[TOC]
CSRF概述
Cross-site request forgery 简称为“CSRF”，中文名为跨站请求伪造。攻击者精心构造一个请求来诱导受害者点击，假如此时受害者刚好打开了相关网站，则有可能会导致执行了相关恶意操作。
攻击场景（某购物网站）
攻击者A尝试修改受害者B的账户邮箱地址，他发现该网站在修改邮箱时候发送的请求类似于http://xxx.com/edit.php?email=123@123.com&Change=Change，通过加以包装和诱导B进行点击，这便可能会使得B的邮箱被修改从而达到了A的目的。
CSRF攻击需要条件
目标网站没有防CSRF的处理，导致了请求容易被伪造
判断一个网站是否有CSRF漏洞，就要看他的增删改操作是否容易被伪造。
受害者再点击恶意链接时，必须是在同一台设备处于已登录的状态
CSRF与XSS的区别
XSS攻击中，攻击者确确实实拿到了被害者的身份验证信息，即直接盗取了用户的权限。而CSRF攻击过程中，攻击者实际上并未切实拿到被害者权限，而是而是被害者自己“主动”发送的，颇有一种借刀杀人的感觉。
CSRF攻击过程示例
这里以Pikachu靶场的三道题目进行演示：
CSRF(GET)
随便登陆一个用户账号，修改信息时抓包查看，
1 | GET /vul/csrf/csrfget/csrf_get_edit.php?sex=boy&phonenum=15988767673&add=hacker&email=kobe%40pikachu.com&submit=submit |
发现并没有token之类的认证手段。将这段URL适当修改，然后登录另一个账户，点击点击刚刚构造好的URL来模拟该用户被攻击，发现该用户的信息被成功修改成了我们想要的情况。
CSRF(POST)
发现修改信息被放在了POST请求体中，那么就无法像GET型一样直接构造恶意URL了。
但我们可以自己建一个网站，修改相关参数发送请求抓包后自己写一个html页面，诱导受害者进行点击等操作从而发送了恶意的POST请求修改了数据。
而BP中就有相关功能可以根据请求包直接生成可用的CSRF PoC:
生成之后点击测试一下：
点击提交按钮后发现信息被成功修改。
CSRF Token
抓包发现有token验证：
查看源码即可发现，token发现Tokenmeici发送请求后会被和Session中的Token值进行比较，相同才会修改成功
，并且在修改之后还会重新生成一个新的值放在html的隐藏标签中。
只要生成的Token足够随机，就会在一定程度上防止了CSRF攻击。
防御措施
每次设置随机Token
二次验证
例如：修改账号密码，需要判断旧密码。
Referer监测
检测跳转的站点是否符合规范。
这三种措施若同时使用基本可以杜绝CSRF攻击。
参考文章：