api - 黑客可以在发出 API 请求时更改他们的域名吗？

Question

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

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

Answer 1

Origin Http Header

But I always wonder, can't hackers edit their "from domain" when making an HTTP request to my APIs?

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

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，并且不会为 GET 请求发送 Origin header 。

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

伪造原始 header

Can't they mimic some other domain to trick my API that they're trusted?

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

$ 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"
  }
}

看看用您的应用程序的真实域重放请求是多么容易；)。您可以在此 other answer 中阅读有关重播攻击的更多信息我给出了问题 How to secure REST API from replay attacks with parameter manipulation?。

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

保护 API 服务器

If I release an API on the public internet, but it's only meant to be used by my apps, I can make a white list of accepted domains, so other domains can't use it.

如上所示，依赖域执行请求是不可行的。

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

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

为了让您了解如何开始应用防御层，您需要首先了解访问您的 API 服务器的谁 与什么 之间的区别。你可以去看this article部分查找此语句:

The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?

The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.

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

既然您了解了访问您的 API 服务器的谁 和什么 之间的区别，您就可以开始应用法律要求的尽可能多的防御层。

对于仅服务于移动应用程序的 API，您将希望以这种类型的架构结束:

是的，没有 API key 或任何其他类型的 secret 存储在移动应用程序中，您可以在此 other answer 中阅读更多相关信息我给出了 How to secure an API REST for mobile app 这个问题？ (如果嗅探请求为您提供“ key ”)，这将更详细地解释图形。

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

加倍努力

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

The Web Security Testing Guide :

The OWASP Web Security Testing Guide includes a "best practice" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues.

The Mobile Security Testing Guide :

The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.