在 .htaccess 中阻止 SQL 注入有什么危险？

Question

我一直在寻找我的 Wordpress 网站上的防御措施。毫不奇怪，有大量关于这个主题的文档。这里似乎有两个更好的指南：

http://moz.com/blog/the-definitive-guide-to-wordpress-security

显然：http://codex.wordpress.org/Hardening_WordPress

我想加强对 SQL 注入的防御，因为我以前的网站成为此类攻击的受害者，并且几乎无法再次清理。

从许多其他网站上发布的 cmets 和类似指南来看，似乎有很多人不同意实现这一目标的每一种方法，就像他们发誓一样。

我正在考虑将以下内容（在第一个提到的网站上找到）添加到我的网站，但除了编辑您的 @987654324 的明显危险之外，似乎没有人谈论 这样做的危险 @ 文件。

添加此功能可能会丢失或损害哪些功能，如果没有，为什么基本 Wordpress 安装中不包含此类代码？如果添加这种东西没有害处，为什么不是每个安装都包含它，并允许知道自己在做什么的开发人员在必要时将其删除？？

    ## SQL Injection Block ##
<IfModule mod_rewrite.c>
RewriteBase /
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC]
RewriteRule ^(.*)$ - [F,L]
RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]
RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]
RewriteCond %{QUERY_STRING} tag\= [NC,OR]
RewriteCond %{QUERY_STRING} ftp\:  [NC,OR]
RewriteCond %{QUERY_STRING} http\:  [NC,OR]
RewriteCond %{QUERY_STRING} https\:  [NC,OR]
RewriteCond %{QUERY_STRING} (\|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)||ê|"|;|\?|\*|=$).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*("|'|<|>|\|{||).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%24&x).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F|127\.0).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(request|select|insert|union|declare).* [NC]
RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$
RewriteRule ^(.*)$ - [F,L]
</IfModule>

鉴于我有限的 SQL 知识，我担心会破坏数据库搜索功能，例如基于 URL 的查询 （例如在 wp-admin 中，例如 users.php?s=rachel&action=-1&new_role&paged=1&action2=-1

简而言之：

• 我的主要问题是在.htaccess 中限制 SQL 注入有什么危险，即 wordpress、函数或插件是否依赖于能够通过此类操作更改数据库。我有一个自定义主题并使用自定义php 在很多页面上，但总是使用已知的 wordpress 函数来添加数据，而不是直接写为 SQL 查询或编辑。

和

• 它是否会阻止在这种实例“How can I prevent SQL injection in PHP?”中使用的攻击（即，当您编写了这种 POST 代码时，为了节省读取——修改表单以将 SQL 注入数据库。）

  if (isset($_POST['Dropdownmenu'])) {
  update_post_meta($postID , 'meta_value' , $thedropdownvalue );
  

Answer 1

这没有用，原因如下：

1. 不可能定义规则来捕获所有可能的注入。为了安全，您仍然需要在应用程序代码（即绑定参数）中进行适当的防御。如果您的代码得到适当保护，则无需进行此 URL 过滤。

2. 这只会过滤 URL。 SQL 注入也可能来自 POST 变量。如上所述，您需要在应用程序代码中进行防御。

3. 规则很可能会非常广泛以阻止合法流量（例如，/article.php?title=us-declares-war 会被给定规则之一阻止）。