Submitted by gouki on 2009, June 15, 9:46 PM
昨天说的是限制的BUG,今天说的是评论的BUG
好象sablog最近屡屡被人强暴?
论坛里也有N多人在感叹被攻击
目前有几种解决方法
1、关闭评论(模版里删除相应的代码,同时,在post.php的第211行把if($_POST['action'] == 'addcomment') { 改成其他的)
2、等待官方的解决方案
3、考虑换验证码程序?
4、禁止用户注册
5、如果实在受不了。。。换wp或者其他的吧
——————————————————————————————————————————
当然也有其他的,只是目前不想说。
Tags: sablog, bug
PHP | 评论:0
| 阅读:18466
Submitted by gouki on 2009, June 14, 9:45 AM
一次误操作,发现了sablog的一个小BUG,或许这个BUG平时 很多人遇不到吧。
由于最近一些评论实在太多,我就加了IP限制,不过,我并没有加上*来做IP段的限制,我都是一个IP一个IP添加的。为了添加方便,我直接在最后的IP后面加了一个“,”,结果导致我自己也不能评论了。提示我,我的IP在屏蔽列表内。
看来这就是SA的一个小BUG了,没有把为空的数据过滤掉,
PHP的函数:array_filter,就可以了啦。HOHO
不过,平时确实感觉不出来。。。勉强算个BUG吧。
但我想还有一些垃圾评论的关键字,如果也用了这个,那。恐怕别人也回复或者评论不了了。。。
BTW:刚解禁,就发现后台有了几条来自同一IP的垃圾评论。唉。。。
(再BTW:好象最近SA被人攻破了?官方论坛上很多人在抱怨了。。。看来如果Sa不解决这个问题,就要被人BS了。。。如果一个月内不解决。恐怕我也会考虑换wp了)
Tags: sablog, bug
PHP | 评论:0
| 阅读:17695
Submitted by gouki on 2008, December 19, 8:17 PM
原文来自: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,如果你用的虚拟主机有这样的漏洞,那么也尽早通知他们一声,与人方便与己方便。
我自己没有测试过,所以不知道是否存在这个漏洞。
Tags: apache, mimetype, rar, php, bug
Linux | 评论:0
| 阅读:24012
Submitted by gouki on 2008, October 12, 10:00 PM
PHP版本一直在更新,同样我们的代码也会随着服务器上的PHP版本的更新而不得不进行更改,但每次PHP的更新,几乎只是显示fix了多少多少BUG,但究竟会在版本升级的时候带来哪些问题,自己一点也不清楚 。
其实翻开PHP的手册,你也能找到这些,现在方便了,到我的博客上下载乔楚编译的最新的手册,翻开左侧树的最后一个节点:Appendices,找到:
展开这三个节点,你会看到在版本更新的时候,PHP的核心加了哪些方法,去除了哪些函数(事实上这很重要,或许在你以前的项目里一直在采用XXX方法,但新版本去掉了,很可能你的程序就不能再运行了。。。)
当然你更应该看的是:Changes in reference handling,这里面介绍的是一些老的代码写法和应用在新的代码里会出错的例子,如果你的代码里沿用了这些旧的方法,那么,你先考虑一下升级的代价吧。
Tags: 升级, bug, 解决方案
PHP | 评论:0
| 阅读:24277
Submitted by gouki on 2008, July 30, 8:42 PM
刚才打开google reader的时候,突然看到一篇文章,让俺大吃一惊呀。详细内容如下:
原文网址:http://www.cnblogs.com/xinerzhui/archive/2008/07/30/1256648.html
- 请谨慎注意这一微软SQLBug
- 刚来博客园,有什么不对,需要改进的地方,欢迎各位同道指出来,谢谢。
- 今天在使用数据库时出现意外操作,将一张表的数据删除了。仔细查看SQL语句,发现问题。将问题类推到Northwind中。我们使用两个表,Employees和Products
- SQL语句如下:
- select * from Products where CategoryID in (select CategoryID from Employees)
- 不看表结构是看不出什么问题的,不清楚的看一下表结构。执行上面的SQL语句,你将能看到所有的产品记录。
- 当你执行上面语句的"select CategoryID from Employees",将会提示一个错误提示:
- 消息 207,级别 16,状态 3,第 1 行
- 列名 'CategoryID' 无效。
- 表Employees中根本就没有CategoryID列,而微软忽略了括号中的错误,执行前面的语句。如果是应用在删除,更新,那后果将是不可现象的。我曾为此付出了代价。
- 这个应该就是微软SQL的BUG吧,我们需要特别注意。
- 在SQL2000企业管理器,SQL2000的查询分析器,SQL2005的Management Studio Express中均有此Bug。
然后有人回复为:
#2楼 2008-07-30 17:21 | 熊呜呜
我在Sql2000上测试,确实有这个问题。
#3楼 2008-07-30 17:27 | ocean
- 有意思的问题,在我的management studio里面查询,也会有这个问题,要好好地研究一下。
#7楼 117.22.68.*2008-07-30 17:45 | johnnyshieh [未注册用户]
- Microsoft SQL Server Management Studio 9.00.1399.00
- 有楼主说的问题!
- 确实应该注意一下。
#9楼 2008-07-30 17:55 | 金色海洋(jyk)
- 看了表结构才知道,Employees 表里面没有 CategoryID字段。为什么不报错呢。错误被吃掉了。
-
- select * from Products where CategoryID in (select CategoryID from Employees)
-
- select * from Products where CategoryID in (select EmployeeID from Employees)
-
- 我比较了一下这两个语句的执行计划,不完全一样。建议lz分析一下执行计划。
- 因为我还不能完全看懂执行计划。只能看出来两个执行计划是不一样的。呵呵。
在MYSQL里没有试会不会遇到这种情况,我用navicat试是没有这种情况的。不知道其他的会不会有。
联想起以前写CRUD之类的东西时候,在过滤条件时,自动将空值直接unset掉,然后再拼成SQL,后来被BOBBY严厉批评了一下,确实,查询的时候感觉不出有什么问题,可如果是在UPDATE或者是DELETE的时候呢?本来是有条件的,可突然被unset掉成为没有条件了,那岂不是很恐怖?
借这个机会再次提醒自己,细心、周全、小心
Tags: mssql, sqlserver, microsoft, sql, bug
DataBase | 评论:0
| 阅读:20706