您可以使用一组针对应用程序中每个入口点的系统测试来手动检测 SQL 注入。为此,您通常会提交:
'
OR 1=1
,OR 1=2
或者可以使用 Burp Scanner 快速可靠地找到大多数 SQL 注入漏洞。
想象一下,一个显示不同类别产品的购物应用程序。当用户单击**“礼物**”类别时,其浏览器会请求 URL:
https://insecure-website.com/products?category=Gifts
这会导致应用程序进行 SQL 查询,以从数据库中检索相关产品的详细信息:
SELECT * FROM products WHERE category = 'Gifts' AND released = 1
此 SQL 查询要求数据库返回:
*
)products
category
,Gifts
released
,1
该限制用于隐藏未发布的产品。我们可以假设对于未发布的产品,.released = 1
,released = 0
应用程序未实现任何针对 SQL 注入攻击的防御措施。这意味着攻击者可以构建以下攻击,例如:
https://insecure-website.com/products?category=Gifts'--
这将导致 SQL 查询:
SELECT * FROM products WHERE category = 'Gifts'--' AND released = 1
至关重要的是,请注意,这是 SQL 中的注释指示符。这意味着查询的其余部分被解释为注释,从而有效地删除了它。在此示例中,这意味着查询不再包含 .因此,将显示所有产品,包括尚未发布的产品。--
AND released = 1
您可以使用类似的攻击来使应用程序显示任何类别中的所有产品,包括他们不知道的类别:
https://insecure-website.com/products?category=Gifts'+OR+1=1--
这将导致 SQL 查询:
SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1
修改后的查询将返回 为 或等于 的所有项目。与往常一样,查询将返回所有项。category Gifts 1 1 1=1
警告
将条件注入 SQL 查询时要小心。即使它在你注入的上下文中看起来是无害的,应用程序在多个不同的查询中使用来自单个请求的数据也是很常见的。
例如,如果您的条件达到 OR 语句,则可能导致数据意外丢失。
OR 1=1
,UPDATE
,DELETE
想象一下,一个允许用户使用用户名和密码登录的应用程序。如果用户提交用户名和密码,则应用程序通过执行以下 SQL 查询来检查凭据:wiener``bluecheese
SELECT * FROM users WHERE username = 'wiener' AND password = 'bluecheese'
如果查询返回用户的详细信息,则登录成功。否则,它将被拒绝。
在这种情况下,攻击者可以以任何用户身份登录,而无需密码。他们可以使用 SQL 注释序列来执行此操作,以从查询子句中删除密码检查。例如,提交用户名和空白密码会导致以下查询:-- WHERE administrator'--
SELECT * FROM users WHERE username = 'administrator'--' AND password = ''
此查询返回其用户,并成功以该用户身份将攻击者登录。username``administrator
administrator
username
值更改为administrator'--