CSRF

• 是什么?

CSRF全称cross site request forgery,翻译过来就是跨站点请求伪造。意思就是在一个网站上通过伪造图片（get）或者表单（post）等去请求另一个网站，以达到操作用户账户的目的。

• 流程

流程

• 为什么CSRF能成功？

http协议
现在的互联网产品，大多都是基于http协议开发的。http协议，要求我们不管做什么操作，都必须发送一个http请求和携带必要的参数，比如删除博客，服务端的设计是要求我们发送http://blog.xxx.com/delete?acticleId=123。

为什么要验明身份
如果只是这样子，只要发送这个请求，那么阿猫阿狗都可以来删除你的博客。所以像删除修改这种敏感操作，一般要先验明身份。

验明身份之账号密码
不懂的人可能会问，不是只要登陆就可以了吗？但是http是无状态，也就是说你登陆以后，然后再发送过来的请求，服务器是无法区分是不是同一个人发过来的。你可能会又问，那么我们每次请求的时候把账号密码带上不就行了吗？有这种想法，只能说你实在too young，too native，因为每次请求都带账号密码，首先，客户端，即发送请求的人每次都要输入账号密码，这用户体验很差，就算我们把账号密码保存到本地，也有泄露账号密码的危险。最重要的是在服务端，每次请求都要验证用户名和密码，从数据库取数据这本来就很消费服务端的资源。

验明身份之令牌
看古装剧，某位官员有要事想要出城，一般会骑着马，掏出一块令牌，守城的将士验明了这块令牌的真假性，就可以放行了。那么这种方法是否可以用到实际中呢？账号在登陆的时候，我们给他颁布一块“令牌”，并且保存到一个地方，下次这个账号有什么请求，只要携带这块“令牌”，服务端根据某种规则检验这块令牌是否合法。是不是服务端颁发的，并且是不是颁发给这个用户的就可以了。这种思想应用到实际中，“令牌”就是token，保存令牌的地方就是cookie。

为什么csrf能够成功
浏览器在发送请求的时候，除了发送请求和参数，还会携带其他很多东西，组成一个http报文，发送过去。这个很多东西包括

报文

我们可以看到cookie也发送过去了，也就是说cookie里面存放的token也发送过去了。服务端验明token没问题，就会执行请求代表的操作，比如删除文章。在图1里面，用户访问了A网站后保存了A网站的token到cookie中，然后又打开了B网站，就会触发B网站里面删除A网站博客的恶意请求，并且会把cookie发送过去，A网站验明没问题了，就会执行接下来的操作，所以我们会看到我们的博客不见了。

意外
有些浏览器是禁止跨域访问发送cookie的，比如IE浏览器，所以对这种用户，使用CSRF是无效的。

• 简易操作

通过伪造图片构建CSRF请求

1. 伪造页的代码（http://localhost/test/photo.jsp）

        
CSRF通过伪造图片进行请求
        

          
        

2. 当我们访问 http://localhost/test/photo.jsp时，浏览器还会去访问 http://139.199.168.61?csrf=photo ，并且还会把cookie带过去

报文

3. 查看我们的服务器后台，会发现确实有这个请求

   日志

通过伪造表单构建CSRF请求

1. 伪造页代码

2. 服务端接收到的请求

image

---

• 防御

如何从零开始进行CSRF攻击？

明确你想做什么
假设你现在想对一个人进行CSRF攻击,首先我们要明确自己要做什么事,比如我现在想删除某位博主在CSDN的一篇博客,博客地址是
http://blog.csdn.net/qq271967835/article/details/59683674

了解CSRF请求的规则
我们知道自己是要删除某人的某篇博客以后,接下来我们要了解CSRF请求地址的规则，我们可以自己删一篇博客,看看请求地址的规则,比如
http://blog.csdn.net/qq271967835/article/delete?articleId=59675656
并且是get请求..从这个url，我们可以得出csdn删除文章的请求是这样子的
http://blog.csdn.net/用户名/article/delete?articleId=文章id
用户名和文章id,我们都不难从博主的博客中找到。

构造CSRF的攻击地址
整合后确定我们的请求地址是
http://blog.csdn.net/qq271967835/article/delete?articleId=59683674

伪造CSRF页面
因为删除的请求是get请求，所以我们这里可以伪造成图片，代码如下

CSRF通过伪造图片进行请求

 

我把它上传到我的服务器上，地址为http://139.199.168.61/csrf.html

把csrf页面丢给你要攻击的对象
如果用户打开了，即中招，但是在本例子中，访问后发现，抓包查看返回结果为

所以即说明删除失败，但是问题不大。
删除失败的原因有几种:

1. 你构造的csrf请求有问题
2. 被攻击的对象的浏览器不能正确发送cookie，有两种可能，一种是被攻击对象使用的是IE等跨跨站访问限制发送cookie的浏览器，二是被攻击的对象没有在该浏览器没有登陆过csdn或者保存的cookie已经过期。
3. csdn做了csrf防御，使你的攻击失效。在本例子，很明显就是CSDN做了检查referer的CSRF防御。

有哪些预防CSRF的手段

原理
黑客有且只有能控制只有攻击地址，像cookie，黑客是无法获知的，所以构建一个正确的攻击地址对黑客而言尤为重要。我们发现，上面的攻击地址，不管是url还是参数都很容易让黑客猜出来，那我们是不是可以构建一个复杂的攻击地址，让黑客猜不出来呢，答案是可以的。比如我们可以添加一个参数，参数的值是变化的，但是符合某种规律，这种规律只有网站设计者自己知道，只要服务端验明请求符合这种规律，就让他通过。

1. 验证码
   验证码的原理是用户访问网站后，服务端会把一串字符保存在该用户网对应的session中，并把字符串发给用户，用户填写完其他参数和验证码之后发来请求，服务端只要从请求中获取验证码，再与保存在session的进行对比即可。这种方法防御CSRF，就是添加一个随机的参数，这个参数的值，黑客是无法猜出来的。

2. signature
   这个方法中，客户端会把参数结合密钥进行加密，得到得到一个signature，并且把signature当成参数发给服务端，服务端收到请求后，会对除signature的参数，像在客户端那样与密钥结合进行加密，如果得出来的结果和signature一样，那么就说明是通过正常路径发过来的请求。当然，黑客也可以通过研究网站的JS，然后获取signature的密钥。所以我觉得这种方式不是很安全。

3. token
   服务端在第一次请求的时候把token发给用户，保存到cookie里面，用户之后每次请求，获取cookie里面的token作为参数发过来，只要服务端验证参数的token值和cookie里面的token值是一样的，就说明这是正常途径发过来的请求。由于同源策略的限制，黑客是无法从一个浏览器的一个网站，获取到另一个网站的cookie的，所以自然无法构造出有效的攻击url。

4. referer
   当我们从A网页点击某个链接到B网页后，那么A网页就是这次请求的referer，比如我现在从我的博客主页http://139.199.168.61 点击进入到某篇文章http://139.199.168.61/?p=60 ，那么http：//139.199.168.61就是这次请求的referer，我们可以抓包通过referer字段查看到

   image

   所以黑客的CSRF请求的referer自然是他的伪造网页，只要我们在服务端检查它的referer是否合法就可以了。一般特定的请求都有特定的referer的，比如删除博客的referer，理论上就是文章列表或者文章首页。