java防注入原理和sql運行過程
談及java防注入就要談及sql運行過程，只有理解了sql運行過程，才能理解預編譯，才能深入瞭解java防注入的實現原理
1 sql注入
sql注入，簡單來說就是用戶在前端web頁面輸入惡意的sql語句（拼接的sql語句）來欺騙後端服務器去執行惡意的sql代碼，從而導致數據庫數據泄露或者遭受攻擊。
2 解決sql注入方法
2.1 那麼如何解決sql注入？
在JDBC進行連接時使用PreparedStatement類去代替Statement,或者傳入的條件參數完全不使用String字符串，同樣地，在用mybatis時，則儘量使用#{param}佔位符的方式去避免sql注入（${param}可以通過拼接參數實現sql注入）。
2.2 防止sql注入原理
這兩個不同環境下解決sql注入實際原理是一致的。當使用PreparedStatement去寫sql語句時，程序會對該條sql首先進行預編譯，然後會將傳入的字符串參數以字符串的形式去處理，即會在參數的兩邊自動加上單引號（’param’），而Statement則是直接簡單粗暴地通過人工的字符串拼接的方式去寫sql，那這樣就很容易被sql注入。這裏就需要理解sql運行過程（後面會講到）
那麼，如果PreparedStatement只是僅僅簡單地通過把字符串參數兩邊加上引號的方式去處理，一樣也很容易被sql注入，下面舉個例子帶着大家簡單瞭解下sql注入。
創建user表（id,name,class）;
create table user
(
id int4 PRIMARY KEY,
name VARCHAR(20) not null,
class VARCHAR(20)
)
裏面有如下幾條數據：
INSERT INTO `user` VALUES ('1', 'Tom', '1班');
INSERT INTO `user` VALUES ('2', 'Jeery', '2班');
這裏我們使用mybatis的$ {param} 和 #{param} 兩個不同的佔位符來作爲示例解釋 Statement 和 PreparedStatement (mybatis和jdbc的低層原理是一樣的)。不瞭解mybatis的讀者可以暫時放下這個疑問，或者搜索查看下${}和#{}的區別。
首先{}是不能防止sql注入的，它能夠通過字符串拼接的形式來任意擺弄你的sql語句，而#{}則可以很大程度上地防止sql注入，下面是關於這個的一條sql：
<mapper namespace="com.sky.dao.UserMapper">
<select id="query" parameterType="com.sky.model.User" resultType="com.sky.model.User">
select * from user where name = '${name}'
</select>
</mapper>
- 前端頁面的簡略的代碼：
<form action="<%=basePath%>query" method="get">
<input type="input" placeholder="請輸入姓名" name="name"/><input type="submit" value="查詢"/>
</form>
前端頁面通過form表單的形式輸入查詢條件並調用後端sql。如果使用的是${param}佔位符
select * from user where name = ${name}
當在前端傳入參數爲：Tom，則對應sql爲：select * from user where name = ‘Tom’；這時只顯示Tom的數據。
但是，如果其傳入參數爲：‘Tom’ or 1=’1；則傳到後臺之後其對應的sql就變爲：select * from user where name = ‘Tom’ or 1=’1’；此時得到的爲全表數據，這個就有了很大的問題。
將mybatis中的sql語句改爲：select * from user where name = #{name}
如果傳入的參數爲：Tom，依舊爲Tom的一行數據，輸入：張三’ or 1=’1 則顯示爲空。
那麼它的原理又是什麼呢？我帶着這個問題去尋找答案，很顯然，尋找答案的最好方式就是去看源代碼。於是找到mysql-jdbc連接的源代碼，查看PreparedStatement類的源代碼，其中setString()方法的源代碼如下：
這段代碼的作用是將java中的String字符串參數傳到sql語句中，並通過驅動將其轉換成sql語句併到數據庫中執行。這段代碼中前面一部分做了一些是否需要對字符串進行轉義的判斷。後面一部分則是如何有效防止sql注入的重點，代碼中通過一個for循環，將字符串參數通過提取每一位上的char字符進行遍歷，並通過switch()….case 條件語句進行判斷，當出現換行符、引號、斜槓等特殊字符時，對這些特殊字符進行轉義。那麼，此時問題的答案就出來了，當我們使用PreparedStatement進行傳參時，若傳入參數爲：'Tom’ or 1 = ‘1 時，經過程序後臺進行轉義後，真正的sql其實變成了： select * from user where name = ‘Tom\’ or 1 = \’1’；顯然這樣查詢出來的結果一定爲空。
/**
* 傳入下標和參數
* @param parameterIndex
* @param x
* @throws SQLException
*/
/** Is this query a LOAD DATA query? */
//此查詢是加載數據查詢嗎？
protected boolean isLoadDataQuery = false;
public void setString(int parameterIndex, String x) throws SQLException {
synchronized (checkClosed().getConnectionMutex()) {
// if the passed string is null, then set this column to null
//如果傳遞的字符串爲空，則將此列設置爲空
if (x == null) {
setNull(parameterIndex, Types.CHAR);
} else {
checkClosed();
//獲取參數長度
int stringLength = x.length();
if (this.connection.isNoBackslashEscapesSet()) {
// Scan for any nasty chars
//調用isEscapeNeededForString()方法掃描任何惡意的字符(防注入檢測)，
//返回Boolean類型的needsHexEscape，有字符返回true
boolean needsHexEscape = isEscapeNeededForString(x,
stringLength);
if (!needsHexEscape) {
//定義一個Byte類型的數組，用於接收轉換後的字符串
byte[] parameterAsBytes = null;
//看這裏，這裏對數據進行了改造，前後都有拼接
StringBuffer quotedString = new StringBuffer(x.length() + 2);
quotedString.append('\'');
quotedString.append(x);
quotedString.append('\'');
if (!this.isLoadDataQuery) {
parameterAsBytes = StringUtils.getBytes(quotedString.toString(),
this.charConverter, this.charEncoding,
this.connection.getServerCharacterEncoding(),
this.connection.parserKnowsUnicode(), getExceptionInterceptor());
} else {
// Send with platform character encoding
//使用網絡字符編碼發送
parameterAsBytes = StringUtils.getBytes(quotedString.toString());
}
setInternal(parameterIndex, parameterAsBytes);
} else {
byte[] parameterAsBytes = null;
//isLoadDataQuery定義的Boolean類型的變量，初始值爲false，判斷是否此查詢是加載數據查詢
if (!this.isLoadDataQuery) {
parameterAsBytes = StringUtils.getBytes(x,
this.charConverter, this.charEncoding,
this.connection.getServerCharacterEncoding(),
this.connection.parserKnowsUnicode(), getExceptionInterceptor());
} else {
// Send with platform character encoding
//轉化爲字符類型的數組
parameterAsBytes = StringUtils.getBytes(x);
}
setBytes(parameterIndex, parameterAsBytes);
}
return;
}
String parameterAsString = x;
boolean needsQuoted = true;
if (this.isLoadDataQuery || isEscapeNeededForString(x, stringLength)) {
needsQuoted = false; // saves an allocation later
StringBuffer buf = new StringBuffer((int) (x.length() * 1.1));
buf.append('\'');
//
// Note: buf.append(char) is _faster_ than
// appending in blocks, because the block
// append requires a System.arraycopy()....
// go figure...
//
for (int i = 0; i < stringLength; ++i) {
//charAt()方法返回指定索引位置的char值
char c = x.charAt(i);
switch (c) {
case 0: /* Must be escaped for 'mysql' */
buf.append('\\');
buf.append('0');
break;
case '\n': /* Must be escaped for logs */
buf.append('\\');
buf.append('n');
break;
case '\r':
buf.append('\\');
buf.append('r');
break;
case '\\':
buf.append('\\');
buf.append('\\');
break;
case '\'':
buf.append('\\');
buf.append('\'');
break;
case '"': /* Better safe than sorry */
if (this.usingAnsiMode) {
buf.append('\\');
}
buf.append('"');
break;
case '\032': /* This gives problems on Win32 */
buf.append('\\');
buf.append('Z');
break;
case '\u00a5':
case '\u20a9':
// escape characters interpreted as backslash by mysql
if(charsetEncoder != null) {
CharBuffer cbuf = CharBuffer.allocate(1);
ByteBuffer bbuf = ByteBuffer.allocate(1);
cbuf.put(c);
cbuf.position(0);
charsetEncoder.encode(cbuf, bbuf, true);
if(bbuf.get(0) == '\\') {
buf.append('\\');
}
}
// fall through
default:
buf.append(c);
}
}
buf.append('\'');
parameterAsString = buf.toString();
}
byte[] parameterAsBytes = null;
if (!this.isLoadDataQuery) {
if (needsQuoted) {
//定義的變量charConverter:要使用的字符轉化器（默認null），定義的變量charEncoding：要使用的字符編碼
parameterAsBytes = StringUtils.getBytesWrapped(parameterAsString,
'\'', '\'', this.charConverter, this.charEncoding, this.connection
.getServerCharacterEncoding(), this.connection
.parserKnowsUnicode(), getExceptionInterceptor());
} else {
parameterAsBytes = StringUtils.getBytes(parameterAsString,
this.charConverter, this.charEncoding, this.connection
.getServerCharacterEncoding(), this.connection
.parserKnowsUnicode(), getExceptionInterceptor());
}
} else {
// Send with platform character encoding
parameterAsBytes = StringUtils.getBytes(parameterAsString);
}
setInternal(parameterIndex, parameterAsBytes);
this.parameterTypes[parameterIndex - 1 + getParameterIndexOffset()] = Types.VARCHAR;
}
}
}
private boolean isEscapeNeededForString(String x, int stringLength) {
boolean needsHexEscape = false;
for (int i = 0; i < stringLength; ++i) {
//charAt()方法返回指定索引位置的char值
char c = x.charAt(i);
switch (c) {
case 0: /* Must be escaped for 'mysql' */
needsHexEscape = true;
break;
case '\n': /* Must be escaped for logs */
needsHexEscape = true;
break;
case '\r':
needsHexEscape = true;
break;
case '\\':
needsHexEscape = true;
break;
case '\'':
needsHexEscape = true;
break;
case '"': /* Better safe than sorry */
needsHexEscape = true;
break;
case '\032': /* This gives problems on Win32 */
needsHexEscape = true;
break;
}
if (needsHexEscape) {
break; // no need to scan more
}
}
return needsHexEscape;
}
}
看了java中PreparedStatement的底層源碼，對於防止sql注入有了瞭解，但是這隻停留在java編程層面，對數據庫的具體操作還是由sql語句在數據庫中執行生成，那麼爲什麼PreparedStatement中的‘？‘佔位符就可以在sql中使用囊？那麼sql語句如何執行成功的呢？Statement和PreparedStatement到底有什麼區別囊？帶着問題我們一起去看sql執行過程。
3 sql運行過程
詞法分析→語法分析→語義分析→生成執行計劃進行性能優化→執行。
這裏就要說到基本上與其他編譯系統差不多。SQL語句本意就是要避開復雜的底層操作，用非常利於普通人理解的簡單語句完成對於二維表的查詢。
從程序到sql執行的具體過程：
第一步：應用程序把查詢SQL語句發給服務器端執行
我們在數據層執行SQL語句時，應用程序會連接到相應的數據庫服務器，把SQL語句發送給服務器處理。
第二步：服務器解析請求的SQL語句（這裏需要注意一下java中的sql緩存和數據庫中的sql緩存，這裏不細講）
SQL計劃緩存，經常用查詢分析器的朋友大概都知道這樣一個事實，往往一個查詢語句在第一次運行的時候需要執行特別長的時間，但是如果你馬上或者在一定時間內運行同樣的語句，會在很短的時間內返回查詢結果。原因是：
- 服務器在接收到查詢請求後，並不會馬上去數據庫查詢，而是在數據庫中的計劃緩存中找是否有相對應的執行計劃。如果存在，就直接調用已經編譯好的執行計劃，節省了執行計劃的編譯時間。
- 如果所查詢的行已經存在於數據緩衝存儲區中，就不用查詢物理文件了，而是從緩存中取數據，這樣從內存中取數據就會比從硬盤上讀取數據快很多，提高了查詢效率。數據緩衝存儲區會在後面提到。
如果在SQL計劃緩存中沒有對應的執行計劃，服務器首先會對用戶請求的SQL語句進行語法效驗，如果有語法錯誤，服務器會結束查詢操作，並用返回相應的錯誤信息給調用它的應用程序。
注意：此時返回的錯誤信息中，只會包含基本的語法錯誤信息，例如select 寫成selec等，錯誤信息中如果包含一列表中本沒有的列，此時服務器是不會檢查出來的，因爲只是語法驗證，語義是否正確放在下一步進行。
語法符合後，就開始驗證它的語義是否正確。例如，表名、列名、存儲過程等等數據庫對象是否真正存在，如果發現有不存在的，就會報錯給應用程序，同時結束查詢。
接下來就是獲得對象的解析鎖，我們在查詢一個表時，首先服務器會對這個對象加鎖，這是爲了保證數據的統一性，如果不加鎖，此時有數據插入，但因爲沒有加鎖的原因，查詢已經將這條記錄讀入，而有的插入會因爲事務的失敗會回滾，就會形成髒讀的現象。
接下來就是對數據庫用戶權限的驗證。SQL語句語法，語義都正確，此時並不一定能夠得到查詢結果，如果數據庫用戶沒有相應的訪問權限，服務器會報出權限不足的錯誤給應用程序，在稍大的項目中，往往一個項目裏面會包含好幾個數據庫連接串，這些數據庫用戶具有不同的權限，有的是隻讀權限，有的是隻寫權限，有的是可讀可寫，根據不同的操作選取不同的用戶來執行。稍微不注意，無論你的SQL語句寫的多麼完善，完美無缺都沒用。
解析的最後一步，就是確定最終的執行計劃。當語法、語義、權限都驗證後，服務器並不會馬上給你返回結果，而是會針對你的SQL進行優化，選擇不同的查詢算法以最高效的形式返回給應用程序。例如在做表聯合查詢時，服務器會根據開銷成本來最終決定採用hash join,merge join ，還是loop join，採用哪一個索引會更高效等等。不過它的自動化優化是有限的，要想寫出高效的查詢SQL還是要優化自己的SQL查詢語句。
當確定好執行計劃後，就會把這個執行計劃保存到SQL計劃緩存中，下次在有相同的執行請求時，就直接從計劃緩存中取，避免重新編譯執行計劃。
第三步：語句執行
服務器對SQL語句解析完成後，服務器纔會知道這條語句到底表態了什麼意思，接下來纔會真正的執行SQL語句。
此時分兩種情況：
- 如果查詢語句所包含的數據行已經讀取到數據緩衝存儲區的話，服務器會直接從數據緩衝存儲區中讀取數據返回給應用程序，避免了從物理文件中讀取，提高查詢速度。
- 如果數據行沒有在數據緩衝存儲區中，則會從物理文件中讀取記錄返回給應用程序，同時把數據行寫入數據緩衝存儲區中，供下次使用。
說明：SQL緩存分好幾種，這裏有興趣的朋友可以去搜索一下。有時因爲緩存的存在，使得我們很難馬上看出優化的結果，因爲第二次執行因爲有緩存的存在，會特別快速，所以一般都是先消除緩存，然後比較優化前後的性能表現，這裏有幾個常用的方法：
1 DBCC DROPCLEANBUFFERS
2 從緩衝池中刪除所有清除緩衝區。
3 DBCC FREEPROCCACHE
4 從過程緩存中刪除所有元素。
5 DBCC FREESYSTEMCACHE
6 從所有緩存中釋放所有未使用的緩存條目。
SQL Server 2005 數據庫引擎會事先在後臺清理未使用的緩存條目，以使內存可用於當前條目。但是，可以使用此命令從所有緩存中手動刪除未使用的條目。
這隻能基本消除SQL緩存的影響，目前好像沒有完全消除緩存的方案，如果大家有，請指教。
執行順序：
- FROM 子句返回初始結果集。
- WHERE 子句排除不滿足搜索條件的行。
- GROUP BY 子句將選定的行收集到 GROUP BY 子句中各個唯一值的組中。
- 選擇列表中指定的聚合函數可以計算各組的彙總值。
- 此外，HAVING 子句排除不滿足搜索條件的行。
- 計算所有的表達式；
- 使用order by對結果集進行排序。
- 查找你要搜索的字段。
預處理編譯 SQL 是佔用資源的，所以在使用後注意及時使用 DEALLOCATE PREPARE 釋放資源，這是一個好習慣。
useServerPrepStmts參數
默認使用PreparedStatement是不能執行預編譯的，這需要在url中給出useServerPrepStmts=true參數（MySQL Server 4.1之前的版本是不支持預編譯的，而Connector/J在5.0.5以後的版本，默認是沒有開啓預編譯功能的）。
例如：jdbc:mysql://localhost:3306/test?useServerPrepStmts=true
這樣才能保證mysql驅動會先把SQL語句發送給服務器進行預編譯，然後在執行executeQuery()時只是把參數發送給服務器。
這裏Statement和PreparedStatement的區別其實就體現在了預編譯上。
預編譯語句的優勢在於歸納爲：一次編譯、多次運行，省去了解析優化等過程；此外預編譯語句能防止sql注入。
備註：MySQL中的預編譯語句作用域是session級，
文章參考了大佬的博文，但是之前一直保存在草稿箱中，無法批註複製博主的地址，有知道的，請大家留言，我附到文章後面。