如何保护 REST-API？

Question

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

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

Answer 1

在我解决您的问题之前，我认为重要的是首先我们清除开发人员之间关于谁和什么正在访问 API 的一个普遍误解。

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

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

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

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

我希望现在你可能已经知道为什么WHO和WHAT不一样了，但如果不一样，马上就会明白。

该世界卫生组织是移动应用程序，我们可以验证，授权和以多种方式确定，比如使用OpenID登录连接或流的oauth2的用户。

身份验证

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

OpenID 连接

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

虽然用户认证可以让你的API服务器知道世卫组织正在使用的API，它不能保证请求源自什么你期待，你的移动应用程序。

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

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

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

以上文章摘自我写的一篇文章，题为为什么您的移动应用程序需要 API 密钥？，您可以在此处完整阅读，这是有关 API 密钥的系列文章中的第一篇。

你的问题

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

如果logging in from anywhere您的意思是任何物理位置，那么您可以使用@hanshenrik 已经建议的通过 IP 地址进行阻止，但是如果您的意思是阻止其他应用程序的日志记录，那些不是您为其颁发 API 密钥的应用程序，那么您有你手中的一个非常难解决的问题，这就引出了你的第一个问题：

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

如果这将取决于什么是访问的API是一个Web或移动应用程序。

Web应用程序

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

对于为 Web 应用程序提供服务的 API，您可以使用多层密集层，从reCaptcha V3开始，然后是Web 应用程序防火墙(WAF)，最后是用户行为分析(UBA) 解决方案。

谷歌reCAPTCHA V3：

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

...帮助您在没有任何用户摩擦的情况下检测网站上的滥用流量。它根据与您网站的交互返回一个分数，并为您提供更大的灵活性来采取适当的行动。

WAF - Web 应用程序防火墙：

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

UBA - 用户行为分析：

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

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

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

移动应用程序

来自您对评论的回复：

对于移动应用程序呢？

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

通过大量开源工具（如移动安全框架（MobSF）、Frida、XPosed、MitmProxy 等）可以轻松地对移动应用程序进行逆向工程，但正如您在本文中看到的，可以使用 MobSF 完成或者使用strings安装在普通 Linux 发行版中的实用程序。

移动安全框架

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

弗里达

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

摆姿势

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

中间人代理

用于渗透测试人员和软件开发人员的交互式 TLS 拦截 HTTP 代理。

提供服务的移动应用正性识别模型关于API可通过使用移动应用认证的解决方案，保证向API服务器使用什么正在请求是可以信任的，不会产生误报的可能性。

移动应用认证

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

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

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

一旦移动应用程序认证服务使用的秘密不被移动应用程序知道，即使应用程序被篡改、在有根设备中运行或通过连接进行通信，也无法在运行时对其进行逆向工程。中间人攻击的目标。

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

结论

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

因此，使用 API 密钥可能听起来像是锁住家门并将钥匙留在垫子下，但不使用 API 密钥就像将车停在门关闭的情况下，但钥匙在点火开关中。