我想知道是否有一种解决SQL注入的标准方法。我问，因为我开始在一家公司工作，他们希望我让网站sql注入安全。有没有办法像扫描整个网站或程序来处理已经存在的软件中的SQL注入？
答案 0 :(得分：3)
我在演示文稿中SQL Injection Myths and Fallacies广泛地写了关于SQL注入防御的文章（或者听我在free webinar at Percona.com中提出它）。
基本上没有银弹，但有几种标准的防御方法。
有多种免费入侵检测工具可供使用，例如WebScarab或w3af。这些可以作为黑盒测试技术的第一步，用于查找您网站中的第一层漏洞。
关于这个主题的另一篇好文章是来自IBM DeveloperWorks的Web Application Security: Testing for Vulnerabilities。
我们可以扫描整个网站的代码来检测SQL注入漏洞吗？是的，有许多代码分析工具可用。哪一个最适合您取决于您使用的代码语言和开发环境。
NIST有一个非常庞大的Source Code Security Analyzers列表。
但即使您使用入侵检测和代码分析工具，也要记住测试的旧智慧：Testing shows the presence, not the absence of bugs.也就是说，任何测试都必然是不完整的，所以不要只依赖于自动化测试。
找到漏洞后，请进行修复。有几种编码技术可以提供帮助：
这些防御措施各有用，但在任何情况下都不起作用，所以你必须学习如何使用它们。
谨慎的代码审查无可替代。基本上，对于任何使用动态内容进行部分查询的SQL查询（即将应用程序变量或任何外部输入复制到SQL字符串中），您必须确保通过其中一种防御方法使内容“安全”。上面列出的。
例如， Perl具有支持此功能的功能。每个Perl变量都有一个被“污染”的元属性，因此不能安全地逐字复制到SQL中（或者作为eval的代码执行，甚至输出到HTML，冒着XSS问题的风险）。如果变量从外部不受信任的内容中获取任何值，则该变量会受到污染。或者，如果变量从另一个受污染的变量中获取其值（它具有传染性）。您可以通过正则表达式匹配函数对变量进行“解开”（这假定您负责制作一个能够消除危险内容的合理正则表达式）。
其他语言没有这个受污染的变量概念，但您可以通过手动分析执行类似操作，跟踪复制到SQL字符串中的每个变量的来源。
始终确保100％的安全性是非常困难的。即使您纠正了应用程序无法处理SQL的99.9％，最后一个案例可能是黑客需要的开放。当然，你的一个无能的开发人员明天可能会引入另一个漏洞。
任何安全计划都必须包含对可疑网站行为的持续监控。许多最糟糕的SQL注入灾难都是如此糟糕，因为他们几个月未被发现，而攻击者却掠夺了宝贵的数据。
因此，您必须保留SQL查询的日志，并观察无效查询的模式。例如，保留应用程序代码运行的已知SQL查询类型的白名单。如果任何SQL查询出现在日志中但与白名单不匹配，则可能是攻击者运行的非法查询。有关此想法的更多信息，请参阅Using the Percona Toolkit to Detect and Even Prevent SQL Injection Attacks。
还有一些SQL注入代理产品，如GreenSQL，可以帮助透明地监控或列入SQL流量白名单。