CSRF(跨站请求伪造)概述
Cross-site request forgery 简称为“CSRF”，在CSRF的攻击场景中攻击者会伪造一个请求（这个请求一般是一个链接），然后欺骗目标用户进行点击，用户一旦点击了这个请求，整个攻击就完成了。所以CSRF攻击也成为"one click"攻击。 很多人搞不清楚CSRF的概念，甚至有时候会将其和XSS混淆,更有甚者会将其和越权问题混为一谈,这都是对原理没搞清楚导致的。
CSRF与XSS的区别：CSRF是借用户的权限完成攻击，攻击者并没有拿到用户的权限，而XSS是直接盗取到了用户的权限，然后实施破坏。
如何确认一个web系统存在CSRF漏洞：
1.对目标网站增删改的地方进行标记,并观察其逻辑,判断请求是否可以被伪造
- ****比如修改管理员账号时，并不需要验证旧密码,导致请求容易被伪造;
- ****比如对于敏感信息的修改并没有使用安全的token验证,导致请求容易被伪造;
2.确认凭证的有效期(这个问题会提高CSRF被利用的概率)
- ****虽然退出或者关闭了 浏览器,但cookie仍然有效 ,或者session并没有及时过期 ,导致CSRF攻击变的简单;
CSRF（get）
打开pikachu的CSRF（get）页面，输入账号密码，修改个人信息，然后到burp中抓包查看
我们可以看到后台并没有一些防CSRF的措施，同时有时通过get请求来提交的
接来下我们只需要获取到网站修改个人信息的get请求链接，把信息修改成我们想要修改的信息，发送给用户就可以了，一旦用户点击攻击就完成了
http://127.0.0.1:88/pikachu/vul/csrf/csrfget/csrf_get_edit.php? sex=girl&phonenum=12345678922&add=wuhan&email=lucy%40pikachu.com&submit=submit
CSRF（post）
打开pikachu的CSRF（post）页面，登入账号密码，修改个人信息，然后打开burp抓包查看
可以看到请求是以post方式提交的，所有的参数都在请求体里传输的，无法利用url来伪造请求
这个是之前post型的xss方式是一样的，我们构造一个自己的站点，在这个站点上做一个表单，然后让用户去点我们恶意站点的表单url
利用这表单的url去向网站的后台提交请求
相应的恶意站点后台文件，把里面相应的信息修改成我们想要的，
将我们伪造表单的url /http://127.0.0.1:88/pikachu/vul/csrf/csrfpost/csrf_post.php 发给用户，诱使用户点击，一旦用户点击我们的攻击就完成了
CSRF（token）的防范措施
CSRF的主要问题是敏感操作容易被伪造，可以加通过加入Token让请求不容易被伪造
- 即每次都增加一个随机码（需要够随机，不容易被伪造），后台每次对这个随机码进行验证！
我们登入pikachu平台的CSRF（token）页面，修改个人信息，然后burp中抓包查看个人信息修改的get请求
可以看到和之前相比这里多一个token值，来防CSRF的
接下来我们看看前端如何拿到token，以及如何提交给后端验证的
每次用户后台都会生成一个token，用户做一些敏感操作后台都回去验证这个token，这样就有效的防范了CSRF攻击
CSRF的防范措施
增加Token验证(常用做法)：
- 对关键操作增加token参数，token值必须随机，每次都不一样;
关于安全的会话管理(避免会话被利用) :
- 不要在客户端端保存敏感信息(比如身份认证信息) ;
- 测试直接关闭，退出时,关闭浏览器的会话过期机制;
- 设置会话过期机制,比如15分钟内无操作，则自动登录超时;
访问控制安全管理:
- 敏感信息的修改时需要对身份进行二次认证，比如修改账号时，需要判断旧密码;
- 敏感信息的修改使用post，而不是get ;
- 通过http头部中的referer来限制原页面；
增加验证码:
一般用在登录(防暴力破解) , 也可以用在其他重要信息操作的表单中(需要考虑可用性)；