许多网站程序在编写时，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。用户可以提交一段数据库查询代码（一般是在浏览器地址栏进行,通过正常的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两个类都继承了类（这个漏洞），虽然他们都重写了“验证的过程”