我的网站最近遭到攻击,在我看来是一个无辜的代码:
那里没有SQL调用,所以我不怕SQL注入.但是,显然,SQL不是唯一的注入方式.
本网站有一个解释和一些避免代码注入的例子:http://www.theserverpages.com/articles/webmasters/php/security/Code_Injection_Vulnerabilities_Explained.html
你如何保护代码注入代码?
使用白名单并确保该页面位于白名单中:
$whitelist = array('home', 'page'); if (in_array($_GET['page'], $whitelist)) { include($_GET['page'].'.php'); } else { include('home.php'); }
清理输入的另一种方法是确保只有允许的字符(没有"/",".",":",...).但是,不要将黑名单用于坏字符,而是使用允许字符的白名单:
$page = preg_replace('[^a-zA-Z0-9]', '', $page);
...后跟file_exists.
这样你就可以确保只执行你想要执行的脚本(例如,这将排除"blabla.inc.php",因为"."是不允许的).
注意:这是一种"黑客",因为那时用户可以执行"home"并且它会给出"home"页面,因为它只是删除所有禁止的字符.它并不是要阻止想要对你的页面进行可爱的东西的"聪明人",但它会阻止人们做出非常糟糕的事情.
BTW:你可以做的另一件事.htaccess文件是为了防止明显的攻击企图:
RewriteEngine on RewriteCond %{QUERY_STRING} http[:%] [NC] RewriteRule .* /–http– [F,NC] RewriteRule http: /–http– [F,NC]
这样,所有使用"http:"url(和查询字符串)的页面访问都会导致出现"Forbidden"错误消息,甚至无法访问php脚本.这导致较少的服务器负载.
但请记住,查询字符串中不允许使用"http".您的网站可能在某些情况下可能需要它(可能在填写表格时).
顺便说一句:如果你能读懂德语:我也有关于该主题的博客文章.
接受用户输入时的#1规则始终对其进行清理.在这里,您没有在将页面GET变量传递给include之前对其进行清理.在包含文件之前,您应该执行基本检查以查看服务器上是否存在该文件.
Pek,有很多事情要担心增加sql注入,甚至不同类型的代码注入.现在可能是进一步了解Web应用程序安全性的好时机.
从之前关于从桌面移动到Web开发的问题,我写道:
构建安全Web应用程序和Web服务的OWASP指南应该是任何希望认真对待安全性的Web开发人员(应该是所有 Web开发人员)的必读内容.有许多原则可以帮助考虑安全性时所需的思维方式.
如果阅读一份大文件并不适合你,那么请看看Mike Andrews几年前在谷歌如何打破网络软件的研讨会视频.