Flag少侠的博客

Web应用通常会使用输入过滤器，设计这些过滤器的目的是防御包括SOL 注入在内的常见攻击。这些过滤器可能位于应用的代码中(自定义输入验证方式)，也可能在应用外部实现，形式为 Web应用防火墙(WAF)或入侵防御系统(IPS)

在 SQL 注入攻击中，UNION 运算符的潜在价值非常明显：如果应用程序返回了第一个(原始)查询得到的所有数据，那么通过在第一个查询后面注入一个 UNION 运算符，并添加另外一个任意查询，便可以读取到数据库用户访问过的任何一张表。

在WHERE子句中，使用了一个条件：category='bikes' OR '1'='1'。这个条件的目的是返回所有category为'bikes'的记录，同时也使用了OR逻辑运算符和'1'='1'条件。'1'='1'始终为真，因此这个条件始终成立，导致查询结果返回了所有记录，而不仅仅是category为'bikes'的记录。这是可以预料到的结果。注入 attacker'很明显会产生错误,因为末尾增加了多余的单引号,这导致该 SQL语句出错，但是可以尝试不同的风格，例如 ’bike‘ or '1'='1。

识别漏洞只是目标的一部分。最终目标是利用所测试应用中出现的漏洞。要实现该目标，您需要构造一条有效的SOL请求，它会在远程数据库中执行且不会引发任何错误。

识别数据库的最好方法在很大程度上取决于是否处于盲态。如果应用程序返回(至少在某种程度上)查询结果和(或)数据库服务器错误消息(例如，非盲态)，那么跟踪会相当简单，因为可以很容易通过产生的输出结果来提供关于底层技术的信息。但如果处于盲态，无法让应用返回数据库服务器消息，那么就需要改变方法，尝试注入多种已知的、只针对特定技术才能执行的查询。通过判断这些查询中的哪一条被成功执行,获取目前面对的数据库服务器的精确信息。

另一种不同的SQL注入攻击是“二阶”SQL注入，这种攻击的事件时序通常如下所示:(1)攻击者在HTTP请求中提交某种经过构思的输入。(2)应用程序存储该输入(通常保存在数据库中)以便后面使用并响应请求。(3)攻击者提交第二个(不同的)请求。(4)为处理第二个请求，应用程序会检索已经存储的输入并处理，从而导致攻击者注入的SOL 查询被执行。(5)如果可行的话，会在应用程序对第二个请求的响应中向攻击者返回查询结果。二阶 SOL注入跟等价的一阶 SOL注入一样功能强大。