burp注入

priess

简介

所谓SQL注入，就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将（恶意的）SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。

自动化检测注入工具

使用SQLNinja和SQLMap等一些自动化工具开发SQL注入变得相对容易，我也很喜欢使用。这些自动化工具中的很多都是高度可配置的，帮助你绕过黑名单/过滤器，甚至可以为你提供shell，还有许多其他功能，这里不一一介绍了。SQLMap最厉害的就是检测SQL漏洞了 - 它们的模板可以在payloads.xml中找到文件。SQLMap目前包含六种注入技术的特定有效载荷：基于布尔的盲注，基于时间的盲注，基于错误的，UNION查询，堆栈查询（out-of-band）。

但是，在以自动方式利用SQL注入漏洞之前，你必须首先检测到它存在注入的可能。使用上述自动化工具来检测新的注入漏洞并不是最好的选择，因为有几个原因。通常这些工具需要很多时间，只是因为他们默认会枚举大量的有效载荷。目前，SQLMap为你提供了一些选项来限制选择的有效载荷的数量： –level, –risk，-dbms和-technique（据我所知），它会产生极大的流量。例如，我发现SQLMap的盲注会结合多线程产生极大的流量，有时会产生大量的误报，而且出现CRSF特性验证方式的时候会出现找不到注入点的问题。

我下面使用burpSite 通过爆破来检测是否存在注入的可能。

基础知识(了解即可)

这种方法是基于注入有效负载，突破原来的查询，并在服务器端产生一个SQL错误，可以在Web应用程序返回的页面内容中检测到。

布尔型

此方法基于注入有效负载来改变原始查询的结果，从而导致不同的返回页面内容。

先决条件

修改攻击的参数必须对页面内容有所影响，因此可以用在布尔表达式中，这通常会将此方法的范围限制为在查询的WHERE子句中使用的参数。

有效载荷

将一个参数的值替换为一个布尔型子查询，该查询对于整个查询为真：

sql 999999 or 1=1 or 1=1 ' or 1=1 or '1'='1 " or 1=1 or "1"="1 999999) or 1=1 or (1=1 ') or 1=1 or ('1'='1 ") or 1=1 or ("1"="1 999999)) or 1=1 or ((1=1 ')) or 1=1 or (('1'='1 ")) or 1=1 or (("1"="1 999999))) or 1=1 or (((1 '))) or 1=1 or ((('1'='1 "))) or 1=1

必须使用两个相邻的OR子句，因为AND具有比OR优先级更高。

发现

为了检测漏洞，必须确定基本请求的响应与包含注入有效负载的请求的响应之间的内容长度的显着差异。最好的方法是采用一个无效的参数值的基本请求，所以它的响应是尽可能小的。当参数容易受到SQL注入的攻击时，我们的有效载荷使得SQL查询返回更多的结果，而这些结果在接收到的响应中将是可见的。以Acunetix的以下测试平台网站为例：

http://testaspnet.vulnweb.com/ReadNews.aspx?id=2

我们要测试GET ID参数，所以首先我们用无效的值替换有效值，以便获得尽可能小的基本请求：

http://testaspnet.vulnweb.com/ReadNews.aspx?id=1337

我们选择ID参数的值作为注入位置，加载我们的12个有效载荷字符串并开始攻击：

第一步设置代理，拦截数据。然后传到爆破(intruder)这个选项下(前提burpSite得会使用)









第二步复制有效载荷



第三步进行攻击





我们可以清楚地看到，我们的第一个有效载荷请求产生了比无效请求大得多的响应，而所有其他的有效载荷请求产生了非常小的响应。在攻击结果窗口的底部，我们可以看到只有这些请求返回了HTTP头，这可能表明服务器端的错误被抑制，这里没有详细的错误信息。在分析引起较小响应的有效负载时，我们发现它们都包含可能会破坏SQL查询的字符：引号和括号。我们可以猜到，这是发生了什么事，导致一个空返回值。

当我们的浏览器打开请求时，我们看到包含有效的新闻文章的页面被返回：

http://testaspnet.vulnweb.com/ReadNews.aspx?id=999999 or 1=1 or 1=1

有可能我们发现一个SQL注入，但它仍然不确定。例如，某些Web应用程序在某些情况（未）满足时显示默认文章。为了更确定一些，我通常会进行一个简单但相当可靠的手动测试，对于以下情况不同：

整数：将有效参数的整数值替换为导致相同值的数学公式，并验证两个响应是否相同，这意味着该参数的值由SQL后端直接解释，并且SQL注入非常可能。
字符串：将有效参数的字符串值分为两部分，并在两者之间添加一个SQL字符串concat指令。
当执行下面的请求时，我们得到与id = 2的基本请求完全相同的响应：

http://testaspnet.vulnweb.com/ReadNews.aspx?id=3-1

这只是我的小思路，大家要根据实际情况应变。

然后就是到SQLMap的时刻。

结论

覆盖所有数据库有限的有效载荷数量是一个很大的优势。这种方法的主要缺点是可能会遗漏一些注入点，它们位于不同于WHERE子句的字段中，或者不影响网页的响应。但是，当你看到一个参数明显影响了请求的响应时，这个参数肯定是值得尝试的，例如一个包含很多字段的搜索表单。我经常为每个字段输入一些无效的值，将请求发送给入侵者，并对其发起这些有效载荷。必须指出的是，这种方法可能仍然会导致误报 - 为了充分确认漏洞，需要手动验证。