我正在开发一个JSON / REST Web API,我特别希望第三方网站能够通过AJAX调用我的服务。因此,我的服务是发送着名的CORS标题:
Access-Control-Allow-Origin: *
允许第三方网站通过AJAX调用我的服务。到目前为止一切都很好。
但是,我的web api的一个子部分是非公开的,需要身份验证(OAuth和access_token cookie非常标准)。在我的网站的这一部分启用CORS是否安全?
一方面,如果第三方网站的ajax客户端也可以与我的这部分服务进行交互,那将会很酷。但是,首先存在相同原产地政策的原因是这可能存在风险。您不希望之后访问的任何网站能够访问您的私人内容。
我担心的情况是用户登录我的网络API,无论是在网站上还是通过他信任的网站,他忘记退出。这会允许他之后访问的其他所有网站使用现有会话访问其私人内容吗?
所以我的问题:
答案 0 :(得分:40)
在回答第二个问题时(如果启用CORS的服务器通过cookie设置session_token ......?),cookie将保存在CORS服务器的域下。主网页的JS代码无法访问cookie,即使是通过document.cookie
。只有在设置.withCredentials
属性时才会将cookie发送到服务器,即使这样,只有在服务器设置Access-Control-Allow-Credentials
标头时才接受cookie。
你的第一个问题是更开放的问题。这是相当安全的,但有办法绕过事情。例如,攻击者可以使用DNS中毒技术导致预检请求到达实际服务器,但是将实际的CORS请求发送到流氓服务器。以下是有关CORS安全性的更多资源:
最后,您关心的是让任何网站访问您的CORS数据。为了防止这种情况,您不应使用Access-Control-Allow-Origin: *
标头。相反,您应该回显用户的Origin值。例如:
Access-Control-Allow-Origin: http://www.example.com
此标头仅允许http://www.example.com
访问响应数据。
答案 1 :(得分:19)
CORS的目的是允许对XHR请求的跨源请求,同时赋予服务器指定哪个源可以访问哪个资源的权限。特别是,CORS引入了 Origin 头字段,该字段允许服务器将常规和可能的XHR请求分开。用户不能设置或更改此标头字段,但是浏览器会为XHR请求设置此标头字段。
因此,如果您的API设计为仅供XHR使用,您可以(并且应该)要求请求符合CORS。特别是如果请求也可以修改服务器上的状态,否则您将容易受到CSRF的攻击。</ p>
请注意,无论CORS使用其他方法伪造GET和POST请求,都可以进行CSRF攻击。如果服务器允许,CORS仅允许使用JavaScript访问服务器对XHR请求的响应。