sadly
(sadly)
管理员
 
管理员
UID 1
精华
4
积分 2033
帖子 2023
金钱 1540 喜悦币
威望 40
人脉 453
阅读权限 200
注册 1970-1-1
来自 北京 三元桥
状态 离线
|
[广告]: 代充Paypal帐号美元
从trackback说起
前两天在网上逛的时候看到了关于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 快速响应
设计是不会完美，你总会遗漏东西，今天一个优秀的设计明天环境变了也许就成了鸡肋，快速响
应才是真的道理。
| 
以PHP在中国的繁荣发展为己任
QQ:824008 MSN:sadly@phpx.com |
|
