现在的位置: 首页 > IT运维 > 正文

WebScarab结合WebGoat进行SQL注入

2011年03月18日 IT运维 ⁄ 共 1666字 暂无评论 ⁄ 被围观 732+

WebScarab,记录web交互的会话内容(请求和应答),使用者可以通过多种形式来查看这些记录。WebScarab可以让使用者可以掌握某种基于HTTP(S)程序的运作过程;也可以用它来调试程序中较难处理的bug,也可以帮助安全专家发现潜在的程序漏洞。

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的结构,并且需要利用一些工具进行辅助。因为在测试中用到了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端口(webscarab的),在webgoat的密码框中输入111提交

其中password可以修改为:x’ or ‘1’=’1,点击Accept Changes,成功

给我留言

您必须 [ 登录 ] 才能发表留言!

×
#