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

我的解决方案是扫描完整的URL(和参数)并搜索是否存在" cast(0x)"，如果存在，则重定向到静态页面。

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

解决方案

回答

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

回答

我不。

相反，我使用参数化的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"]);

回答

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

回答

这。

编辑：有关防止SQl注入攻击的MSDN的模式和实践指南。不错的起点。

回答

感谢答案和链接。顺便说一句，我已经在使用参数化查询，这就是为什么该攻击是"尝试过的"攻击而不是成功的攻击。我完全同意我们有关参数化查询的建议。

MSDN发布的链接提到"限制输入"是该方法的一部分，这是我当前策略的一部分。它还提到此方法的缺点是我们可能会错过一些危险的输入。

到目前为止，建议的解决方案是有效，重要的，并且是防范SQL注入攻击的一部分。关于"限制输入"的问题仍然悬而未决：作为第一道防线，我们还能在URL中寻找什么？

回答

What else could you look for in the URL as a first line of defense?

没有。在扫描URL中查找危险字符串时找不到防御措施。

回答

Nothing. There is no defense to be found in scanning URLs for dangerous strings.

@John我们能详细说明吗？

我不明白的是，如何在URL中检测到SQL注入后立即终止请求不是防御措施？

(我并不是说这是整个解决方案，只是防御的一部分。)

回答

我认为这取决于我们要检查/防止SQL注入的级别。

在顶层，我们可以使用URLScan或者某些Apache Mods / Filters(有人在这里为我提供帮助)来检查到Web服务器本身的传入URL，并立即删除/忽略符合特定模式的请求。

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

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

我们可以在多个级别上进行操作，而我的大部分工作都完成了后两个问题，并且我正在与服务器管理员合作，以使顶层工作到位。

这是否更符合我们想知道的内容？

回答

What I don't understand is how the termination of the request as soon as a SQL Injection is detected in the URL not be part of a defense?
  
  (I'm not claiming this to be the entire solution - just part of the defense.)

• 每个数据库都有自己的SQL扩展。我们必须深入了解语法，并阻止各种类型查询的可能攻击。我们了解数据库注释，转义字符，引号等之间的交互规则吗？可能不是。
• 寻找固定的字符串是脆弱的。在示例中，我们阻止了cast(0x，但是如果攻击者使用CAST(0x？呢？ SQL众所周知，SQL很难解析。
• 它混淆了URL分发，视图和数据库层。URL调度程序将必须知道哪些视图使用SELECT，UPDATE等，并且必须知道使用了哪个数据库。
• 它需要主动更新URL扫描程序。每次发现新的注射剂-相信我，会有很多-我们必须对其进行更新。相反，使用适当的查询是被动的，不需要我们再担心就可以工作。
• 我们必须注意，扫描程序永远不会阻止合法的URL。也许客户永远不会创建名为" cast(0x)"的用户，但是在扫描仪变得足够复杂之后，" Fred O'Connor"会触发"未终止单引号"检查吗？
• 正如@chs所提到的，将数据获取到应用程序中的方法比查询字符串更多。我们准备好测试可以"发布"到的每个视图了吗？每个表单提交和数据库字段？

回答

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