許多網站程序在編寫時，沒有對用戶輸入數據的合法性進行判斷，使應用程序存在安全隱患。用戶可以提交一段數據庫查詢代碼（一般是在瀏覽器地址欄進行,通過正常的www端口訪問），根據程序返回的結果，獲得某些想得知的數據，這就是所謂的SQL Injection，即SQL注入。
SQL注入通過網頁對網站數據庫進行修改。它能夠直接在數據庫中添加具有管理員權限的用戶，從而最終獲得系統管理員權限。黑客可以利用獲得的管理員權限任意獲得網站上的文件或者在網頁上加掛木馬和各種惡意程序，對網站和訪問該網站的網友都帶來巨大危害。
在我們的實際生活中，尋找“ajax+sql注入”的例子並不困難，而且其尋找過程也很簡單，只需經過以下五個步驟即可：
1， 搜索“用戶注冊”，搜索出來的記錄一個一個打開。
2， 測試是否使用了Ajax。
3， 找到check頁面。
4， 在check頁面里的提交用戶名參數那里，給用戶名做下手腳然后在地址欄重新提交。
5， 如果發現500錯誤（web服務器默認錯誤—服務器內部錯誤），就說明他存在注入漏洞。
按照上面的步驟，竟然發現了某大型IT網站的注入漏洞！步驟寫的簡單，具體的方法也有取巧的部分，首先打開找到的網頁（當然是用戶注冊頁面），輸入會員名稱。繼續輸入密碼，彈出消息框：
|
Ajax的作用就在於“不刷新的情況下，異步傳輸數據，經過服務器處理后，得到返回信息，提示給用戶”。看到這個消息框，我第一個想到的就是Ajax。前面說過，在檢測的時候，可以取巧，取巧的地方就在過程中最復雜的地方“翻看源代碼”。如果每個網頁都看看源代碼，然后找js寫的方法（函數），再通過方法（函數）找check頁面，那還不把人累死。於是我想到了“WinSock Expert v0.6 beta1”，這個工具可以截取應用程序通過tcp或udp傳輸的數據，瀏覽器訪問網站的數據當然能夠截獲： 1， 關閉所有的瀏覽器，然后打開一個瀏覽器訪問“用戶注冊頁面”，即上一個截圖給出的頁面。這樣做是為了在選擇進程時，只能看到一個IE進程。 2， 先不要輸入用戶名，打開“WinSock Expert v0.6 beta1”。單擊：
3， 可以看到所有當前運行的進程，選中瀏覽器“IEXOLORE.EXE”。選擇右下角的“open” ：
4， 這個界面就是截獲數據的界面，而且現在已經開始截獲數據，所以不要再去訪問任何頁面。 5， 回到瀏覽器頁面，輸入用戶名“fdsa”（隨便找個一定能被人使用的，比如admin也可以）后把光標移到密碼輸入框。彈出本文第一個圖片所示消息框“對不起，此用戶已經被人使用”，不要點確定。 6， 再回到“WinSock Expert v0.6 beta1”工具界面看到有三條數據：
7， 第一個和最后一個，不去管它，因為它們沒有訪問頁面。單看第2條數據。ID是指序號；status指狀態，這里三條都是發送的數據（send）；packetshex是發送數據的16進制編碼，看不懂不需要看；packets text就是我們能夠看懂的東西了；address當然是服務器ip地址。 8， 選中第二條數據，因為這條數據的第一行顯示“GET /checkuser2”，表示數據是以“GET”形式提交給服務器，也就是說這條信息是IE剛才提交的數據，所以我們查看它。
|
9， 選中后就能在軟件最下面的地方看到數據。復制出來解釋給大家：
 |
詳細參數請參照HTTP頭的文章，這里只解釋能用到的：
第一行是IE訪問的頁面“/checkuser2.jsp?checkemail=fdsa”，以及IE是以GET形式提交的數據，剛輸入的用戶名“fdsa”。
10， 打開http://pass.****.com.cn/checkuser2.jsp?checkemail=fdsa，彈出消息框。
11， 果然可以在這里提交參數，把“fdsa”替換為“fdsa’”提交：
 |
12， 500錯誤頁面，存在SQL注入！
看似很麻煩，有12步，但是比找代碼要簡單的多，直接獲取了check頁面，和參數。
分析服務器返回頁面的代碼：
 |
既然確定存在注入漏洞，就要找他頁面上的Ajax，以便分析出結后寫文章用。查找注冊頁面上的“會員名”，查看輸入框代碼：
 |
調用了RegCheckUserExist2方法，搜索方法找不到記錄。說明是包含了js文件，搜索“<script>”，獲取js文件：
 |
注意我描紅的地方，RegCheckUserExist2方法在/js/chkcus.js文件里，代碼：
 |
Form是在調用RegCheckUserExist2時傳入的參數，整個流程如下：
 |
因為提交是在一個隱藏的iframe（寬和高都是0），所以我們看不到頁面刷新，是個偽Ajax。但是其效果和Ajax一樣，都是在用戶不知道的情況下給服務器提交，只是Ajax是異步的，在提交驗證的時候用戶感覺不到，而這里是同步的，用戶要等待返回結果后，才能進行下一步操作。即使這里用了Ajax，仍然會存在sql注入漏洞，原因是問題出在服務器的驗證這里。我原本打算寫的“ajax可能引發的注入漏洞”和這里所具備的環境基本相似。這有點類似於面向對象里的繼承，一個父類存在漏洞，偽Ajax和Ajax兩個類都繼承了類（這個漏洞），雖然他們都重寫了“驗證的過程”