白帽子讲web安全之 跨站点请求伪造(CSRF)
(有些内容纯属个人理解,如有错误请不吝指正)
CSRF简介
- 本质:
在用户不知道的情况下,攻击者猜解出了一个正确的url,伪造访问请求并且成功访问了此url下的内容。
浏览器的cookie策略
在攻击者进行CSRF攻击时,会遇到一个问题,即要做到成功访问某些页面是需要认证的。这就涉及了cookie。
cookie分为:Session Cookie 和 第三方cookie
Session Cookie: 又称为“临时Cookie",这类Cookie没有指定的存在时间,保存在浏览器的内存空间中,当浏览器关闭后,这个Cookie也就失效了;
第三方Cookie: 又称为”本地Cookie“,这类Cookie在服务器设置时指定了存在的时间,保存在本地,只有到了时间才会失效;
在有些浏览器中,默认策略是允许发送第三方Cookie,这就很容易导致攻击者的利用;
而在另外一些浏览器中,默认禁止了在<img>、<iframe>、<script>、<link>等标签中发送第三方Cookie;虽然可以在一定程度上保证安全性,但是当攻击者诱使用户在当前浏览器中先访问目标站点使Session Cookie有效,依旧可以实施CSRF攻击;
P3P头的副作用
P3P Header 标准的出现再一词动摇了”利用浏览器拦截第三方Cookie来拒绝CSRF攻击“的可靠性;
- P3P作用
主要用于类似广告等需要跨域访问的页面:当网站返回给浏览器的HTTP头中包含有P3P头,将允许浏览器在任何地方发送第三方Cookie; - 注意
P3P头只要由网站设置一次即可,之后每次请求都会遵循这个策略,不需要再重复设置;(所以如果被利用是很可怕的事情)
Flash CSRF
其实就是Flash通过各种方式发起网络请求
- 注意
在IE 6和IE 7中,Flash发送的网络请求还可以带上本地Cookie,但在IE 8中已经禁止;
CSRF Worm
百度用户中心的一个漏洞展现了如何利用CSRF发起蠕虫攻击:
漏洞出现在百度用户中心的发送短消息功能中:
https://msg.baidu.com/?ct=22&cm=MailSend&tn=bmSubmit&sn=用户账户&co=消息内容
只要修改参数sn,即可对指定的用户发送短消息,而百度的另外一个接口则可以查询出来某个用户的所有好友:
https://frd.baidu.com/?ct=28&un=用户账户&cm=FriList&tn=bmABCFriList&callback=gotfriends
利用这两个漏洞,就可以形成一个CSRF Worm——让一个百度用户查看恶意页面后,给他的所有好友发送一条短消息,然后这条短消息中又包含一张图片,其地址再次指向CSRF页面,使得这些好友再次将消息发送给他们的好友,这个Worm得以传播。
- 注:病毒、蠕虫和木马的区别
- 首先蠕虫可以说是一种特殊的病毒,它具有病毒的大部分共性,但又有自己的一些特性,可是说是一种更强大的病毒;而木马与病毒蠕虫最大的不同就是,木马一般情况下不可以自我复制和传播,但是病毒最大的特点就是自行执行和复制传播;
- 其次看蠕虫和病毒的区别: 普通病毒需要传播受感染的驻留文件来进行复制,而蠕虫不使用驻留文件即可在系统之间进行自我复制, 普通病毒的传染能力主要是针对计算机内的文件系统而言,而蠕虫病毒的传染目标是互联网内的所有计算机。同时,蠕虫很容易造成网络带宽的极大浪费,从而造成网络瘫痪;
- 大体上说,病毒破坏你的信 息,而木马窃取你的信息
CSRF的防御
1.验证码
这是针对了CSRF的其中一个特点来进行防护:CSRF是在用户不知情的情况下发生的,而验证码则要求必须有用户进行交互,在一定程度上防御了CSRF攻击;
但是必须意识到:这是治标不治本的,过多设置验证码势必会影响用户体验;
2.Refer Check
由于Refer头表示了请求的来源,那么我们可以通过检查Refer头来确定请求是否来自合法的”源“;
这个策略的缺陷在于:服务器并非在任何时候都可以取到Refer头
3.Anti CSRF Token
- CSRF的本质
CSRF成功的本质原因在于重要操作的所有参数都是可以被攻击者猜测到的;
如果我们在url中新增一个参数:token,这个token的值是随机的(必须是真随机!要足够安全),攻击者无法猜测出token的值,那么就可以有效防止CSRF攻击了
- token的使用原则
- token的生成一定要足够随机
- 为了使用方便,可以允许在一个用户的有效生命周期内,在token消耗掉前都使用同一个token