51

如果 CORS 在服务器上正确设置为仅允许特定来源访问服务器，

这足以防止 CSRF 攻击吗？

4

6 回答 6

48

更具体地说，很容易错误地认为如果 evil.com 由于 CORS 无法向 good.com 发出请求，那么 CSRF 就会被阻止。然而，有两个问题被忽视：

  1. CORS 仅受到浏览器的尊重。这意味着谷歌浏览器将遵守 CORS，并且不会让 evil.com 向 good.com 提出请求。但是，想象一下有人构建了一个原生应用程序或任何具有将内容发布到您的站点的表单。XSRF 令牌是防止这种情况的唯一方法。

  2. 是否容易忽略 CORS 仅适用于 JS 请求的事实。evil.com 上的常规表单回传到 good.com 仍然可以使用 CORS。

由于这些原因，CORS 不是 XSRF 令牌的良好替代品。最好同时使用两者。

于 2016-05-05T08:11:57.700 回答
13

不！

CORS 支持在两个域之间共享，其中 XSRF 是一种无论如何都不依赖于 CORS 的攻击方法。

我不明白您所说的“CORS 已正确设置”是什么意思，但是当使用 XSRF 进行攻击时，浏览器不会在服务器上询问 CORS 标头。

CORS 不是安全性:)

于 2013-11-05T16:25:27.703 回答
10

不。

同源策略（CORS 允许您选择性地打洞）可防止第三方站点伪装成用户以从另一个站点读取（私有）数据。

跨站点请求伪造攻击是指第三方站点伪装成用户向另一个站点（作为该用户）提交数据。它不需要读回响应。

于 2013-11-05T16:29:46.063 回答
6

也许

伙计，这是一项艰巨的任务，而且比其他人提供的要复杂得多。所以“也许”

首先，CORS 旨在“放松”同源策略，这是防止特定类型 CSRF 攻击的默认设置。但是，同源并不适用于所有类型的请求。

因此，会话需要超时的时间越长，用户在不受信任的站点上浏览的次数越多，出现 CSRF 攻击的风险就越高。任何向外部资源发出请求的标签都可用于执行隐藏的 CSRF 攻击——包括图像、链接标签、一些元标签、嵌入和对象标签等。加载背景图像或类似的属性也是如此。如果您将应用程序标记的标题中的 DTD 文件替换为服务器上的资源，您甚至可以检查您的站点是否已被某人验证——这也是 CSRF。资源

对于一个例子，检查这个..

<img src=victim.bank/check.png?account=...>; 从易受攻击的银行站点获取支票照片，而不生成原始标头或预检请求。[...] 将显示照片，攻击者可以使用 Javascript 获取照片数据并将其发回。资源

然而，至少有一个消息来源表明，未来 Web 服务器可能会在图像上返回带有Access-Control-Allow-Origin(CORS) 标头的图像，这将阻止浏览器呈现图像。这将防止此类 CSRF-GET 攻击。

如果浏览器检查响应中的 Access-Control-Allow-Origin 标头并拒绝显示，这将是一种有效的防御。资源

于 2015-04-14T19:18:15.750 回答
1

正确的 CORS 设置

现代浏览器试图通过一种安全机制又名SOP（同源策略）来防止跨域请求伪造攻击。

CORS设置将打开 SOP 的一些限制并放宽它。

我会将正确的 CORS 设置解释为：

  • 具有 SOP 功能的浏览器
  • 允许 cors 标头不是*或<request-origin-host>（只是作为受信任的主机）

标准作业程序限制

如果任何页面请求跨域，则有3个策略：

  1. 写请求，例如：链接、重定向、xhr、表单提交（允许）（规则 1）
  2. 嵌入请求，例如：（<script>, <link>, <img>, <video>, <audio>, <object>, <embed>, @font-face, <iframe>允许）（规则 2）
  3. 读取请求（禁止）（规则 3）

其中第一个选项（写请求）容易被滥用跨站点请求伪造。

SOP 机制只允许这些写请求

为什么？

  • 向后兼容现有网站
  • 方便的开发和使用（想想如果存在复杂的重定向解决方案会发生什么！！！）

浏览器 SOP 对此步骤所做的唯一帮助是为资源更改（POST/PUT/...）XHR 请求发送飞行前请求

注意：在以后的步骤中，它的帮助远不止这些

在 pre-flight 请求中，服务器发送CORS Allow Header，浏览器判断是否允许更改资源请求。

例如：如果有一个带有 post 方法的表单更改服务器上的资源，CORS Allowance Header将从服务器接收，但服务器上的资源已经更改。（索拉博死后的解药）

SOP 将防止 CSRF 攻击 xhr 请求而不是 application/x-www-form-urlencoded 请求

  • evil.com 上可以有一个表单，或者脚本可以在 DOM 中附加一个表单并自动发送它。

或者它自己的 xhr 预检可能不会像我们预期的那样阻止，因为：

  • 在某些浏览器中，它可以因为性能而被禁用（没有 2 个请求）
  • 如果未设置 Origin 标头
  • 服务器可能允许*
  • 预检请求上的一些错误暴露了功能......

CSRF-令牌机制

CSRF 令牌可用于表单和 xhr 请求。

CSRF-token 机制只有在CSRF Token 不暴露于跨域恶意脚本的情况下才能防止 CSRF 攻击

但这种情况可以想象：恶意网站上的脚本：

  • 第一次请求表单（又名编辑表单或删除表单）并获取令牌
  • 然后使用 application/x-www-form-urlencoded 或 xhr 发送令牌

SOP 支持 CSRF-token

我已经提到过 SOP 限制了读取请求。并且只允许嵌入的读取请求。

因此 SOP 将防止 CSRF 令牌被恶意脚本暴露（获取表单并使用令牌创建虚假表单），如果：

  • 正确的 CORS 设置
  • 表单无法嵌入

TL;博士

SOP 机制（使用规则#1）（正确的 CORS 设置）只能防止 CSRF xhr（在实现中可能存在一些缺陷）（不能保护所有场景）

如果令牌没有被泄露，CSRF-Token 可以保护 CSRF 攻击

SOP 机制（规则#3）可以保护 CSRF-token & CSRF-token 保护用户免受 CSRF-attack

我们应该注意不要使用嵌入式资源规则（规则＃2）破坏 CSRF 令牌。（主要是 iframe 滥用）

MDN 如何阻止跨域访问

  • 为防止跨域写入，请检查请求中不可猜测的令牌 - 称为跨站点请求伪造 (CSRF) 令牌。您必须防止跨域读取需要此令牌的页面。
  • 为防止资源的跨域读取，请确保它不可嵌入。通常有必要防止嵌入，因为嵌入资源总是会泄露一些关于它的信息。
  • 为防止跨域嵌入，请确保您的资源不能被解释为上面列出的可嵌入格式之一。浏览器可能不尊重 Content-Type 标头。例如，如果您指向一个
标记 HTML 文档时，浏览器会尝试将 HTML 解析为 JavaScript。当您的资源不是站点的入口点时，您还可以使用 CSRF 令牌来防止嵌入。

进一步阅读

同源政策

CSRF Token 机制（在 Laravel 中实现）

于 2021-10-16T17:20:51.880 回答
-4

实际上，CORS 确实有助于安全性。CORS 对不同主机之间的 XSS 和 CSRF 攻击有很大帮助。如果一个网站存在 XSS 漏洞，并且攻击者想使用它通过 向另一个网页发送恶意请求xmlhttprequest，多亏了 CORS，他将无法做到。

于 2014-05-19T18:53:43.400 回答