ajax 什么时候启用 CORS 是安全的？

When is it safe to enable CORS?

提问by Jeroen

I am developing a JSON/REST web API, for which I specifically want third party websites to be able to call my service through AJAX. Hence, my service is sending the famous CORS header:

我正在开发一个 JSON/REST web API，我特别希望第三方网站能够通过 AJAX 调用我的服务。因此，我的服务正在发送著名的 CORS 标头：

Access-Control-Allow-Origin: *

Which allows third party sites to call my service through AJAX. All fine so far.

这允许第三方站点通过 AJAX 调用我的服务。到目前为止一切都很好。

However, a subsection of my web api is non-public and requires authentication (pretty standard stuff with OAuth and an access_token cookie). Is it safe to enable CORS on this part of my site as well?

但是，我的 web api 的一部分是非公开的并且需要身份验证（带有 OAuth 和 access_token cookie 的非常标准的东西）。在我网站的这一部分启用 CORS 是否安全？

On the one hand, it would be cool if third party websites could have ajax clients that also interact with this part of my service. However, the reason that there is a same origin policy in the first place, is that this might be risky. You don't want any website that you visit afterwards to be able to access your private content.

一方面，如果第三方网站可以有 ajax 客户端也与我的这部分服务进行交互会很酷。然而，首先有同源策略的原因是这可能是有风险的。您不希望您之后访问的任何网站能够访问您的私人内容。

The scenario that I am afraid of is that a user logs in on my web api, either on the website or through a website that he trusts, and he forgets to logout. Will this allow every other website that he vists afterwards to access his private content using the existing session?

我害怕的场景是，用户登录我的 web api，无论是在网站上还是通过他信任的网站，他都忘记注销。这会允许他之后访问的所有其他网站使用现有会话访问他的私人内容吗？

So my questions:

所以我的问题：

• Is it ever safe to enable CORS on non-public content?
• If a CORS enabled server sets a session_token through a cookie, will this cookie be saved under the domain of the CORS server or main web-page server?

• 在非公开内容上启用 CORS 是否安全？
• 如果启用 CORS 的服务器通过 cookie 设置 session_token，该 cookie 会保存在 CORS 服务器或主网页服务器的域下吗？

采纳答案by monsur

In answer to your second question (If a CORS enabled server sets a session_token through a cookie...?), the cookie is saved under the domain of the CORS server. The main web page's JS code can't access the cookie, even via document.cookie. The cookie is only sent to the server when the .withCredentialsproperty is set, and even then, it is only accepted when the server sets the Access-Control-Allow-Credentialsheader.

回答您的第二个问题（如果启用 CORS 的服务器通过 cookie 设置 session_token ......？），cookie 保存在 CORS 服务器的域下。主网页的 JS 代码无法访问 cookie，即使通过document.cookie. cookie 仅在设置.withCredentials属性时发送到服务器，即使如此，也仅在服务器设置Access-Control-Allow-Credentials标头时才被接受。

Your first question is a little more open ended. It is fairly secure, but there are ways to circumvent things. For example, an attacker could use a DNS poisoning technique to cause a preflight request to hit the actual server, but send the actual CORS request to the rogue server. Here are some more resources on CORS security:

你的第一个问题更开放一些。这是相当安全的，但有一些方法可以规避事情。例如，攻击者可以使用 DNS 中毒技术使预检请求命中实际服务器，但将实际 CORS 请求发送到流氓服务器。以下是有关 CORS 安全性的更多资源：

• http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity
• owasp.org CORS CheatSheet

• http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity
• owasp.org CORS 备忘单

Lastly, your concern is around giving anywebsite access to your CORS data. In order to protect against this, you should not use the Access-Control-Allow-Origin: *header. Instead, you should echo back the user's Origin value. For example:

最后，您担心的是让任何网站访问您的 CORS 数据。为了防止这种情况，您不应该使用Access-Control-Allow-Origin: *标题。相反，您应该回显用户的 Origin 值。例如：

Access-Control-Allow-Origin: http://www.example.com

This header will allow only http://www.example.comto access the response data.

此标头将仅允许http://www.example.com访问响应数据。

回答by Gumbo

The intention of CORS is to allow cross-origin requests for XHR requests while giving the server the authority to specify what origin has access to which resource. In particular, CORS introduced the Originheader field that allows the server to tell regular and possible XHR requests apart. This header field cannot be set or changed by the user but is set by the browser for XHR requests.

CORS 的目的是允许 XHR 请求的跨域请求，同时赋予服务器指定哪个源可以访问哪个资源的权限。特别是，CORS 引入了Origin标头字段，允许服务器区分常规和可能的 XHR 请求。此头字段不能由用户设置或更改，而是由浏览器为 XHR 请求设置。

So if you have an API that is designed to be only used by XHR, you can (and should) require the request to conform with CORS. Especially if the requests can also modify state on your server as otherwise you would be vulnerable to CSRF.

因此，如果您的 API 设计为仅供 XHR 使用，您可以（并且应该）要求请求符合 CORS。特别是如果请求还可以修改您服务器上的状态，否则您将容易受到 CSRF 的攻击。

Note the CSRF attacks are possible regardless of CORS using other methods to forge GET and POST requests. CORS does only enable to access the server's response of XHR requests with JavaScript if the server allows it.

请注意，无论 CORS 是否使用其他方法来伪造 GET 和 POST 请求，CSRF 攻击都是可能的。如果服务器允许，CORS 仅允许使用 JavaScript 访问服务器对 XHR 请求的响应。