CSRF(跨站请求伪造)概述
Cross-site request forgery 简称为“CSRF”，在CSRF的攻击场景中攻击者会伪造一个请求（这个请求一般是一个链接），然后欺骗目标用户进行点击，用户一旦点击了这个请求，整个攻击就完成了。
小黑想要修改大白在购物网站tianxiewww.xx.com上填写的会员地址。
先看下大白是如何修改自己的密码的：
登录---修改会员信息，提交请求---修改成功。 所以小黑想要修改大白的信息，他需要拥有：1，登录权限 2，修改个人信息的请求。但是大白又不会把自己xxx网站的账号密码告诉小黑，那小黑怎么办？ 于是他自己跑到www.xx.com上注册了一个自己的账号，然后修改了一下自己的个人信息（比如：E-mail地址），他发现修改的请求是【http://www.xxx.com/edit.php?email=xiaohei@88.com&Change=Change】 于是，他实施了这样一个操作：把这个链接伪装一下，在小白登录xxx网站后，欺骗他进行点击，小白点击这个链接后，个人信息就被修改了,小黑就完成了攻击目的。
为啥小黑的操作能够实现呢。有如下几个关键点：
1.www.xxx.com这个网站在用户修改个人的信息时没有过多的校验，导致这个请求容易被伪造; ---因此，我们判断一个网站是否存在CSRF漏洞，其实就是判断其对关键信息（比如密码等敏感信息）的操作(增删改)是否容易被伪造。 2.小白点击了小黑发给的链接，并且这个时候小白刚好登录在购物网上; ---如果小白安全意识高，不点击不明链接，则攻击不会成功，又或者即使小白点击了链接，但小白此时并没有登录购物网站，也不会成功。 --因此，要成功实施一次CSRF攻击，需要“天时，地利，人和”的条件。 当然，如果小黑事先在xxx网的首页如果发现了一个XSS漏洞，则小黑可能会这样做：欺骗小白访问埋伏了XSS脚本（盗取cookie的脚本）的页面，小白中招，小黑拿到小白的cookie，然后小黑顺利登录到小白的后台，小黑自己修改小白的相关信息。
---所以跟上面比一下，就可以看出CSRF与XSS的区别：CSRF是借用户的权限完成攻击，攻击者并没有拿到用户的权限，而XSS是直接盗取到了用户的权限，然后实施破坏。
因此，网站如果要防止CSRF攻击，则需要对敏感信息的操作实施对应的安全措施，防止这些操作出现被伪造的情况，从而导致CSRF。比如： --对敏感信息的操作增加安全的token； --对敏感信息的操作增加安全的验证码； --对敏感信息的操作实施安全的逻辑流程，比如修改密码时，需要先校验旧密码等。
CSRF（get)
CSRF漏洞，黑客构造一个请求诱导用户去点击，用户点击了攻击就成立了。
对于get型的首先想到的是先进行一个抓包，查看它的http请求头信息。
可以看到，在GET后面直接提交的用户名密码(使用的用户名和密码是根据提示得来的)。
此时我们将这个包发送到repeater模块，send查看一下，发现这个包是登录的，并不是返回包，回到拦截模块，forward放行这个包，会抓到一个登录信息返回包，同样发送到repeater模块，结果呢发现这个是登录进去的包，而并不能去修改它的一些信息。
此时拦截到这两个包都没有用，剩下一个修改用户信息的包，再去修改信息拦截一下。
发现修改的地方出来了，也提交了所有的参数信息。
接下来就直接在burpsuite中修改它给出的所有能修改的信息，放行后退出登录，重新登录查看。
CSRF （post）
同样的，还是抓修改个人信息的包
这次它的个人信息的参数只是不在POST处了
还是修改它所有的参数，放行后退出登录，重新登录查看
CSRF Token
同样的，使用Kobe用户登录一下去看看
既然是这样，那依旧抓包个人修改页
还是get请求，不过添加了token验证，抓到的包发送到repeater模块，执行两次，token值发生改变。
此时使用CSRF Token Tracker插件
添加一个host和name
将抓到的包发送到repeater模块，修改信息，send执行
此时回到proxy拦截模块，修改信息后，forward发包并退出拦截，回到pikachu退出登录后重新登进去。
