作者: 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 快速响应 设计是不会完美，你总会遗漏东西，今天一个优秀的设计明天环境变了也许就成了鸡肋，快速响 应才是真的道理。