如何保护 REST-API？

Posted 2023-03-10

【中文标题】如何保护 REST-API？

【英文标题】：How do I secure a REST-API?

【发布时间】：2019-08-21 11:00:59

【问题描述】：

我已经设置了一个带有身份验证的 API，但我只想允许某些应用程序和网站访问它。我该怎么办？

我已为登录后只能访问 API 的用户设置了身份验证，但是，如何防止他们从任何地方登录？

【问题讨论】：

ip 白名单。您无法阻止其他应用程序以白名单应用程序为幌子进行逆向工程和利用该 API。

IP 白名单会起作用吗？移动应用程序呢？

【参考方案1】：

在我回答您的问题之前，我认为重要的是首先我们要澄清开发人员之间的一个常见误解，即WHO 和WHAT 正在访问 API。

与您的 API 服务器通信的对象和对象之间的区别

为了更好地了解 WHO 和 WHAT 访问您的移动应用之间的区别，让我们使用这张图片：

预期通信渠道表示您的移动设备正按您的预期被合法用户使用，没有任何恶意，使用您的移动应用程序的未篡改版本，并直接与您的 API 服务器通信，而不会受到中间人的攻击。

实际的渠道可能代表几种不同的场景，例如怀有恶意的合法用户可能正在使用您的移动应用的重新打包版本，黑客使用您的移动应用的正版版本而中间人攻击它以了解移动应用程序和 API 服务器之间的通信是如何进行的，以便能够自动攻击您的 API。许多其他情况也是可能的，但我们不会在这里一一列举。

我希望现在您可能已经知道为什么 WHO 和 WHAT 不一样，但如果不一样，一会儿就会清楚。

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

OAUTH

通常，OAuth 代表资源所有者向客户端提供对服务器资源的“安全委托访问”。它指定了资源所有者授权第三方访问其服务器资源而不共享其凭据的过程。 OAuth 专为与超文本传输​​协议 (HTTP) 一起使用而设计，本质上允许授权服务器在资源所有者的批准下将访问令牌颁发给第三方客户端。然后第三方使用访问令牌访问资源服务器托管的受保护资源。

OpenID Connect

OpenID Connect 1.0 是 OAuth 2.0 协议之上的简单身份层。它允许客户端根据授权服务器执行的身份验证来验证最终用户的身份，并以可互操作和类似 REST 的方式获取有关最终​​用户的基本配置文件信息。

虽然用户身份验证可能会让您的 API 服务器知道 谁 正在使用 API，但它不能保证请求来自您所期望的 WHAT，即您的移动应用。

现在我们需要一种方法来识别 什么 正在调用您的 API 服务器，而这里的事情变得比大多数开发人员想象的要棘手。 WHAT 是向 API 服务器发出请求的事物。它真的是您的移动应用程序的真实实例，还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动在您的 API 服务器周围探查？

令您惊讶的是，您最终可能会发现它可能是您的合法用户之一，他们使用重新打包的移动应用程序版本或尝试游戏化并利用您的服务的自动化脚本。

好吧，为了识别什么，开发人员倾向于使用 API 密钥，通常他们将其硬编码在他们的移动应用程序的代码中。一些开发人员加倍努力并在运行时在移动应用程序中计算密钥，因此它成为运行时机密，而不是前一种方法，即在代码中嵌入静态机密。

以上文章摘自我写的一篇题为为什么你的移动应用需要一个API KEY？的文章，你可以阅读全文here，这是第一篇有关 API 密钥的系列文章中的文章。

您的问题

我已经为登录后只能访问 API 的用户设置了身份验证，但是，如何防止他们从任何地方登录？

如果logging in from anywhere 指的是任何物理位置，那么您可以按照@hanshenrik 的建议使用 IP 地址阻止，但如果您的意思是阻止来自其他应用程序的日志记录，那不是您发布 API 的应用程序钥匙，那么你有一个非常困难的问题要解决，这就引出了你的第一个问题：

我已经设置了一个带有身份验证的 API，但我只想允许某些应用程序和网站访问它。我该怎么办？

这取决于访问 API 的什么是网络应用程序还是移动应用程序。

网络应用程序

在 web 应用中，我们只需要使用浏览器开发工具检查源代码，或者通过右键单击查看页面源并搜索 API 密钥，然后在任何工具中使用它，例如 Postman 或任何类型的我们想要的自动化，只需复制我们在浏览器的网络选项卡中看到的调用。

对于服务于 Web 应用程序的 API，您可以使用多层密集层，从 reCaptcha V3 开始，然后是 Web Application Firewall(WAF)，最后如果您负担得起，则可以使用 User Behavior Analytics(UBA) 解决方案。

谷歌reCAPTCHA V3：

reCAPTCHA 是一项免费服务，可保护您的网站免受垃圾邮件和滥用。 reCAPTCHA 使用高级风险分析引擎和自适应挑战来防止自动化软件在您的站点上参与滥用活动。它在让您的有效用户轻松通过的同时做到这一点。

...帮助您检测网站上的滥用流量，而不会产生任何用户摩擦。它会根据与您的网站的互动返回一个分数，并让您更灵活地采取适当的行动。

WAF - Web Application Firewall:

Web 应用程序防火墙（或 WAF）过滤、监控和阻止进出 Web 应用程序的 HTTP 流量。 WAF 与常规防火墙的区别在于，WAF 能够过滤特定 Web 应用程序的内容，而常规防火墙充当服务器之间的安全门。通过检查 HTTP 流量，它可以防止源自 Web 应用程序安全漏洞的攻击，例如 SQL 注入、跨站点脚本 (XSS)、文件包含和安全错误配置。

UBA - User Behavior Analytics:

Gartner 定义的用户行为分析 (UBA) 是一个关于检测内部威胁、有针对性的攻击和金融欺诈的网络安全流程。 UBA 解决方案着眼于人类行为模式，然后应用算法和统计分析从这些模式中检测出有意义的异常——表明潜在威胁的异常。 UBA 不是跟踪设备或安全事件，而是跟踪系统的用户。 Apache Hadoop 等大数据平台通过分析 PB 级数据以检测内部威胁和高级持续性威胁，正在增加 UBA 功能。

所有这些解决方案都基于否定识别模型，换句话说，它们通过识别 WHAT 是坏的而不是 WHAT 来尽力区分好与坏是好的，因此它们很容易出现误报，尽管其中一些使用了先进的技术，例如机器学习和人工智能。

因此，您可能会发现自己经常不得不放松阻止对 API 服务器的访问的方式，以免影响好用户。这也意味着此解决方案需要持续监控，以验证误报不会阻止您的合法用户，同时它们是否正确阻止了未经授权的用户。

移动应用

来自您对评论的回复：

移动应用程序呢？

有些人可能认为，一旦移动应用程序以二进制格式发布，他们的 API 密钥就会是安全的，但事实证明并非如此，从二进制文件中提取它有时几乎与从网络中提取它一样容易应用。

通过大量开源工具（例如 Mobile Security Framework (MobSF)、Frida、XPosed、MitmProxy 等），对移动应用程序进行逆向工程变得很容易，但正如您在 this article 中看到的那样，它可以使用 MobSF 或安装在普通 Linux 发行版中的 strings 实用程序来完成。

Mobile Security Framework

Mobile Security Framework 是一种自动化的一体化移动应用程序 (android/ios/Windows) 渗透测试框架，能够执行静态分析、动态分析、恶意软件分析和 Web API 测试。

Frida

将您自己的脚本注入黑盒进程。挂钩任何功能、监视加密 API 或跟踪私有应用程序代码，无需源代码。编辑，点击保存，立即查看结果。所有这些都无需编译步骤或程序重新启动。

xPosed

Xposed 是一个模块框架，可以在不触及任何 APK 的情况下改变系统和应用的行为。这很好，因为这意味着模块可以在不同版本甚至 ROM 上工作而无需任何更改（只要原始代码没有太大更改）。它也很容易撤消。

MiTM Proxy

一个交互式的支持 TLS 的拦截 HTTP 代理，供渗透测试人员和软件开发人员使用。

关于服务于移动应用程序的 API，可以通过使用移动应用程序证明解决方案来使用积极的识别模型，该解决方案向 API 服务器保证 WHAT 发出的请求是可信的，而不会出现错误积极的。

移动应用证明

移动应用证明服务的作用是在运行时通过在后台运行 SDK 来保证您的移动应用没有被篡改或没有在有根设备中运行，该 SDK 将与在云中运行的服务进行通信以证明移动应用程序和正在运行的设备的完整性。

成功证明移动应用程序的完整性后，会发出一个短期 JWT 令牌，并使用只有云中的 API 服务器和移动应用程序证明服务知道的秘密进行签名。如果移动应用证明失败，JWT 令牌会使用 API 服务器不知道的秘密进行签名。

现在，应用程序必须在每个 API 调用中发送请求标头中的 JWT 令牌。这将允许 API 服务器仅在可以验证 JWT 令牌中的签名和过期时间时服务请求，并在验证失败时拒绝它们。

一旦移动应用程序不知道移动应用程序证明服务使用的秘密，即使应用程序被篡改、在有根设备中运行或通过正在成为中间人攻击的目标。

Mobile App Attestation 服务已作为 SAAS 解决方案存在于 Approov（我在这里工作），它为多个平台提供 SDK，包括 iOS、Android、React Native 等。集成还需要对 API 服务器代码进行小检查，以验证云服务发布的 JWT 令牌。此检查对于 API 服务器能够决定服务哪些请求和拒绝哪些请求是必要的。

结论

最终，必须根据您要保护的内容的价值以及该类型数据的法律要求（例如欧洲的 GDPR 法规）来选择用于保护您的 API 服务器的解决方案。

因此，使用 API 密钥可能听起来像是锁上了你家的门并将钥匙放在垫子下面，但不使用它们就像让你的车停在门关闭的情况下，但钥匙在点火装置中。