CSRF全称是Cross Site Request Forgery，也就是跨站点请求伪造，是一种很常见的Web攻击。

在很多网站的操作中，往往使用者只需要一个Cookie和参数就可以对其内容的增添或者删除的操作，比如搜狐的博客就有：

http://blog.sohu.com/manage/entry.do?m=delete&id=156713012

这样当用户登陆的时候，就能通过访问这个连接达到删除博客的目的。这样假设我们诱导用户访问上面的地址，用户就会神不知鬼不觉的删除自己的文章。 这个删除博客文章的请求，就是攻击者所伪造的，所以这种攻击就被成为跨站点请求伪造。

CSRF进阶

浏览器Cookie策略

上面的例子中，攻击者伪造的请求之所以可以被服务器验证通过，是因为用户的浏览器成功的发送了Cookie的缘故。

浏览器所持有的Cookie分为两种：一种是Session Cookie，也就是临时Cookie；另一种是Third-party Cookie，也就是本地Cookie。

两者的区别再与Third-Party Cookie在Set-Cookie时候就指定了Expire的时间，只有到了Expire时间后Cookie才会是小，所以这种Cookie会保存在本地；而Session Cookie则没有指定Expire的时间，所以当浏览器关闭的时候，Cookie也失效了。

也就是说，Session Cookie在全浏览器的生命周期，即使浏览器打开了一个新的Tab页，Session Cookie也都是有效的。Session Cookie保存在浏览器的内存空间中；而Third-Party Cookie则保存在本地。

如果浏览器从一个域的页面中，要加载另一个域的资源，由于安全原因，某些浏览器会阻止Third-party Cookie的发送。

需要说明的是IE出于安全的考虑，默认禁止了浏览器在<img>、<iframe>、<script>、<link>等标签中发送第三方Cookie。而Firefox默认的策略是允许发送第三方cookie的。

目前主流的浏览器之中，默认会拦截Third-party Cookie的有：IE、Safari；不会拦截的则有：Firefox、Opera、Chrome、Android等。但是CSRF攻击的目标如果不需要使用cookie，那么也不必考虑浏览器的Cookie策略了。

P3P头的副作用

尽管有些CSRF攻击的实施起来不需要认证，不需要发送Cookie，但是不可否认的是，大部分敏感的操作都是躲在认证之后的。因此浏览器拦截第三方Cookie的发送，在某种程度上来说降低了CSRF攻击的威力。

但是P3P的介入却使得情况变得复杂。P3P是W3C指定的一项关于隐私的标准，全称是The Platform for Privacy Preferences。

如果网站返回给浏览器的HTTP头包含了P3P头，则在某种程度上来说，会允许浏览器发送第三方Cookie，在IE下即使是<iframe>和<script>也不会在拦截第三方Cookie的发送。

在网站的业务中，P3P主要用于类似广告等需要跨域访问的页面。但是很遗憾的是，P3P头设置后，对于Cookie的影响将扩大到整个域中的所有页面，因为Cookie是以域和path为单位的，所以不满足最小权限的要求。

假设有www.a.com和www.b.com两个域，在www.b.com上有一个页面，其中包含一个指向www.a.com的iframe。

如果www.b.com/test.html的内容为:

<iframe width=300 height=300 src="http://www.a.com/test.php"></iframe>

如果这http://www.a.com/test.php对a.com设置了Cookie的页面，其内容为：

123

header("Set-Cookie:test=axis;domian=.a.com;path=/")?>

如果请求www.b.com/test.html的时候，他的iframe会告诉浏览器去跨域请求www.a.com/test.php。test.php会尝试请求Set-Cookie，所以浏览器会收到一个Cookie。

如果设置Cookie成功之后，会再次请求该界面，浏览器会发送刚刚收到的Cookie，可是由于跨域限制，在a.com上Set-Cookie是不会成功的，所以无法发送刚才收到的Cookie，无论是临时还是本地的Cookie。

可是当加入P3P之后，其允许跨域访问数据，从而跨域Set-Cookie成功。

P3P头的介入会改变域名的隐私策略，从而使得<iframe>、<script>等标签在IE中不再拦截第三方Cookie的发送。P3P头只需要由网站设置一次即可，之后的每次请求都会遵循此策略，而不需要再重复设置。

P3P策略可以查询W3C标准。也可以直接引用一个XML策略文件。www.w3.org/TR/P3P

GET或者POST

不仅仅GET能够发起CSRF攻击，POST请求也能够发起CSRF攻击，所以不能仅凭请求方式来获取变量执行操作。

比如，在一个页面中构造好一个<form>，然后使用Javascript自动提交这个表单，比如，攻击者在www.b.com/test.html中写入下面的代码。

1234567891011

<form action="http://www.a.com/register" id="register" method="post">	<input type="text" name="username" value="" />	<input type="text" 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>

攻击者甚至可以将这个页面隐藏于一个不可见的iframe的窗口中，这整个自动提交表单的过程来说，对于用户来说也是不可见的。

Flash CSRF

Flash也有许多的方式能够发起网络请求，包括POST。但是自IE 8起，Flash发送的网络请求已经不再发送本地Cookie了。

CSRF Worm

实现的原理可以举个例子：

假设现在有一个SMS服务，可以向指定的用户发送短消息：

http://msg.xx.com/?ct=22&cm=MailSender&tn=bmSubmit&sn=账号&co=消息内容

只需要修改参数sn，即可以对指定的用户发送短消息，而这里另一个接口则可以查询出某个用户的所有好友：

http://frd.xx.com/?ct=28&cm=FriList&tn=bmABCFriList&un=账号&callback=gotfriends

将两者结合起来，可以组成一个CSRF Worm，让一个用户查看恶意截面后，将给他的好友发送一条短消息，这个短消息又包含一张图片，其地址再次指向CSRF页面，使得这些好友再次将信息发给他的好友，这个worm因此得以传播。

首先：模拟服务器取得request的参数。

12345

var lsURL = window.location.href;loU = lsURL.split("?");if(loU.length>1){	var loallPm=loU[1].split("&");// get param from ?XXXX大专栏

标签：发送,www,浏览器,请求,伪造,站点,Cookie,P3P,com
来源： https://www.cnblogs.com/liuzhongrong/p/12371305.html