CSRF攻击
CSRF叫做跨站请求伪造攻击，也有叫XSRF的，其实都差不多，你也可以认为是XSS和CSRF的结合。对于这个攻击原本我是不怎么理解的，写了个接口，然后试了一下，直接就发起了请求。
先看接口：
const http=require('http');
http.createServer(function(requset,response){
response.setHeader('Access-Control-Allow-Credentials', 'true');
response.end('123');
}).listen(3000);
当我用图片地址访问的时候，出现：
A cookie associated with a cross-site resource at was set without the SameSite attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with SameSite=None
大概意思就是不允许携带cookie，如果我设置了：
response.setHeader('Set-Cookie', 'a=888;Path=/;SameSite=Lax');
然后用img标签请求成功了：
虽然cookie没有携带，不知道是不是这个原因：
Chrome 计划将Lax变为默认设置。这时，网站可以选择显式关闭SameSite属性，将其设为None。不过，前提是必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送），否则无效。
写不出好的接口去验证，于是只好不求甚解的简单理解一下，就是用户通过访问安全网站，进行登录，登录成功后，用户验证登录的信息记录在了浏览器，这时候用户在安全网站可以正常操作，之后要是用户在同一个浏览器访问不安全网站，不安全网站通过各种方法通过安全网站的用户登录信息进行攻击，比如：
1、当安全网站A登录之后，不安全网站B通过img、script等不会跨域的元素调用get请求的接口，如果是通过请求携带cookie判断的话，直接就可以请求成功。
2、如果后台是POST接口，校验数据用的也是post才能获取参数，不安全网站B可以通过ifram嵌入安全网站A，然后通过form表单提交请求。
这是一般我们认知的简单CSRF，有资料说，可以触发请求的方法达到了几百种，单单HTML就有196种。还有什么PDF JavaScript、ServiceWorkers等奇奇怪怪的方法去进行XSRF攻击。
有攻击就有防御方法，检查Referer、添加校验token、不保存cookie、不使用全局cookie、自定义header属性并校验等等。
虽然不知道CSRF攻击是不是真的那么简单，突然发现自己做过的项目好像并没有想象中的那么安全，感觉随便都能被攻击了。
像阿里这种几乎是所有黑客攻击的第一目标，他们要遭遇的可不仅仅是CSRF这种小儿科玩意儿，很难想象他们的安全团队是多么的牛逼。
image
发表评论 (审核通过后显示评论)：