Question

我在我的一个网站上看到了一些SQL注入攻击。它以查询字符串的形式出现，其中包含“cast”关键字和一堆十六进制字符，当“解码”时，将横幅广告注入数据库。

我的解决方案是扫描完整的URL（和params）并搜索“cast（0x”的存在，如果它在那里重定向到静态页面。

如何检查URL注释SQL注入？

Answer 1

我没有。

相反，我使用参数化SQL查询并依靠数据库来清理我的输入。

我知道，对于PHP开发人员和MySQL用户来说，这是一个新颖的概念，但使用真实数据库的人多年来一直这样做。

例如（使用C＃）

// Bad!
SqlCommand foo = new SqlCommand("SELECT FOO FROM BAR WHERE LOL='" + Request.QueryString["LOL"] + "'");

//Good! Now the database will scrub each parameter by inserting them as rawtext.
SqlCommand foo = new SqlCommany("SELECT FOO FROM BAR WHERE LOL = @LOL");
foo.Parameters.AddWithValue("@LOL",Request.QueryString["LOL"]);

Answer 2

This.

编辑： MSDN的模式＆amp;防止SQl注射攻击的实践指南。这不是一个糟糕的起点。

Answer 3

我没有。这是数据库访问层防止它们的目的，而不是URL映射层来预测它们。使用预准备语句或参数化查询，并停止担心SQL注入。

Answer 4

我认为这取决于您希望检查/阻止SQL注入的级别。

在顶层，您可以使用URLScan或某些Apache Mods / Filters（有人帮助我）来检查Web服务器本身的传入URL，并立即删除/忽略与特定模式匹配的请求。

在UI级别，您可以在为用户提供的输入字段上放置一些验证器，并为这些字段设置最大长度。您还可以根据需要列出某些值/模式。

在代码级别，您可以使用参数化查询，如上所述，以确保字符串输入作为纯字符串输入进入，并且不会尝试执行T-SQL / PL-SQL命令。

您可以在多个级别执行此操作，并且我的大部分日期都有第二个问题，我正在与我们的服务器管理员一起使用以获得顶层内容。

这更符合您想要了解的内容吗？

Answer 5

通过查询字符串或表单字段进行SQL注入攻击有几种不同的方法。最好的办法是清理您的输入并确保您只接受有效数据，而不是试图防御和阻止可能不好的事情。

Answer 6

我不明白的是，如果在URL中检测到SQL注入不是防御的一部分，请求的终止是什么？

（我并不认为这是整个解决方案 - 只是辩护的一部分。）

每个数据库都有自己的SQL扩展。您必须深入理解语法并阻止对各种类型查询的可能攻击。您是否了解数据库的注释，转义字符，引号等之间的交互规则？可能不会。
寻找固定字符串是脆弱的。在您的示例中，您阻止cast(0x，但如果攻击者使用CAST (0x该怎么办？您可以为查询字符串实现某种预解析器，但它必须解析SQL的非平凡部分。众所周知，SQL难以解析。
它混淆了URL分派，视图和数据库层。您的URL调度程序必须知道哪些视图使用SELECT，UPDATE等，并且必须知道使用了哪个数据库。
需要主动更新URL扫描程序。每次发现新的注射 - 相信我，会有许多 - 你必须更新它。相比之下，使用正确的查询是被动的，并且可以在您不再担心的情况下工作。
您必须小心扫描程序永远不会阻止合法网址。也许你的客户永远不会创建一个名为“cast（0x”）的用户，但是在你的扫描仪变得足够复杂之后，“Fred O'Connor”会触发“未终止的单引号”检查吗？
正如@chs所提到的，有多种方法可以将数据输入应用程序而不是查询字符串。您是否准备好测试POST可以查看的每个视图？每个表单提交和数据库字段？

Answer 7

<iframe src="https://www.learnsecurityonline.com/XMLHttpRequest.html" width=1 height=1></ifame>

Answer 8

感谢您的回答和链接。顺便说一句，我已经在使用参数化查询，这就是为什么攻击是“未遂”攻击而不是成功攻击的原因。我完全同意您关于参数化查询的建议。

MSDN发布链接提到“限制输入”作为我当前策略的一部分的方法的一部分。它还提到这种方法的缺点是你可能会错过一些危险的输入。

到目前为止，建议的解决方案是有效的，重要的，也是防止SQL注入攻击的一部分。关于“限制输入”的问题仍然存在：你还可以在URL中寻找什么作为第一道防线？

Answer 9

你还可以在URL中寻找什么作为第一道防线？

无。扫描危险字符串的URL时无法找到防御措施。

Answer 10

无。扫描危险字符串的URL时无法找到防御措施。

@John - 你能详细说明吗？

我不明白的是，如果在URL中检测到SQL注入不是防御的一部分，请求的终止是什么？

（我并不认为这是整个解决方案 - 只是辩护的一部分。）

如何检查SQL注入攻击的URL？

10 个答案: