你能看到以下SQL注入防御方案中的任何漏洞吗？

Question

1. 不要将撇号（'）存储在数据库的字符字段中，而是始终将撇号转换为某些唯一的替代符号，该符号不会被识别为SQL语法，并且不可能是 - 在您的数据中找到或有意义。
2. 当接收来自GET，POST等的直接用户输入时，请始终过滤掉值中的任何撇号，方法是将它们转换为您选择的替代符号。
3. 对于包含用户输入的所有SQL语句，始终围绕文字值包围撇号。例如，像这样：SELECT Name FROM Client WHERE TYPE = '1';。这应该强制所有非撇号字符被视为文字值本身的一部分，无论它们是后引号，花括号，分号，反斜线，正斜线等等。所以像{{1不会以不同的方式解释。
4. 每当将用户输入合并到SQL语句的非文字部分（例如ORDER BY子句中的列名）时，从该值中过滤出标点符号，或者根据预定义的安全集验证它。 / LI>
5. 每当从数据库输出数据（到HTML，XML等）时，总是通过用撇号替换您选择的替换符号来反转此过滤过程，以便客户可以很好地读取数据。

（注意：我们正在使用SQL Server，它不会将反引号符号识别为有效的SQL标点符号，但如果使用MySQL，我们还需要翻译后引号。）

我已经用可以阻止SQL的每个可以想象的符号对此进行了测试，到目前为止它已经经受住了一切。我忽略了什么吗？我想在生产系统上尝试之前得到一些社区反馈。

我们的环境：

• Linux（不是Windows）
• PHP 5.4
• ADOdb版本？ （文档：较旧= http://phplens.com/lens/adodb/docs-adodb.htm;较新= http://adodb.sourceforge.net/）
• Driver =＆＃34; mssql＆＃34;

Answer 1

我不了解MySQL方面的事情，但由于这主要是关于SQL Server，我可以说这种方法不会让你获得任何参数化查询和/或使用存储过程不会产生任何问题的方法。已经得到你了但是，它确实有以下缺点：

1. 实施
需要时间
2. 它使系统更容易出错（即忘记翻译的地方）
3. 由于所有客户都需要知道这种非显而易见的翻译，因此数据不易移植/可导出/可报告
4. 关于执行SELECT Name FROM Cient WHERE TYPE = '1';，如果TYPE字段是数字类型，那么您最多会损害性能，最糟糕的是会出现转换错误
5. 您现在有一个不必要的过于复杂的系统，这将增加培训和支持时间（让新程序员加快速度，找到/解决问题所需的时间等）。

只需使用参数，无论是作为存储过程的输入，还是参数化的即席SQL语句。如果使用.NET，则在两种情况下都使用SqlParameter。

ADOdb 支持参数化查询和存储过程（本质上参数化）。请参阅：

• http://phplens.com/lens/adodb/docs-adodb.htm#prepare和
• http://phplens.com/lens/adodb/docs-adodb.htm#preparesp

他们甚至提到PDO（转到这里及其下一小节：http://phplens.com/lens/adodb/docs-adodb.htm#connect_ex），但我不确定这是否有用或无用。这里还提到了PDO：http://adodb.sourceforge.net/docs-adodb.htm#php5。