在.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

简而言之:

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

和

• 它会阻止在这种实例中使用的攻击吗？ " 如何在PHP中阻止SQL注入？ "(即保存读取 - 修改表单以便在编写此类POST时将SQL注入数据库.)

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

Answer 1

这没用,原因如下:

1. 无法定义规则以捕获每种可能的注入.您仍然需要在应用程序代码中使用适当的防御(即绑定参数)才能确保安全.如果您的代码得到妥善保护,则不需要此URL过滤.

2. 这只会过滤网址.SQL注入也可能来自POST变量.如上所述,您需要在应用程序代码中使用防御来防御它.

3. 规则很可能是如此宽泛以至于阻止合法流量(例如,/article.php?title=us-declares-war将被某个给定规则阻止).