公共存储桶的 S3 CORS 策略答案

【问题标题】：S3 CORS policy for public bucket公共存储桶的 S3 CORS 策略
【发布时间】：2019-04-14 16:40:34
【问题描述】：

这似乎很容易，但我不知道我错过了什么。我有一个从我的网站获取的带有 js 脚本的公共存储桶。我注意到我没有将 Origin 标头发送到 S3，这不是必需的，并且在没有任何 CORS 配置的情况下一切正常。

更重要的是，即使我手动将 Origin 标头添加到该 GET 调用并通过以下方式明确禁止 GET 和我的域：

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>http://www.nonexistingdomain.com</AllowedOrigin>
    <AllowedMethod>POST</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

我仍然可以获取内容。这是怎么回事？

【问题讨论】：

标签： amazon-s3

【解决方案1】：

好的，在与 Quentin 交谈之后，我想我明白我在哪里误解了 CORS 的工作原理。在 Java 世界中，当 Origin 不匹配时实际拒绝请求是一种非常常见的做法。这是另一个线程，它是mentioned。如果我们以 Spring 为例（这是 Java 世界中的事实标准），添加 CORS 过滤器时会发生以下情况：

    String allowOrigin = checkOrigin(config, requestOrigin);
    ...

    if (allowOrigin == null) {
        logger.debug("Reject: '" + requestOrigin + "' origin is not allowed");
        rejectRequest(response);
        return false;
    }

地点：

/**
 * Invoked when one of the CORS checks failed.
 */
protected void rejectRequest(ServerHttpResponse response) {
    response.setStatusCode(HttpStatus.FORBIDDEN);
}

您可以找到代码here。

但令我惊讶的是，这在其他堆栈和服务器端技术中并不常见。另一种常见的方法是将他们拥有的任何 CORS 配置发送到浏览器，然后由浏览器决定。

S3 更加棘手：它仅在桶 CORS 规则匹配启用 CORS 的请求（请求 qith Origin 标头）时发送 CORS 响应标头。否则，将没有 CORS 响应标头。

【讨论】：

【解决方案2】：

同源策略是浏览器强制执行的一项功能，可防止在一个网站上运行的 JavaScript 读取来自不同网站的数据。（这会阻止使用 JavaScript 的随机网站使用您的浏览器跳过您的公司防火墙并访问您的 Intranet 或使用您的 cookie 读取您的 GMail）。

CORS 让网站放松同源策略，以允许其他网站以这种方式从中读取数据。

CORS 不是身份验证/授权。您的公共存储桶是public。

您没有使用 JavaScript 从存储桶中读取数据，而是直接从存储桶加载 JS。

【讨论】：

我确实使用js来加载其他js。这是一种确保我的跟踪代码只加载一次的方法。
我没有说 CORS 与 auth 有任何关系。
虽然 CORS 是由浏览器强制执行的，但它首先是一种保护服务器的机制。当带有 Origin 标头（或 pre-flight）的请求到达时，服务器应该做出相应的反应。
@yuranos87 — 不。它根本不是为了保护服务器而设计的。同源策略旨在阻止邪恶站点使用受害者的浏览器从其他站点读取数据，这些数据应该是在其他站点和受害者之间保密的。 CORS 旨在允许其他站点让受信任站点访问该秘密数据（或者说该数据根本不是秘密）。
嗯，这就是我的意思。也许“保护服务器”并不是最准确的说法，但它是关于保护服务器上的数据。 “从其他站点读取数据” - 毕竟是关于服务器上的数据。

【解决方案3】：

让我们分解问题并尝试了解 CORS 的基本原理。

什么是跨域请求和 CORS？

跨域请求：对资源的请求（例如图像或字体）在原点之外被称为跨域请求。

当您从另一个来源请求受保护的资源时，CORS 很有帮助。

跨域请求共享：对源之外的受保护资源（如图像或字体或 XHR 请求）的请求称为跨域请求。

当可以使用身份验证/授权令牌保护资源时，为什么我们需要 CORS？

CORS 是第一道防线。当客户端（例如浏览器）和服务器都支持 CORS 时，客户端将根据服务器的指示只允许来自特定来源的请求。

默认情况下，浏览器应该按照构建浏览器的指南实现同源策略安全机制。几乎所有现代浏览器都实现了同源策略，该策略指示浏览器在来源相同的情况下允许对服务器的请求。

同源策略是浏览器的一种安全机制，你可以阅读更多关于它的信息here。正是由于浏览器的这个特性，当指定来源和来源来源不同时，浏览器会阻塞所有的请求。（服务器甚至不知道发生了这种情况，哇！）

对于更简单的用例，当资产（js、CSS、图像、字体）、XHR 资源可以同源访问时，无需担心 CORS。

如果资产托管在另一个源上或 XHR 资源托管在与源具有不同域的服务器上，则默认情况下浏览器不会拒绝跨源请求。只有使用适当的 CORS 请求和响应标头，浏览器才能进行跨域请求。

让我们看看请求和响应标头。

Request headers

原产地
访问控制请求方法
访问控制请求标头

Response headers

访问控制允许来源
访问控制允许凭据
访问控制公开标头
访问控制最大年龄
访问控制允许方法访问控制允许标头

要设置 CORS，需要 Origin 和 Access-Control-Allow-Origin 标头。浏览器会自动为每个请求添加Origin 标头，因此开发人员只需配置Access-Control-Allow-Origin 响应标头。

为了保护仅从特定域访问资源，S3 提供了配置 CORS 规则的选项。如果Access-Control-Allow-Origin header 的值为*，则允许所有跨域请求，否则定义一个逗号分隔的域列表。

使用 CORS 时需要注意几件事。

这是对受保护资源的第一级防御，而不是最终防御。
您仍然需要对资源实施适当的身份验证和授权，才能在服务器上执行 CRUD 操作。
实施同源策略是构建浏览器的指南，不是强制性的。
CORS 标头仅在客户端接受标头时才有用。只有现代浏览器接受 CORS 标头。如果您不使用浏览器发出资源请求，则 CROS 不适用。
如果您在浏览器的地址栏中键入链接，则不会应用 CORS 规则，因为浏览器不会将 Origin 标头发送到服务器。 Origin 标头仅由浏览器在源的后续资源请求（样式表、js 文件、字体）和 XHR 请求中发送。
- 如果您通过直接在地址栏中键入链接来访问资源文件，浏览器不会向该请求发送Origin 标头。

此外，如果您想限制 GET 访问，请在私有存储桶上使用 S3 预签名 URL。

【讨论】：