跨站请求伪造
关于CSRF可以参考spring/security/跨站请求伪造篇。 Cookie在设计的时候允许第三方发起，网站a.com本身向自己发起请求，会携带本网站a.com的cookie，这种称为第一方cookie，另一个网站b.com也可以请求 网站a.com，这时会自动携带a.com的cookie请求a.com网站，但是是由b.com网站发起的，所以称为第三方cookie。正是由于这种特性，第三方网站可以发起 请求伪造攻击。
CSRF剖析
攻击者通常通过实现get请求改变服务器状态，来利用网站。他们会伪造一个get请求，诱导受害者点击，点击之后让网站执行不可预期的操作。
get请求是唯一一个在URL中包含所有请求内容的HTTP请求。所以也是CSRF唯一可以利用的攻击手段。
在早期的Twitter中，可以使用GET方法创建一篇文章，聪明的黑客创建了一个恶意的连接，当被点击时，将会发布一条淫秽信息和恶意连接的微博。后面越来越多
的人点击并发布了同样的信息。最终Twitter紧急处理，并在事情失控前关闭了漏洞。
解决方案1：遵从REST规则
遵从REST规则，GET不能改变服务器的状态。
解决方法2：实现反CSRFCookies
GET请求对修改关闭，解决了大部分的攻击，但是其他的方法还是存在攻击的可能性，例如，攻击者可以引诱用户点击一个POST请求，通过让受害者提交一个被攻击者
控制的第三方脚本或者表单，也可以达到攻击的目的。此时，你需要使用anti-CSRF cookies来确保这些请求都是由自己网站的表单或者脚本发起的。
一个anti-CSRF Cookies是一个服务器输出到cookie中的随机数，如Set-Cookie: _xsrf=5978e29d4ef434a1。网站使用anti-CSRF Cookies验证
POST 请求发起的页面是处于同一个域名下的。HTML 页面添加相同的token，在每个表单中添加标签<input type="hidden" name="_xsrf" value=
"5978e29d4ef434a1">。当用户请求到服务器时，_xsrf值和cookie中的_xsrf值不一致，服务器拒绝该请求。
最后一步，确保攻击者不能窃取你的anti-CSRF令牌，并将它嵌入到恶意代码中。
解决方案3：使用SameSite Cookie属性
指定SameSite 属性，从根源上禁止第三方网站发起Cookie。
Set-Cookie: _xsrf=5978e29d4ef434a1; SameSite=Strict;
额外的解决方案：对敏感动作设置重新身份认证
如，在转账时，输入密码；github删除项目时，输入登录密码等。