sql注入

sql注入

原創

铃儿叮当权

2018-09-02 02:17

1、JDBC：使用PreparedStatement防止SQL注入

http://blog.csdn.net/javy_codercoder/article/details/49276653

2、mybatis深入理解之 # 與 $ 區別以及 sql 預編譯

${}方式無法防止sql注入;
1. $一般用入傳入數據庫對象，比如數據庫表名;
2. 注意：mybaties排序時使用order by 動態參數時需要注意，使用${}而不用#{};

xxxx：將傳入的數據直接顯示生成在sql中，對於字符串數據，需要手動加上引號。
#{xxxx}：會給數據加雙引號

mybatis 在對 sql 語句進行預編譯之前，會對 sql 進行動態解析， ${ } 的變量的替換階段是在動態 SQL 解析階段，而 #{ }的變量的替換是在 DBMS 中。

原文：http://blog.csdn.net/hanchao_h/article/details/53640720

mybatis中的sql注入問題:

–mybatis框架作爲一款半自動化的持久層框架，其sql語句都要我們自己來手動編寫，這個時候當然需要防止sql注入。其實Mybatis的sql是一個具有“輸入+輸出”功能，類似於函數的結構，如下：

<select id=“getBlogById“ resultType=“Blog“ parameterType=”int”>
   select id,title,author,content from blog where id=#{id}
</select>

這裏，parameterType標示了輸入的參數類型，resultType標示了輸出的參數類型。迴應上文，如果我們想防止sql注入，理所當然地要在輸入參數上下功夫。上面代碼中高亮部分即輸入參數在sql中拼接的部分，傳入參數後，打印出執行的sql語句，會看到sql是這樣的：
select id,title,author,content from blog where id = ?
不管輸入什麼參數，打印出的sql都是這樣的。這是因爲mybatis啓用了預編譯功能，在sql執行前，會先將上面的sql發送給數據庫進行編譯，執行時，直接使用編譯好的sql，替換佔位符“？”就可以了。因爲sql注入只能對編譯過程起作用，所以這樣的方式就很好地避免了sql注入的問題。
mybatis是如何做到sql預編譯的呢？其實在框架底層，是jdbc中的PreparedStatement類在起作用，PreparedStatement是我們很熟悉的Statement的子類，它的對象包含了編譯好的sql語句。這種“準備好”的方式不僅能提高安全性，而且在多次執行一個sql時，能夠提高效率，原因是sql已編譯好，再次執行時無需再編譯。
話說回來，是否我們使用mybatis就一定可以防止sql注入呢？當然不是，請看下面的代碼：

<select id=“orderBlog“ resultType=“Blog“ parameterType=”map”>
    select id,title,author,content from blog order by ${orderParam}
</select>

仔細觀察，內聯參數的格式由“#{xxx}”變爲了xxx。如果我們給參數“orderParam”賦值爲”id”,將sql打印出來，是這樣的：selectid,title,author,contentfromblogorderbyid顯然，這樣是無法阻止sql注入的。在mybatis中，” {xxx}”這樣格式的參數會直接參與sql編譯，從而不能避免注入攻擊。但涉及到動態表名和列名時，只能使用“{xxx}”這樣的參數格式，所以，這樣的參數需要我們在代碼中手工進行處理來防止注入。
結論：在編寫mybatis的映射語句時，儘量採用“#{xxx}”這樣的格式。若不得不使用“ {xxx}”這樣的參數，要手工地做好過濾工作，來防止sql注入攻擊。