黑客在发出 API 请求时可以更改其域名吗？

Question

如果我在公共互联网上发布一个 API，但它仅供我的应用程序使用，我可以制定接受域的白名单，这样其他域就无法使用它。

但我总是想知道，黑客在向我的 API 发出 HTTP 请求时不能编辑他们的“来自域”吗？他们不能模仿其他域来欺骗我的 API，让他们相信他们是可信的吗？

Answer 1

原始 Http 标头

\n

\n

但我总是想知道，黑客在向我的 API 发出 HTTP 请求时不能编辑他们的“来自域”吗？

\n

\n

您指的是根据Fetch Standard不应出现在所有请求中的Origin ：

\n

3. HTTP extensions\n3.1. `Origin` header\n\nThe `Origin` request header indicates where a fetch originates from.\n\nThe `Origin` header is a version of the `Referer` [sic] header that does not reveal a path. \nIt is used for all HTTP fetches whose request\xe2\x80\x99s response tainting is "cors", as well as those where request\xe2\x80\x99s method is neither `GET` nor `HEAD`. \nDue to compatibility constraints it is not included in all fetches. \n

\n

让我们测试一下：

\n

$ curl http://httpbin.org/headers \n{\n  "headers": {\n    "Accept": "*/*", \n    "Host": "httpbin.org", \n    "User-Agent": "curl/7.58.0", \n    "X-Amzn-Trace-Id": "Root=1-5e907f49-3b96ed48ef957ff4c8aa435e"\n  }\n}\n

\n

正如您所看到的cURL，正确实现了 RFC 并且不发送请求Origin的标头GET。

\n

因此，即使攻击者无法欺骗它（他们可以轻松做到），您也不能依赖它，因为任何正确实现 RFC 的浏览器都会被您的 API 列入黑名单，除非您的 API 仅由非浏览器客户端访问Origin无论使用哪种 http 方法，都始终实现标头。

\n

伪造原始标头

\n

\n

难道他们不能模仿其他域来欺骗我的 API 他们是可信的吗？

\n

\n

攻击者可以看到您的正版应用程序如何执行请求并使用正确的Origin标头重播它：

\n

$ curl http://httpbin.org/headers -H "Origin: your-genuine.domain.com"\n{\n  "headers": {\n    "Accept": "*/*", \n    "Host": "httpbin.org", \n    "Origin": "your-genuine.domain.com", \n    "User-Agent": "curl/7.58.0", \n    "X-Amzn-Trace-Id": "Root=1-5e907f9a-4696e1c9ec807a0defdeca54"\n  }\n}\n

\n

了解使用您的应用程序的真实域重播请求是多么容易；）。您可以在我针对该问题给出的另一个答案How to secure REST API from replay attacks with parameter manipulation?中阅读有关重放攻击的更多信息。

\n

因此，尝试基于Origin标头来保护您的 API 是不可行的，因为首先 RFC 不允许在所有请求方法中发送它，其次伪造它是非常简单的。

\n

保护 API 服务器

\n

\n

如果我在公共互联网上发布一个 API，但它仅供我的应用程序使用，我可以制定接受域的白名单，这样其他域就无法使用它。

\n

\n

正如上面已经证明的那样，依靠域来执行请求是不可行的。

\n

现在您可能想知道如何保护您的 API 服务器不被未经授权的客户端使用？

\n

该方法将取决于您的 API 服务器应该服务的内容，仅 Web 应用程序，仅移动应用程序，两者，甚至可能是 IOT 客户端？

\n

为了让您了解如何开始应用防御层，您需要首先了解谁与什么正在访问您的 API 服务器之间的区别。你可以去阅读这篇文章部分来找到这样的说法：

\n

\n

向 API 服务器发出请求的是什么。它真的是您的移动应用程序的真实实例，还是机器人、自动化脚本或攻击者使用 Postman 等工具手动探查您的 API 服务器？

\n

我们可以通过多种方式（例如使用 OpenID Connect 或 OAUTH2 流）对移动应用程序的用户进行身份验证、授权和识别。

\n

\n

如果以上两句话不够清楚，请花几秒钟阅读链接文章中的整个部分。

\n

既然您了解了访问 API 服务器的人员和内容之间的区别，您就可以开始应用尽可能多的防御层，并且满足法律的要求。

\n

对于仅服务于移动应用程序的 API，您将希望最终采用这种类型的架构：

\n

\n

是的，移动应用程序中没有存储 API 密钥或任何其他类型的秘密，您可以在我针对该问题给出的其他答案How to secure an API REST for mobile app? (if sniffing requests gives you the \xe2\x80\x9ckey\xe2\x80\x9d)中阅读更多信息，该答案更详细地解释了该图形。

\n

对于 Web 应用程序，如果您已经阅读了重放攻击答案的先前链接，那么您可能已经了解了，但如果没有，这里又是我针对该问题提供的链接How to secure REST API from replay attacks with parameter manipulation?。此答案作为使用 HMAC 对发送到 API 服务器的请求进行签名的代码示例。

\n

更加努力

\n

如果没有我通常的建议来访问 OWASP 基金会的出色工作，我就无法完成安全答案：

\n

网络安全测试指南：

\n

\n

OWASP Web 安全测试指南包括用户可以在自己的组织中实施的“最佳实践”渗透测试框架和描述测试最常见 Web 应用程序和 Web 服务安全问题的技术的“低级”渗透测试指南。

\n

\n

移动安全测试指南：

\n

\n

移动安全测试指南 (MSTG) 是移动应用安全开发、测试和逆向工程的综合手册。

\n

\n