为什么它不足以阻止前端的SQL注入？

Question

所有关于防止SQL注入的资源都在谈论防止它从数据库级别到前端和后端。为什么我们需要做所有这些事情？

仅通过阻止用户发送恶意SQL代码作为输入，从前端进行是不够的。

Answer 1

因为大多数客户端代码都可以绕过它，因为它在客户端的机器上执行。基本上，任何能够防止客户端输入错误的代码都可以为诚实用户提供更好的反馈，同时也可以减少低水平的攻击类型。

后端代码用于确保绕过前端安全性（使用精心设计的http请求或w / e）的任何恶意用户都无法将错误输入注入您的SQL动态查询之一。这通常通过清理后端上的输入并使用参数化查询来实现。

Answer 2

仅仅因为你按下你的前端并不能保证SQL注入的安全性。所有前端都向用户展示了美好的东西。后端是完成所有工作的地方，因为前端必须以某种方式与后端通信，这意味着您有潜在的安全问题。

我不知道您的应用程序是Winforms还是Web应用程序，但这并不重要。我可以使用Process Explorer等程序来处理发送到后端的数据（如果是Windows应用程序）。

如果它是一个Web应用程序，那么，类似地，我可以使用Fiddler这样的工具来操纵发送到后端的数据。

故事的道德总是按下你的后端，永远不要让你的后端假设从前端得到的数据是笨拙的！[/ p>

Answer 3

深度防守是一件非常非常好的事情。考虑到这一点，您的应用将值作为查询的参数，或者甚至可以使用用户输入来形成查询。您在应用程序级别执行正确的操作以正确地转义输入，因此注入尝试不执行任何操作，并且数据可以安全地读取或写入数据库。现在，如果

1. 写入数据库本身的数据是恶意代码吗？从表中读取的下一个存储过程现在可能正在执行随机代码。
2. 应用程序代码将“安全”数据传递给后端，然后将后端用于存储过程或函数（例如，反序列化，强制转换等）。再一次，你可能正在执行恶意代码。

你可以争辩说，你可以解析输入，而不是转义输入，你可以解析应用程序级别的输入来剥离/拒绝某些值，强类型，正则表达式等等......但是有很多情况下这些限制无法实现因为该应用程序旨在支持可能合法地具有可疑字符的自由流动文本，尤其是如果您支持国际字符集。 （例如姓名，描述，注释等）。

最后，是否/应该/可以让DBA真正依赖应用程序或应用程序开发人员每次都做对了吗？