结合WebScarab对WebGoat进行SQL注入测试

    SQL注入是目前Web应用中最常见的漏洞，只要网页上有提交框并且该提交框的内容影响后台的查询的SQL语句，就可能存在该漏洞。一般程序员在编写Web应用程序时都是直接从request中取出提交的参数的值放入到SQL语句中进行查询，这就造成了一个又一个的SQL注入风险。熟悉SQL语句的攻击者会在网页输入框中输入设计好的内容，将SQL的查询逻辑改变，从而得到自己想要的东西。举几个例子：
    案例1：绕过登录界面：
         常见的登录页面有两个输入框，一个用户名，一个密码，后台的SQL语句为
         select * from Users where username=’[用户名]’ and password=’[密码]’
         其中[用户名]和[密码]分别为在两个输入框中输入的内容，一般来说没有什么问题，程序员只要判断返回的recordset的记录数大于0就可以使用户登录进去，但是如果恶意用户在用户名中输入x’ or ‘1’=’1,密码随便输，那么后台的SQL查询语句就会变为
         select * from Users where username=’ x’ or ‘1’=’1’ and password=’[密码]’
         其中where语句的逻辑值始终为真，如果能猜中用户名，即可以使用该用户登录
    案例2：执行危险的SQL语句；
         现在不少数据库支持批处理，使用分号隔开多个SQL语句，如一个查询界面，可以查询客户号（客户号为数字类型），后台的SQL语句为：
         select * from customers where ID=[客户号]
         其中[客户号]为用户输入内容，假如用户输入的为1;drop table customers。则整个SQL语句变为select * from customers where ID=[客户号] 1;drop table customers，这样的查询一过，Customers表就没了。
         使用同样的手法，恶意用户还可以植入触发器，修改数据，总之，可以执行后台的SQL执行时使用的数据用户权限内的所有操作。

         当然SQL注入攻击也不见得都是这么简单，有的时候需要认真分析网页，猜测其SQL的结构，并且需要利用一些工具进行辅助。本文对WebGoat教程中的一段有关SQL 注入测试进行解释，WebGoat我在另一篇文章【学习Web应用漏洞最好的教程----WebGoat】中有过介绍。因为在测试中用到了WebScarab，这里简单介绍一下。

         WebScarab说白了就是一个代理工具，他可以截获web浏览器的通信过程，将其中的内容分析出来，使你很容易修改，比如我发一个submit请求，WebScarab首先截获到，不急着给真正的服务器，而是弹出一个窗口让你可以修改其中的内容，修改结束了再提交给服务器，如果网页的输入框进行了一些限制，如长度限制、数字格式限制等，只能使用这种方式进行修改了；它也可以修改服务器返回的response，这就可以过滤掉一些对客户端进行限制的js等。这是OWASP的另一利器。

         下面开始注入过程：
         首先明确目标，webgoat的教程：

      界面上只有一个输入框，该教程的要求是要我们使用SQL注入方法登入界面，兴冲冲的在password中输入x’ or ‘1’=’1，不行，原来这个password框只能输入8个字符，刚才的那个有12个字符之多！这时看样子要祭出WebScarab了。
      WebScarab的默认运行模式为Lite模式，如下图：

         需要将其更改为Full-Featured Interface模式，勾选上图中的【use Full-Featured Interface】，重新启动WebScarab，界面如下，多了很多功能选项：

 

         因为我们要截获发出的请求，将【Proxy】-【Manual Edit】-【Intercept request】勾选上。在IE中将代理服务器指向本机的8008端口，在webgoat的密码框中输入111提交，马上弹出了如下界面：

         其中password可以修改为：x’ or ‘1’=’1，点击Accept Changes，成功，界面如下：