防止 SQL 注入的 Htaccess 和 Mysqli 方法之间的区别

Posted 2023-02-19

【中文标题】防止 SQL 注入的 Htaccess 和 Mysqli 方法之间的区别

【英文标题】：Difference between Htaccess and Mysqli methods preventing SQL injections

【发布时间】：2018-01-29 19:15:33

【问题描述】：

我想保护我的 WordPress 博客免受 SQL 注入。

我有许多 php 自定义页面，其中包含对数据库和自定义非 wordpress 表的查询。

我知道我可以使用 2 种方法：

1) mysqli 或 PDO 用于准备好的语句和参数化查询。

2) htaccess 规则如下：

RewriteCond %QUERY_STRING [a-zA-Z0-9_]=http:// [OR]

RewriteCond %QUERY_STRING [a-zA-Z0-9_]=(\.\.//?)+ [OR]

RewriteCond %QUERY_STRING [a-zA-Z0-9_]=/([a-z0-9_.]//?)+ [NC,OR]

RewriteCond %QUERY_STRING \=PHP[0-9a-f]8-[0-9a-f]4-[0-9a-f]4-[0-9a-f]4-[0-9a-f]12 [NC,OR]

RewriteCond %QUERY_STRING (\.\./|\.\.) [OR]

RewriteCond %QUERY_STRING ftp\: [NC,OR]

RewriteCond %QUERY_STRING http\: [NC,OR]

RewriteCond %QUERY_STRING https\: [NC,OR]

RewriteCond %QUERY_STRING \=\|w\| [NC,OR]

RewriteCond %QUERY_STRING ^(.*)/self/(.*)$ [NC,OR]

RewriteCond %QUERY_STRING ^(.*)cPath=http://(.*)$ [NC,OR]

RewriteCond %QUERY_STRING (\<|%3C).*script.*(\>|%3E) [NC,OR]

RewriteCond %QUERY_STRING (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]

RewriteCond %QUERY_STRING (\<|%3C).*iframe.*(\>|%3E) [NC,OR]

RewriteCond %QUERY_STRING (<|%3C)([^i]*i)+frame.*(>|%3E) [NC,OR]

RewriteCond %QUERY_STRING base64_encode.*\(.*\) [NC,OR]

RewriteCond %QUERY_STRING base64_(en|de)code[^(]*\([^)]*\) [NC,OR]

RewriteCond %QUERY_STRING GLOBALS(=|\[|\%[0-9A-Z]0,2) [OR]

RewriteCond %QUERY_STRING _REQUEST(=|\[|\%[0-9A-Z]0,2) [OR]

RewriteCond %QUERY_STRING ^.*(\[|\]|\(|\)|<|>).* [NC,OR]

RewriteCond %QUERY_STRING (NULL|OUTFILE|LOAD_FILE) [OR]

RewriteCond %QUERY_STRING (\./|\../|\.../)+(motd|etc|bin) [NC,OR]

RewriteCond %QUERY_STRING (localhost|loopback|127\.0\.0\.1) [NC,OR]

RewriteCond %QUERY_STRING (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]

RewriteCond %QUERY_STRING concat[^\(]*\( [NC,OR]

RewriteCond %QUERY_STRING union([^s]*s)+elect [NC,OR]

RewriteCond %QUERY_STRING union([^a]*a)+ll([^s]*s)+elect [NC,OR]

RewriteCond %QUERY_STRING (;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode) [NC,OR]

RewriteCond %QUERY_STRING (sp_executesql) [NC]

RewriteRule ^(.*)$ - [F,L]

使用 htaccess 方法将非常容易和快速。使用这个有缺点吗？

【问题讨论】：

这绝对是特定于实现的。

使用准备好的语句。它更容易，并且适用于任何类型的数据。 （$POST、$GET 等）

@GrumpyCrouton 看到有人支持您的评论，$POST/$GET 应该真正展示真正的superglobals 是$_POST/$_GET，因为有些人可能认为（甚至是OP）$POST, $GET 是正确的语法。评论应该被编辑。编辑：现在无法编辑。请使用正确的语法，这样对每个人都更有帮助，也更清楚。

我可以看到这种类型的实现限制了想要的数据而不是阻止 SQL 注入。

您的 htaccess 可能会阻止某些可用于 sql 注入的查询，但无法判断它是否在所有情况下都能成功。另一方面，对于准备好的语句，您会知道使用的变量肯定会被转义。

【参考方案1】：

如我所见，您将您认为有害的事物列入黑名单。我不相信这一点，因为您可能会忘记某些事情或将来可能会出现其他违规行为，并且您不会记得将其添加到文件中。

更好的方法是将你知道没问题的东西列入白名单，但我不知道在 htaccess 中是否可行。

我认为理想的方法是 cmets 中建议的方法。为 PDO 或 mysqli_real_escape_string() 和/或 settype() 为 mysqli 扩展使用准备好的语句。

【参考方案2】：

使用 Prepared Statement 是防止网站遭受 SQL 注入 的最佳解决方案，因为正如您所说 您可以使用 htacess 属性，但这不是保护您的网站免受 sql 注入的最佳方法。 htacess 仅有助于防止基于 URL 的注入，但通过使用 Prepared Statement 它将帮助您防止所有类型的 sql 注入

这样做之后

您还可以使用pentesterking.com 测试您的网站安全性或漏洞

【参考方案3】：

您的 htaccess 可能会阻止某些可用于 sql 注入的查询，但无法判断它是否在所有情况下都会成功 - 而且很可能不会。

另一方面，对于准备好的语句，您会知道使用的变量肯定会被转义。

htaccess 规则甚至可能阻止有效输入，例如如果您有一个维护 SQL 代码的应用程序，并且您希望允许用户搜索查询，那么查询包含您在 htaccess 中过滤的字符串可能是完全有效的。

为此目的使用 htaccess 规则很难维护，容易出错，最糟糕的是，如果您查看代码，您永远无法确定传递给查询的变量是否无害。您将始终需要检查所有可能的方式来使用该变量，并检查是否以这种方式对其进行了修改，以任何可能导致任何恶意的方式。

准备好的语句和任何其他验证方法的想法是，在尽可能接近使用它们的地方执行它们。这是保持代码可维护性的唯一方法，因为您只需要查看一小部分代码即可检查它是否有效。