之前一直以为设置了 CORS ,那么 Allowed Origin 之外的其他域名下的代码发送的请求就不会到达服务端。
今天凑巧研究了一下 CSRF 的攻击过程,原来设置了 CORS 只会阻止前端代码读取 Response 的内容,但这个请求本身还是会被发送到服务端,并被处理。
1
Meiyun 2023-11-08 18:14:04 +08:00
不发送到服务端前端怎么知道有没有被允许?
|
2
proxytoworld 2023-11-08 18:18:39 +08:00
你是不是搞错了 cors 防 xss 的,csrf 防护对应的是 csrf token
|
3
jiangzm 2023-11-08 18:19:41 +08:00
无知了哈,
OPTIONS 请求不会阻止 GET/POST 请求会阻止 |
4
yumusb 2023-11-08 18:19:44 +08:00
option 预检请求会被发送。
|
5
jiangzm 2023-11-08 18:21:16 +08:00 1
即使 OPTIONS 返回了内容也会忽略。
大概率你的服务端没有按标准 CORS 输出内容 |
6
retanoj 2023-11-08 18:32:17 +08:00
所以你知道了 Access-Control-Allow-Origin 这个 header 头是服务端设置并返回的对吧。
事实上,为了解决 XS-*类的问题,还有其他很多机制是浏览器配合服务端一起实现的。 比如 Fetch Metadata/ COOP / CORP |
7
limaofeng 2023-11-08 18:38:54 +08:00 via iPhone
一般情况下,httpserver 都不会拒绝客户端发送的请求。 那是防火墙的工作
|
8
DOLLOR 2023-11-08 18:57:18 +08:00 via Android
HTTP 报头的 referer 和 origin ,就是用来给服务端检查请求来源的。但估计大部分服务端开发都没这个意识,都是全盘放行。
|
9
ETiV 2023-11-08 19:02:59 +08:00 via iPhone
恭喜你学到了新知识 🎉
|
10
we21x 2023-11-08 19:08:28 +08:00
这个我记得是分 简单请求 和 非简单请求,简单请求的响应跨域了话会被拦截,非简单请求预检过不了所以不会发送实际的请求。
*区分简单请求和非简单请求:请求方法 和 content-type |