与前端/后端位于两个不同域上的CORS控制相比,CSRF保护如何为我提供更高的安全性? [英] How does CSRF protection give me greater security than CORS control with front-end/back-end being on two different domains?

查看:66
本文介绍了与前端/后端位于两个不同域上的CORS控制相比,CSRF保护如何为我提供更高的安全性?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

如果我有

  • 一个域上的Web前端.
  • 另一个域上的REST API.
  • 通过将标头 Access-Control-Allow-Origin 设置为Web前端域,REST API服务器配置为仅允许来自Web前端域的跨源请求.
  • A web front-end on one domain.
  • A REST API on another domain.
  • The REST API server configured to only allow cross origin requests from the web front-end domain by setting header Access-Control-Allow-Origin to the web front-end domain.

除了需要克服的障碍之外,CSRF还提供哪些额外的安全性?攻击者无法 POST 到我的后端,而不先将其代码注入Web前端,对吧?

Aside from more hoops to jump through, what additional security does CSRF provide? Attackers can't POST to my backend without first injecting their code into the web front-end, right?

关于这个问题"[...]所以,是的,我认为通常所有API视图都应免除CSRF.[...]" .这个概念有效吗?它包括我的拓扑吗?

On this question, Chris Pratt said, "[...]So, yes, I think as a rule any API view should be CSRF exempt.[...]". Is that concept valid and does it include my topology?

在我的配置中,正确配置了CORS,我是否需要装饰 GET POST PUT DELETE 和数据元素CSRF令牌的code>请求?

In my configuration, with CORS properly configured, do I need to decorate GET, POST, PUT, DELETE requests coming from the web front-end with the Cookie and the data element CSRF token?

:
开明的人可能会将此问题视为重复的问题,但我已阅读,和,而且我仍然需要一些帮助.请帮助我进一步充实这个想法.

Meta:
Enlightened individuals may see this question as a duplicate, but I have read this, this, this, this, this, this, and this, and I still need some help. Please help me flesh this idea out more.

推荐答案

在从域加载的页面的上下文中,CORS仅控制浏览器是否可以读取来自另一个域的XHR响应.它不控制浏览器可以向 发出请求的域.也就是说,CORS将针对标头设置的任何来源放宽相同来源政策-但是关于同源起源策略"的任何内容都没有说不能首先提出请求.

In the context of a page loaded from a domain, CORS only controls whether a browser can read XHR responses from another domain. It does not control which domains a browser can make requests to. That is, CORS will relax the Same Origin Policy for any Origins set by your header - but nothing about the Same Origin Policy says that requests cannot be made in the first place.

其他域仍然可以GET和POST到您的域,这仅仅是因为除非CORS允许,否则无法在客户端脚本中读取您站点生成的任何响应.您的服务器仍会接收并处理实际的GET和POST .

Other domains can still GET and POST to your domain, it would just be that any responses generated by your site could not be read in client-side script unless allowed by CORS. The actual GET and POST is still received by your server and processed.

因此,即使对于具有符合CORS要求的浏览器的用户,您仍然需要CSRF防护.

Therefore, you still need CSRF prevention - even for users with a CORS compliant browser.

这篇关于与前端/后端位于两个不同域上的CORS控制相比,CSRF保护如何为我提供更高的安全性?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆