如果在服务器上正确设置CORS以仅允许某些来源访问服务器,这是否足以阻止XSRF攻击?
答案 0 :(得分:30)
更具体地说,如果evil.com因CORS无法向good.com提出请求,则很容易犯错误,因此CSRF被阻止了。然而,有两个问题被忽视了:
CORS仅受浏览器尊重。这意味着谷歌Chrome将遵守CORS,而不是让evil.com向good.com提出请求。但是,假设某人构建了一个本机应用程序或任何具有向您的站点发布POST的表单的内容。 XSRF令牌是防止这种情况发生的唯一方法。
容易忽略CORS仅用于JS请求的事实。尽管有CORS,但发送回good.com的evil.com上的常规表单仍然有效。
由于这些原因,CORS不是XSRF令牌的良好替代品。最好同时使用两者。
答案 1 :(得分:14)
没有!
CORS支持在两个域之间共享,其中XSRF攻击方法无论如何都不依赖于CORS。
我不明白你的意思是“CORS正确设置”但是当用XSRF攻击时,浏览器不要求服务器上的CORS头。
CORS不安全:)
答案 2 :(得分:10)
没有
同源策略(CORS允许您打击选择性漏洞)可防止第三方网站伪装成用户,以便从其他网站读取(私人)数据。
跨站点请求伪造攻击是指第三方站点伪装成用户提交数据到另一个站点(作为该用户)。它不需要阅读回复。
答案 3 :(得分:3)
男人这是一个艰难的人,而且比其他人提供的要复杂得多。所以"也许"
首先,CORS旨在“放松”#34; same-origin-policy是一个默认值,可以阻止特定类型的CSRF攻击。但是,同源不适用于所有类型的请求。
因此,会话需要超时的时间越长,用户在不受信任的网站上浏览的次数就越多,因此对其进行CSRF攻击的风险就越高。任何触发外部资源请求的标记都可用于执行隐藏的CSRF攻击 - 包括图像,链接标记,某些元标记,嵌入和对象标记等。同样适用于属性加载背景图像或类似。如果您将应用程序标记的标题中的DTD文件替换为服务器上的资源(甚至是CSRF),您甚至可以检查您的站点是否已经过某人验证。 source
举个例子,检查一下..
<img src=victim.bank/check.png?account=...>
;从易受攻击的银行网站获取支票照片,而不生成原始标题或预先发出的请求。 [...]将显示照片,攻击者可以使用Javascript获取照片数据并将其发回。 source
但是,至少有一个消息来源表示,未来的Web服务器可能会在图像上返回带有Access-Control-Allow-Origin
(CORS)标题的图像,这会阻止浏览器呈现图像。这将阻止此类CSRF-GET攻击..
如果浏览器检查响应中的Access-Control-Allow-Origin标头并拒绝显示它,则它将是一种有效的防御措施。 source
答案 4 :(得分:-4)
实际上CORS确实有助于提高安全性。 CORS对不同主机之间的XSS和CSRF攻击有很大帮助。如果某个网站存在XSS漏洞并且攻击者想要通过xmlhttprequest
将其用于向其他网页发送恶意请求,那么感谢CORS他无法做到。