跨站请求伪造CSRF

原理解释

画个丑图来解释一波

1、 用户输入账号信息请求登录A网站。
2、 A网站验证用户信息，通过验证后返回给用户一个cookie
3、 在未退出网站A之前，在同一浏览器中请求了黑客构造的恶意网站B
4、 B网站收到用户请求后返回攻击性代码，构造访问A网站的语句
5、 浏览器收到攻击性代码后，在用户不知情的情况下携带cookie信息请求了A网站。此时A网站不知道这是由B发起的。那么这时黑客就可以进行一下骚操作了！

两个条件：a 用户访问站点A并产生了cookie
b 用户没有退出A同时访问了B

CSRF分类

GET型

如果一个网站某个地方的功能，比如用户修改邮箱是通过GET请求进行修改的。如：/user.php?id=1&email=123@163.com ，这个链接的意思是用户id=1将邮箱修改为123@163.com。 当我们把这个链接修改为 /user.php?id=1&email=abc@163.com ，然后通过各种手段发送给被攻击者，诱使被攻击者点击我们的链接，当用户刚好在访问这个网站，他同时又点击了这个链接，那么悲剧发生了。这个用户的邮箱被修改为 abc@163.com 了

POST型

在普通用户的眼中，点击网页->打开试看视频->购买视频是一个很正常的一个流程。可是在攻击者的眼中可以算正常，但又不正常的，当然不正常的情况下，是在开发者安全意识不足所造成的。攻击者在购买处抓到购买时候网站处理购买(扣除)用户余额的地址。比如：/coures/user/handler/25332/buy.php 。通过提交表单，buy.php处理购买的信息，这里的25532为视频ID。那么攻击者现在构造一个链接，链接中包含以下内容。

<form action=/coures/user/handler/25332/buy method=POST>
<input type="text" name="xx" value="xx" />
</form>
<script> document.forms[0].submit(); </script>

当用户访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作，自动购买了id为25332的视频，从而导致受害者余额扣除。

CSRF漏洞挖掘

1、 抓取一个正常请求的数据包，如果没有Referer字段和token，那么极有可能存在CSRF漏洞
2、 如果有Referer字段，但是去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。
3、 利用工具进行CSRF检测。如：CSRFTESTER，CSRF REQUEST BUILDER等

使用burpsuite快速生成CSRF poc

当我们发现一个页面存在CSRF漏洞后，可以通过burpsuite快速生成攻击代码

点击复制html ，然后保存在本地。

双击打开，当受害者点击就执行了我们的CSRF代码

防御手段

1、 验证http referer中记录的请求来源地址是否是合法用户地址（即最开始登录的来源地址）。但这只能进行简单的防御，因为这个地址可以人为的篡改。
2、 重要功能点使用动态验证码进行CSRF防护
3、 通过token方式进行CSRF防护，在服务器端对比POST提交参数的token与Session中绑定的token是否一致，以验证CSRF攻击
a：在Session中绑定token。如果不能保存到服务器端Session中，则可以替代为保存到Cookie里。
b：在form表单中自动填入token字段，比如 <input type=hidden name="anti_csrf_token" value="$token" />。
c: 在HTTP请求中自动添加token。

参考谢公子的博客