如果我在公共互联网上发布了一个 API,但它仅供我的应用程序使用,我可以创建一个接受域的白名单,这样其他域就不能使用它。
但我总是想知道,当向我的 API 发出 HTTP 请求时,黑客不能编辑他们的“来自域”吗?他们不能模仿其他域来欺骗我的 API 以使他们信任他们吗?
如果我在公共互联网上发布了一个 API,但它仅供我的应用程序使用,我可以创建一个接受域的白名单,这样其他域就不能使用它。
但我总是想知道,当向我的 API 发出 HTTP 请求时,黑客不能编辑他们的“来自域”吗?他们不能模仿其他域来欺骗我的 API 以使他们信任他们吗?
但我总是想知道,当向我的 API 发出 HTTP 请求时,黑客不能编辑他们的“来自域”吗?
您指的是根据Fetch Standard不应出现在所有请求中的Origin :
3. HTTP extensions
3.1. `Origin` header
The `Origin` request header indicates where a fetch originates from.
The `Origin` header is a version of the `Referer` [sic] header that does not reveal a path.
It is used for all HTTP fetches whose request’s response tainting is "cors", as well as those where request’s method is neither `GET` nor `HEAD`.
Due to compatibility constraints it is not included in all fetches.
让我们测试一下:
$ curl http://httpbin.org/headers
{
"headers": {
"Accept": "*/*",
"Host": "httpbin.org",
"User-Agent": "curl/7.58.0",
"X-Amzn-Trace-Id": "Root=1-5e907f49-3b96ed48ef957ff4c8aa435e"
}
}
如您所见cURL
,正确实现了 RFC,并且不发送请求的Origin
标头GET
。
因此,即使攻击者无法欺骗它,就像他们可以轻松做到的那样,您也不能依赖它,因为任何可以正确实现 RFC 的浏览器都会被您的 API 列入黑名单,除非您的 API 仅由非浏览器客户端访问始终实现Origin
标头,无论哪种http方法。
他们不能模仿其他域来欺骗我的 API 以使他们信任他们吗?
攻击者可以看到您的正版应用程序如何处理请求并使用正确的Origin
标头重播它:
$ curl http://httpbin.org/headers -H "Origin: your-genuine.domain.com"
{
"headers": {
"Accept": "*/*",
"Host": "httpbin.org",
"Origin": "your-genuine.domain.com",
"User-Agent": "curl/7.58.0",
"X-Amzn-Trace-Id": "Root=1-5e907f9a-4696e1c9ec807a0defdeca54"
}
}
看看使用您的应用程序的真实域重播请求是多么容易;)。您可以在我为该问题提供的其他答案中阅读有关重放攻击的更多信息How to secure REST API from replay attacks with parameter manipulation?
。
因此,试图根据Origin
标头保护您的 API 是不可行的,因为首先 RFC 不允许在所有请求方法中发送它,其次是伪造它非常简单。
如果我在公共互联网上发布了一个 API,但它仅供我的应用程序使用,我可以创建一个接受域的白名单,这样其他域就不能使用它。
正如上面已经证明的那样,依靠域来执行请求是不可行的。
所以现在您可能想知道如何保护您的 API 服务器不被未经授权的客户端使用?
该方法将取决于您的 API 服务器应该服务什么,仅 Web 应用程序,仅移动应用程序,两者,甚至可能是 IOT 客户端?
为了让您了解如何开始应用防御层,您需要首先了解访问API 服务器的人员与访问对象之间的区别。你可以去阅读这篇文章部分来找到这个陈述:
向 API 服务器发出请求的内容是什么。它真的是您的移动应用程序的真实实例,还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动绕过您的 API 服务器?
谁是移动应用程序的用户,我们可以通过多种方式进行身份验证、授权和识别,例如使用 OpenID Connect 或 OAUTH2 流。
如果以上两句话还不够清楚,那就去花几秒钟阅读链接文章中的整个部分。
既然您了解了访问 API 服务器的人和对象之间的区别,那么您就可以开始应用尽可能多的防御层了,因为您可以负担得起并且是法律要求的。
对于仅服务于移动应用程序的 API,您最终会希望采用这种类型的架构:
是的,移动应用程序中没有存储 API 密钥或任何其他类型的机密,您可以在我为该问题提供的其他答案How to secure an API REST for mobile app? (if sniffing requests gives you the “key”)
中阅读更多信息,该答案更详细地解释了该图形。
对于 Web 应用程序,如果您已经阅读了关于重放攻击答案的上一个链接,您可能已经被覆盖,但如果没有,这里再次是我为问题提供的链接How to secure REST API from replay attacks with parameter manipulation?
。此答案作为使用 HMAC 对发送到 API 服务器的请求进行签名的代码示例。
如果没有我通常建议访问 OWASP 基金会的出色工作,我无法完成安全答案:
OWASP Web 安全测试指南包括一个“最佳实践”渗透测试框架,用户可以在他们自己的组织中实施它和一个“低级”渗透测试指南,描述了测试最常见的 Web 应用程序和 Web 服务安全问题的技术。
移动安全测试指南 (MSTG) 是移动应用安全开发、测试和逆向工程的综合手册。
并非每个 HTTP 请求都指定其域,因此您最多可以尝试将源 IP 映射到域。
如果您接受的域具有恒定的 IP 范围,您可以将这些域列入白名单并阻止其他所有内容。
如果攻击者在通向您的主机站点的网络层中有内部人员,则通常可以进行 IP 欺骗。没有它,攻击者可以尝试对您的 API 进行 DoS,但发送 HTTP 请求需要大量工作。
如果您使用 HTTP 标头来声明域,那么攻击者绝对可以欺骗它们。
如果您的 API 仅服务于您的应用程序,最简单的解决方案是使用 HTTPS 并对每个请求进行签名和/或身份验证(查看JWT,它现在非常流行)。
还有一些基于识别“意外”请求的解决方案,它们也不要求您的应用程序具有恒定的 IP 范围,并且将 API 开放给您不拥有的应用程序也更安全。这些是Web 应用程序防火墙 (WAF) 解决方案,有些有免费层。
要记住的关键是,有大量的“基础”黑客和少量的“大师”黑客,而安全就是从这个金字塔的较低层中剔除尽可能多的黑客。一个强大的、足智多谋的、资金充足的攻击者最终会攻击你,但更多时候,你只是希望那些想赚钱的攻击者去攻击一个更容易的目标。