已知的 SQL 注入漏洞，现在该怎么办？答案

【问题标题】：Known SQL Injection Vulnerability, Now What?已知的 SQL 注入漏洞，现在该怎么办？
【发布时间】：2017-06-17 04:55:30
【问题描述】：

我用 Acunetix 扫描了我的一个测试站点，它显示由于引号未闭合，它存在一些 SQL 注入漏洞。

如果我在表单中输入1'"，我会收到错误消息。

如果我进入

"...MessageHandler.asmx/ChangePassword?PIN=1%27"&CurrentPwd=1&newPwd=1"

在 URL 中，我收到错误消息。

我的问题是，我该去哪里多逛逛？我已经阅读了有关注射的教程，但我似乎无法从这一点上弄清楚该怎么做。我知道我有一个注入漏洞，但现在呢？

我接下来会采取什么措施来查看我可以看到的其他类型的数据？

【问题讨论】：

您是否关心利用攻击向量或修复它？
owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005)
这个测试站点是用什么编程语言编写的？
正如下面评论中指出的，也可以使用准备好的语句，并且可能更容易在现有站点上实施。这两种方法都不是 100% 的防御，特别是如果 SQL 是基于用户输入动态构建的。但是如果输入仅限于参数，那么存储过程是非常安全的。 stackoverflow.com/questions/1582161/… 很好地解释了如何使用准备好的语句来避免 SQL 注入。我建议您也阅读该帖子。
在这一点上，我对修复它不感兴趣。我实际上需要向负责人展示这是多么糟糕，他们需要理解并解决它。我不是程序员。从他们的角度来看，向他们展示网站的某些部分可以接受 SQL 命令实际上并没有“展示”他们太多。我可以寄给他们看的东西，但最终我想向他们展示一些我不应该做的明显不好的视觉效果。一旦他们看到这一点，他们就会更倾向于离线或花时间修复它。

标签： sql sql-server sql-injection

【解决方案1】：

在 Microsoft SQL Server 中，SQL 注入是通过使用存储过程来消除的。它不会执行发送的命令，即使是作为参数。如果您将嵌入式 SQL 替换为存储过程，您将消除 SQL 注入威胁。通过 GUI 验证例程清理您的输入仍然是一种很好的做法，但是经验丰富的黑客可以轻松地绕过这些，因此消除嵌入式 SQL 也很重要。

【讨论】：

存储过程并不是减轻注入攻击的唯一方法，使用存储过程也不能保证免受此类攻击。您可以通过 Prepared Statements 使用嵌入式 SQL，并且在不使用存储过程的情况下更好地防止注入攻击。