关于CSRF && XSS && DDOS 等常见攻击的若干描述
2013-11-24 22:45 Quenteen.Fix 阅读(600) 评论(0) 编辑 收藏 举报题记:最近碰到了这些问题,仔细的想了想危害,
猛然发现,挺严重的。
开个题,后面补上内容。
2013-11-25补第一篇章 -- CSRF
一、关于yii里面生成CSRFToken的逻辑和流程:
CSRF - 跨站伪造请求攻击(具体含义谷百一下)
粗略来说,就是你在某个劣质网站A上,点了一个GET或POST到某高品质有账户的网站B的链接请求,
【以最坏的情况来考虑A的意图:这个链接请求是A故意伪造的、并且可以修改B中账户信息的一个链接】
如果B站没有CSRF验证,那么A站伪造的这个请求就可以携带你的账户信息直接访问一个不在你意图内的B的链接,从而对账户造成冲击。
如果有CSRF验证,那么即使A伪造了这个链接,但由于这个post请求中的 csrf token 值是错误的,那么这个伪装请求也不会生效。
yii里面是支持开启csrf验证的,当post提交的表单数据与当前生成的csrf token不一致时,
会在CHttpRequest的onBeginRequest中,被validateCsrfToken方法给提前终止掉,并返回错误代码400: the csrf token could not be verfied。
所以从上面的流程中,我们知道了被比较的一方是post提交过来的 token,那比较的一方又是从哪里取来的呢?
很简单。
通过读写cookie来中转,cookie中YII_CSRF_TOKEN对应的值就是csrf token,具体的生成方法如下:
1 protected function createCsrfCookie() 2 { 3 $cookie=new CHttpCookie($this->csrfTokenName,sha1(uniqid(mt_rand(),true))); 4 if(is_array($this->csrfCookie)) 5 { 6 foreach($this->csrfCookie as $name=>$value) 7 $cookie->$name=$value; 8 } 9 return $cookie; 10 }
由上可以看出,生成token的策略是:sha1(uniqid(mt_rand(), true)),具体的加密方式,可私下探索一下,但很难被复现是一定的。
获取csrf token的方式如下:
1 public function getCsrfToken() 2 { 3 if($this->_csrfToken===null) 4 { 5 $cookie=$this->getCookies()->itemAt($this->csrfTokenName); 6 if(!$cookie || ($this->_csrfToken=$cookie->value)==null) 7 { 8 $cookie=$this->createCsrfCookie(); 9 $this->_csrfToken=$cookie->value; 10 $this->getCookies()->add($cookie->name,$cookie); 11 } 12 } 13 14 return $this->_csrfToken; 15 }
由上可以看出,当cookie中有token值时,那么获取的token就不会发生变化,在同一个浏览器下,即使你退出当前登录、切换用户、重启浏览器,
除非你手动删除这个cookie,否则这个token会一直保持不变。
注意,这里就应该注意了,因为我要联合XSS一起来讲这个东西的危害性了。
第二节 XSS攻击 - 跨站脚本攻击
所谓脚本攻击,那无非就是网站C的某个页面能执行第三方的js。
执行js的威力就大了,光获取C站的cookie信息就足以吓尿你。
结合XSS和CSRF来举例说明:
首先黑客Bob在C站上植入了XSS的攻击,获取了登录人Mike在C站的所有cookie信息,
然后,伪造一个修改C站账户名(或者财务金钱方面)的url来递交post请求,如果Mike点击了这个链接,
那么,Bob就相当于用Mike的账号完成了一条Mike可能都不知道的账户操作,
随大流的说法就是,Bob在不知道Mike账号的前提下,默默的让Mike从他的账户上转了¥5000到Bob的账户上,我艹,5000米!!
综合上述来说:
1、CSRF是一个网站最基本的验证,否则post请求可以随便被人构造,从而对注册用户的信息造成攻击
2、XSS是网站必须防御的,因为没有它,其实第一条也就失去了它的意义。
好了,关于这些,有补充的,我再慢慢补。。。
某哥说:白天好好完成工作,晚上好好研究技术。这个嘛,在理!