易栈网-膘叔

昨天说的是限制的BUG，今天说的是评论的BUG
好象sablog最近屡屡被人强暴？
论坛里也有N多人在感叹被攻击

目前有几种解决方法
1、关闭评论（模版里删除相应的代码，同时，在post.php的第211行把if($_POST['action'] == 'addcomment') { 改成其他的）

2、等待官方的解决方案

3、考虑换验证码程序？

4、禁止用户注册

5、如果实在受不了。。。换wp或者其他的吧

——————————————————————————————————————————

当然也有其他的，只是目前不想说。

一次误操作，发现了sablog的一个小BUG，或许这个BUG平时 很多人遇不到吧。

由于最近一些评论实在太多，我就加了IP限制，不过，我并没有加上*来做IP段的限制，我都是一个IP一个IP添加的。为了添加方便，我直接在最后的IP后面加了一个“,”，结果导致我自己也不能评论了。提示我，我的IP在屏蔽列表内。

看来这就是SA的一个小BUG了，没有把为空的数据过滤掉，

PHP的函数：array_filter，就可以了啦。HOHO

不过，平时确实感觉不出来。。。勉强算个BUG吧。

但我想还有一些垃圾评论的关键字，如果也用了这个，那。恐怕别人也回复或者评论不了了。。。

BTW：刚解禁，就发现后台有了几条来自同一IP的垃圾评论。唉。。。

(再BTW:好象最近SA被人攻破了？官方论坛上很多人在抱怨了。。。看来如果Sa不解决这个问题，就要被人BS了。。。如果一个月内不解决。恐怕我也会考虑换wp了)

原文来自：http://www.phpv.net/html/1653.html
作者是：扶凯

内容如下：
注意,经测试,本情况发生在少量配置有问题的服务器上.一般正式版apache无此问题.

一般的网站都会开放rar附件上传,并可能会保留原来文件名称,这从而可能导致一个很严重的问题,xxx.php.rar文件会被Apache当作php文件来执行, 造成极大的安全隐患 .

如何测试? 将你的某个php程序文件后缀名修改成  xxx.php.rar , 这时测试一下, 还是按照PHP文件解析执行,Apache并不会认为这是一个rar文件, 这是为什么呢?

原 来,每遇到一种后双重后缀名(如xxx.php.rar)的文件,Apache都会去conf/mime.types 文件中检查最后一个后缀, 如果最后一个后缀并没有在mime.types文件中定义, 则使用前一个后缀来解释 , 因为在默认情况下,rar并未在mime.types中定义, 故Apache会使用php后缀来解释文件, 这就是漏洞的原因所在.

由此类推,如果使用xxx.jsp.ppp.rar 则会认为是jsp文件, 如果修改成xxx.shtml.rar ,则会识别成shtml文件.

a.php.c.d.e.rar 也是会被当成PHP文件解释的!
想想,不知道有多少网站存在这个问题?

那么针对网络管理员,如何杜绝这个隐患 ?
1.修改mime.types文件,在最后面加一条:
application/rar            rar
然后重新启动Apache,即可.

针对WEB管理员及WEB程序开发者,如何更安全?
1.只允许上传指定后缀名的文件,当然,要禁止掉rar格式文件上传.(但这条往往行不通,一般的网站都需要上传rar文件)
2.对上传后的文件进行强制重命名, 强制使用最后一个扩展名,如原始文件名为xxx.php.rar ,上传后强制重命名为 20080912.rar即可避免这个隐患.

早期版本的phpcms 2007, discuz, ecshop都存在这个漏洞,  或许你的网站被挂马,就是因此引起.

上面的文章是转的，我测试了一下,还真这样,不过修改mime.types是没有用的.

需要在http.conf中加入下面这些内容

AddType application/rar .rar
AddType application/x-compressed .rar
AddType application/x-rar .rar
AddType application/x-rar-compressed .rar
AddType application/x-rar-compressed; application/x-compressed .rar
AddType compressed/rar; application/x-rar-compressed .rar 
 

这样就不会出问题了，测试过了，加我上面这些是没有问题的。

听闻有这样的漏洞，不管怎么样，都放上来，与大家一起分享一下，同时也请你自己检测一下自己的apache，如果你用的虚拟主机有这样的漏洞，那么也尽早通知他们一声，与人方便与己方便。
我自己没有测试过，所以不知道是否存在这个漏洞。

PHP版本一直在更新，同样我们的代码也会随着服务器上的PHP版本的更新而不得不进行更改，但每次PHP的更新，几乎只是显示fix了多少多少BUG，但究竟会在版本升级的时候带来哪些问题，自己一点也不清楚 。

其实翻开PHP的手册，你也能找到这些，现在方便了，到我的博客上下载乔楚编译的最新的手册，翻开左侧树的最后一个节点：Appendices，找到：

展开这三个节点，你会看到在版本更新的时候，PHP的核心加了哪些方法，去除了哪些函数（事实上这很重要，或许在你以前的项目里一直在采用XXX方法，但新版本去掉了，很可能你的程序就不能再运行了。。。）

当然你更应该看的是：Changes in reference handling，这里面介绍的是一些老的代码写法和应用在新的代码里会出错的例子，如果你的代码里沿用了这些旧的方法，那么，你先考虑一下升级的代价吧。

刚才打开google reader的时候，突然看到一篇文章，让俺大吃一惊呀。详细内容如下：

然后有人回复为：

联想起以前写CRUD之类的东西时候，在过滤条件时，自动将空值直接unset掉，然后再拼成SQL，后来被BOBBY严厉批评了一下，确实，查询的时候感觉不出有什么问题，可如果是在UPDATE或者是DELETE的时候呢？本来是有条件的，可突然被unset掉成为没有条件了，那岂不是很恐怖？

借这个机会再次提醒自己，细心、周全、小心