CSRF全家桶（含义，防御，攻击）
定义
cross-site request forery 跨站请求伪造，也被称为“One Click Attack”或者Session Riding
通过伪装成受信任的用户请求受信任的网站，利用网站对用户标识的信任，欺骗用户的浏览器发送HTTP请求给目标站点，另外可以通过IMG标签会触发一个GET请求，可以利用它来实现CSRF攻击。
受害者通过了验证可以访问网站A，攻击者构造含有访问网站A的url并进行非法有利的操作的网站B，同时诱导受害者访问网站B，同时触发了代码，使得受害者用自己的cookie通过验证访问网站A，并执行了网站B代码中的非法有利操作。
CSRF漏洞的实质：服务器无法判断当前请求是否是合法用户主观的操作。主观是指用户自己的操作而不是别人代理自己执行的操作。就像别人用自己的手机发送了短信，短信的发送方是我的手机号但是短信不是我发的。
CSRF漏洞检测：
检测CSRF漏洞是一项比较繁琐的工作，最简单的方法就是抓取一个正常请求的数据包，去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。
随着对CSRF漏洞研究的不断深入，不断涌现出一些专门针对CSRF漏洞进行检测的工具，如CSRFTester，CSRF Request Builder等。
以CSRFTester工具为例，CSRF漏洞检测工具的测试原理如下：使用CSRFTester进行测试时，首先需要抓取我们在浏览器中访问过的所有链接以及所有的表单等信息，然后通过在CSRFTester中修改相应的表单等信息，重新提交，这相当于一次伪造客户端请求。如果修改后的测试请求成功被网站服务器接受，则说明存在CSRF漏洞，当然此款工具也可以被用来进行CSRF攻击。
CSRFTester &burp
1）设置浏览器代理：127.0.0.1:8008
2）登陆web应用程序，填写表单，在tester右上角点击start recording，提交表单，在CSRFTester中找到对应的请求包，修改表单内容，
3）点击右下角的generate html 产生，产生POC代码，删掉文件中不用表单，点击保存的文件，用同一个浏览器打开保证cookie。
1）设置代理 抓包
2）右击Engagement tools-> Generate CSRF PoC
3）修改提交的参数—生成CSRF的HTML—在浏览器中测试
打钩后下次点击在浏览器中测试则默认复制CSRFHTML
4）点击copy后，直接在浏览器上的地址栏右键粘贴，回车 ，点击提交请求
信息被修改，或成功新增表单，则说明可以成功伪造请求进行操作，存在CSRF漏洞。
若无被修改/新增或在粘贴地址栏回车时页面出现错误，无法提交，则不存在CSRF漏洞
防御CSRF攻击：
目前防御 CSRF 攻击主要有三种策略：验证 HTTP Referer 字段；在请求地址中添加 token 并验证；在 HTTP 头中自定义属性并验证。
（1）验证 HTTP Referer 字段
Referer，它记录了该 HTTP 请求的来源地址。这种方法简单易行
但是Referer 的值是由浏览器提供的，虽然 HTTP 协议上有明确的要求，但是每个浏览器对于 Referer 的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不安全。事实上，对于某些浏览器，比如 IE6 或 FF2，目前已经有一些方法可以篡改 Referer 值。如果 bank.example 网站支持 IE6 浏览器，黑客完全可以把用户浏览器的 Referer 值设为以 bank.example 域名开头的地址，这样就可以通过验证，从而进行 CSRF 攻击。
即便是使用最新的浏览器，黑客无法篡改 Referer 值，这种方法仍然有问题。因为 Referer 值会记录下用户的访问来源，有些用户认为这样会侵犯到他们自己的隐私权，特别是有些组织担心 Referer 值会把组织内网中的某些信息泄露到外网中。因此，用户自己可以设置浏览器使其在发送请求时不再提供 Referer。当他们正常访问银行网站时，网站会因为请求没有 Referer 值而认为是 CSRF 攻击，拒绝合法用户的访问。
（2）在请求地址中添加 token 并验证
CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的 cookie 来通过安全验证。要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。
这种方法要比检查 Referer 要安全一些，token 可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对，但这种方法的难点在于如何把 token 以参数的形式加入请求。对于 GET 请求，token 将附在请求地址之后，这样 URL 就变成 http://url?csrftoken=tokenvalue。 而对于 POST 请求来说，要在 form 的最后加上 <input type="hidden" name="csrftoken" value="tokenvalue"/>，这样就把 token 以参数的形式加入请求了。但是，在一个网站中，可以接受请求的地方非常多，要对于每一个请求都加上 token 是很麻烦的，并且很容易漏掉，通常使用的方法就是在每次页面加载时，使用 javascript 遍历整个 dom 树，对于 dom 中所有的 a 和 form 标签后加入 token。这样可以解决大部分的请求，但是对于在页面加载之后动态生成的 html 代码，这种方法就没有作用，还需要程序员在编码时手动添加 token。
该方法还有一个缺点是难以保证 token 本身的安全。特别是在一些论坛之类支持用户自己发表内容的网站，黑客可以在上面发布自己个人网站的地址。由于系统也会在这个地址后面加上 token，黑客可以在自己的网站上得到这个 token，并马上就可以发动 CSRF 攻击。为了避免这一点，系统可以在添加 token 的时候增加一个判断，如果这个链接是链到自己本站的，就在后面添加 token，如果是通向外网则不加。不过，即使这个 csrftoken 不以参数的形式附加在请求之中，黑客的网站也同样可以通过 Referer 来得到这个 token 值以发动 CSRF 攻击。这也是一些用户喜欢手动关闭浏览器 Referer 功能的原因。
（3）在 HTTP 头中自定义属性并验证
此方法是将token放到http头自定义的属性中，通过xmlhttprequest将token放到http头的自定义属性中，但是xmlhttprequest是一般用于异步请求，且其请求的页面不会被浏览器记录下来，所以不能进行前进，后退，刷新，收藏等操作，使用体验差，且把所有请求都改为xmlhttprequest请求要重构整个网站代价太大。
444
在set-cookies的参数中添加SameSite字段，让cookies在跨站的情况下不被传送
GET型CSRF攻击
在url中添加参数，然后使用<img <a等标签的src隐藏url，可以自己构造网站让用户点击进入网页，使得包含此url操作的标签执行，或者让用户点击含有url的某些东西，来触发访问带有操作的url。
总之借人之手，绕过验证，行恶意之事。基本上需要构造一个有诱惑性的恶意的页面，让用户访问，点击网站上的某些东西。
POST型CSRF攻击
也就是在表单中添加hidden的<input标签，让用户在使用攻击者的网站的时候，同时提交了一些其他的东西，比如浏览器记录的别的网站的cookie，或者表面访问这个网站，实际上是访问别的网站 等等
总之借人之手，行恶意之事，基本上需要构造一个有诱惑性的恶意页面，让用户访问，点击网站上的某些东西。
GET型CSRF利用
利用a标签
利用iframe标签
利用img标签
利用CSS的background
backgroud属性实际上用的是background中的background-image
使用token进行CSRF防御
CSRF漏洞的实质：服务器无法判断当前请求是否是合法用户主观的操作。
token就是令牌，服务器要求每次操作时都要验证令牌是否正确，正确则执行，不正确则不执行。一般情况下，令牌会写在表单隐藏域的value值中或cookie中，随表单一起提交。
用户登陆成功后给与唯一令牌，维持会话，增删改查的部分需要一起提交token验证是用户主观操作。
下面是一个简单的例子
过程：登陆验证成功后，在会话的SESSION["user_token"]中保存token，在后台进行增删改表单中添加隐藏于hidden，设置value为token，提交表单后验证token是否一致。一致则执行操作，否则不执行。
攻击者获取到的Poc页面中的value=的token也是原来用户的token是一个定值，当用户的此token值失效时，攻击者让用户提交表单会验证失败，不执行操作，从而防止CSRF，即防止别人伪造合法用户进行操作。
默认情况下session 保存在Linux：/tmp 或 /var/lib/php/session Windows：C:\WINDOWS\Temp
Referer防御及CSRF绕过Referer
Referer，它记录了该 HTTP 请求的来源地址。使用referer验证域名值是否时自己的网站的，是就允许操作，不是就不允许。
但是Referer 的值是由浏览器提供的，虽然 HTTP 协议上有明确的要求，但是每个浏览器对于 Referer 的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不安全。
防御CSRF refer的使用方法
php中通过$SERVER["HTTP_REFERER"]获取页面提交的referer值
绕过referer的技巧
如果服务端只是判断当前的refer是否具有域名，那么攻击者在自己的网站中新建一个包含服务端域名的文件夹，并将恶意网页放到此文件下，那么refer的中就包含了服务端的域名。 refer验证路径绕过方法同理，将恶意网页放到和目标站点一样的层级目录下，保证url的路径相同。
即攻击者的网站下建一个refer要检测的目录，将恶意网页放到此文件夹下，使得refer中包含要检测的部分。
CSRF防御方法
验证码防御
当用户进行某些操作时，要求用户必须输入验证码，来防止CSRF，此方法简单有效。旨在一些重要的操作时才用验证码，要不然每一步操作都进行验证码操作太麻烦了，影响使用。
Referer Check防御
Referer Check主要用于图片盗链，即图片源所在网站会检测请求此图片的页面的referer是否在自己的域中，如果是域外网站的请求，则拒绝，不返回图片。同理也可以用来检测请求是否来自一个合法的源，比如用户修改自己的密码，一定是登陆网站进行的，referer一定是自己的，检测referer不是当前系统的域，那么就拒绝执行操作。
缺陷：服务器并不是任何时候都可以获得Referer，比如从https站点跳转到http站点
Token 防御
CSRF漏洞的实质：服务器无法判断当前请求是否是合法用户主观的操作。
token就是令牌，服务器要求每次操作时都要验证令牌是否正确，正确则执行，不正确则不执行。一般情况下，令牌会写在表单隐藏域的value值中或cookie中，随表单一起提交。
用户登陆成功后给与唯一令牌，维持会话，增删改查的部分需要一起提交token验证是用户主观操作。
