API Gateway Lambda CORS 处理程序。安全获取 Origin

Question

我想为多个来源实现 CORS，并且我知道我需要通过 lambda 函数来实现，因为我无法通过 MOCK 方法来实现

exports.handler = async (event) => {
  const corsUrls = (process.env.CORS_URLS || '').split(',')
  const requestOrigin = (event.headers && event.headers.origin) || ''

  if (corsUrls.includes(requestOrigin)) {
    return {
      statusCode: 204,
      headers: {
        "Access-Control-Allow-Headers": 'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,X-Requested-With',
        'Access-Control-Allow-Origin': requestOrigin,
        'Access-Control-Allow-Methods': 'POST,DELETE,OPTIONS'
      }
    }
  }

  return {
    statusCode: 403,
    body: JSON.stringify({
      status: 'Invalid CORS origin'
    })
  }
}

首先，上面看起来还可以吗？然后我从标题event.headers.origin 获取来源。但我发现我可以手动将该标题设置为“绕过”cors。是否有可靠的方法来检测源域？

Answer 1

首先，上面看起来还可以吗？

乍一看，您的代码看起来不错，除了您的观点But I find that I can just set that header manually to "bypass" cors，我认为它没有任何重大问题。

然后我从 headers event.headers.origin 获取来源。但我发现我可以手动将该标题设置为“绕过”cors。有没有可靠的方法来检测源域？

您当前使用的代码是我能想到的如何从头顶检测原始域的唯一方法。尽管正如您所说，您可以手动设置该标头，并且标头正确或有效的保证为 0。它不应该被用作安全的信任层。对于浏览器，它们限制了如何设置此标头（请参阅Forbidden header name）。但是，如果您控制 HTTP 客户端（例如 curl、postman 等），您可以轻松发送您想要的任何标头。没有什么技术可以阻止我向您的 Web 服务器发送任何具有我想要的值的标头。

因此，归根结底，这可能不是一个大问题。如果有人篡改了该标头，他们就会面临安全风险和意外行为。有很多方法可以绕过 CORS，like this、or this、or this 也许。因此，尽管您尽最大努力执行它，但最终还是可以绕过 CORS。尽管所有这些技巧都是黑客，普通用户可能不会使用。与更改源头相同，普通用户不太可能这样做。

您可以研究一些其他技巧来尝试更多地执行它。您可以查看refer header，看看它是否与原始标头相同。同样，可以为任何标头发送任何内容，但会使其变得更难，并强制执行您想要的更多内容。

如果您假设原始标头应始终等于 API Gateway API 的域，那么您可以查看的另一件事是 API Gateway 为您提供的 event.requestContext 对象。该对象具有resourceId、stage、accountId、apiId，以及一些其他有趣的属性。您可以考虑构建一个系统，该系统还将验证这些值，并根据这些值确定 API Gateway 中的哪个 API 发出请求。这可能需要确保您已将每个域分离为单独的 API 网关 API。

我看不出event.requestContext 中的那些值可能被篡改，因为AWS 在将事件对象传递给您之前设置了它们。它们源自 AWS，不能轻易被用户篡改（除非整个请求的构成发生变化）。与刚刚随请求一起发送的标头相比，防篡改肯定要少得多，AWS 会传递给您。

当然，您可以将其中的多个解决方案组合在一起，以创建一个更能执行您的政策的解决方案。请记住，安全性是一个范围，因此您可以在该范围内走多远。

我还鼓励您记住，CORS 并不完全是为了隐藏互联网上的信息。我分享的那些关于如何使用简单的后端系统或插件绕过 CORS 的方法表明它并非完全万无一失，如果有人真的想伪造标头，他们将能够做到。但是，当然，在一天结束时，您可以尽可能地努力实现这一目标。但这需要实现和编写大量代码并进行大量检查才能实现。

您确实必须问自己目标和目标是什么。我认为这真的决定了你的下一步。您可能会确定您当前的设置已经足够好，无需进一步更改。您可能确定您正在尝试保护敏感数据不被发送到未经授权的来源，在这种情况下，CORS 可能不是一个可靠的解决方案（由于能够将该标头设置为任何内容）。或者您可能会确定您可能希望将事情锁定更多，并使用其他一些信号来进一步执行您的政策。

---

tldr 您可以确定将Origin 标头设置为您想要的任何内容，因此不应完全信任它。如果您假设您的原始标头应该始终等于您的 API Gateway API 的域，您可以尝试使用 event.requestContext 对象来获取有关 API Gateway 中的 API 的更多信息，以获取有关请求的更多信息。您还可以查看 Refer 标头，看看是否可以将其与 Origin 标头进行比较。

---

更多信息：

• Is HTTP Content-Length Header Safe to Trust? （免责声明：我不久前在 Stack Overflow 上发布了这个问题）
• Example Amazon API Gateway AWS Proxy Lambda Event
• 绕过 CORS
  • https://github.com/Rob--W/cors-anywhere
  • https://chrome.google.com/webstore/detail/allow-control-allow-origi/nlfbmbojpeacfghkpbjhddihlkkiljbi
  • https://www.thepolyglotdeveloper.com/2014/08/bypass-cors-errors-testing-apis-locally/
• Refer 标头
  • https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer
  • https://en.wikipedia.org/wiki/HTTP_referer

Answer 2

验证多个来源的唯一方法是像您所做的那样，让您的 lambda 读取 Origin 标头，将其与您希望允许的域列表进行比较，如果匹配，则将 Origin 标头的值返回给客户端作为响应中的 Access-Control-Allow-Origin 标头。

信息：Origin 标头是由用户代理自动设置的标头之一。因此任何人都无法通过编程或扩展进行更改。更多详情，请查看MDN。