在.htaccess中阻止SQL注入的危险是什么?

Question

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

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

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

我想加强我对SQL注入的防御，因为我以前的网站成为了这种攻击的受害者，并且几乎不可能再次清除。

从许多其他网站和类似指南上的评论来看，似乎有很多人不同意每一种实现这一目标的方法，因为有很多人发誓。

我正在考虑在我的网站上添加以下内容(在第一个提到的网站上找到)，但似乎没有任何地方讨论做这种操作的危险除了编辑.htaccess文件的明显危险之外。

添加这个代码会损失什么功能，如果没有，为什么不把这类代码包含在基本的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查询或编辑。

和

• 它会阻止在这种情况下使用的攻击"我如何在PHP中防止SQL注入?"(即。为了节省阅读——修改表单以将SQL注入数据库，当您编写了这种POST。

  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将被给定的规则之一阻止)。