从trackback说起

作者: sadly 出自: http://www.phpx.com

前两天在网上逛的时候看到了关于blog里trackback的资料,发现它在设计上是有隐患的,
后来还给某几个知名的网站发了点纪念品, 惹得人家直说我早就知到了,不过这关你屁事.
我对口水战没有什么兴趣. 在此说一点程序设计中我个人认为应该考虑的问题,希望
能够抛砖引玉一下.

1 连续的数字id
使用数字id来标识一篇资料,比如blog的文章, 这当然最简单,最容易实现的. 因为我们设计
数据库的时候通常都会加一个自增长的id来做唯一标志. 用id来标识很直接, 也不需要
额外的存储空间. 不过这显然不是一个很安全的方式, 象村子用的DZ这个程序
viewthread.php?tid=文章编号 是看帖子.只要跑一个循环就可以把全部的文章都抓到了.被
人抓站当然是难免了,但要是被人乱发帖恐怕就不那么舒服了.

大家都知道数据库对读是有优化的, 而对于写所能做的事情则很有限. 想一想, 如果有个
程序不停的发帖, 数据库记录疯涨 ,数据不断更新, 那你设计的静态化之类的恐怕是没
什么效果了.

假如, 我们在数据库里加一个字段 ukey , 设计为唯一的标志, 数据取个随机数好了
当然最好是字母数字混和的长字符串.
现在用 (for $i=起始id;$i<终止id;$i++) 回复第$i个文章 的办法显然是不行了. 不过还是有办法的. 它可以先抓列表页,然后分析出每个文章的ukey, 之后 再 (for $i=起始值;$i<要发送的数量;$i++) 回复第$all_ukey_array[$i]个文章. 于是, 我们在回帖的时候给每个文章加上不同的随机识别码. 好了. 现在它只好先抓到 列表页, 然后再抓具体页面并分析出这个文章对应的识别码. 最后 再 ($i=起始值;$i<要发送的数量;$i++) 用识别码$all_seccode_array[$i] 回复第$all_ukey_array[$i]个文章 看来还是没有解决, 图形验证码浮出了水面, 它确实够安全, 可是图形验证码对于正常使 用的用户是不够友好的, 如果每次发帖都要输一个讨厌的验证码那用户就没什么兴趣了. 算了,还是放弃它, 用户看一篇文章会看多久然后回复它呢? 3分钟? 5分钟? 把随机识别 码加上一个有效时间. 看起来好多了. 当你用一个连续的数字id做唯一标志又没有其他限制的时候, 估计每秒钟发个几十帖 是没问题的. 你把id变成一个随机的ukey以后, 大概能减慢不少了. 如果再加上其他的验证限制, 降到每秒几个看来是不成问题的. 它如果是不停的发新帖呢? 压根没什么ukey, 当然你也可以产生一个随机识别码:) 因为不用抓列表再抓识别码发帖的速度一下子又快起来... 2 正常行为和异常行为 一个正常的用户每秒钟能打多少个字? 按多少次拷备/粘帖键? 如果一个用户1秒钟发了10个文章......(限制一下每30秒只允许发一帖?)... 如果一个用户3分钟发了6个文章,每个文章都有2000字......(很勤劳的转贴者啊)... 如果一个用户6分钟里发了12个文章,但标题或者内容都一样长......(算这么准,数学博士?)... 如果一个用户连续1个小时都在发文章......(绝对应该得五一劳动奖章)... 3 黑名单 IP (可以用代理服务器啊),用户名(可以注册很多个啊),关键词(本来也是随便写的啊)...... 看起来作用有限啊.... 4 局部?整体? 如果一个文章是$user发布的 这样的回帖路径 blog.abc.com/$user/reply/$id 和这样的回帖路径 blog.abc.com/reply/$id 显然威胁是不大一样的,一个是局部,一个是整体。 5 菜鸟乐园? 操做系统的某某漏洞本来是个高级的玩意,等到攻击器满天飞的时候就不是个别人的私家玩具了。 网站也一样,把程序设计到用十分钟写一段js就能把系统搞的乱七八糟, 和需要花两天写个程序还要考虑什么随机数,多线程,代理服务器之类的是不大同的。 6 do it 服务既然要公开提供给用户总是有办法来破坏,就随它去吧? 一个水桶底上少块木板和有一个虫子眼一样么? 7 完美设计 vs 快速响应 设计是不会完美,你总会遗漏东西,今天一个优秀的设计明天环境变了也许就成了鸡肋,快速响 应才是真的道理。

发表评论

电子邮件地址不会被公开。 必填项已用*标注