security - 如何保护REST-API？

Question

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

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

Answer 1

在我回答您的问题之前，我认为重要的是，首先我们要清除开发人员之间关于WHO和WHAT正在访问API的常见误解。
WHO和与您的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​​，但它不能保证请求来自您的移动应用程序。
现在，我们需要一种方法来识别正在调用您的API服务器的内容，这比大多数开发人员想象的要棘手得多。向API服务器发出请求的是什么。它确实是您的移动应用程序的真实实例，还是机器人，自动脚本或攻击者使用诸如Postman之类的工具手动在您的API服务器上戳戳？
令您感到惊讶的是，您可能最终发现它可能是您的合法用户之一，使用重新打包的移动应用程序版本或自动脚本来游戏化并利用您的服务。
好吧，为了确定问题所在，开发人员倾向于使用通常在其移动应用程序代码中进行硬编码的API密钥。一些开发人员付出了更多的努力，并在移动应用程序中在运行时计算了密钥，因此与将静态机密嵌入代码中的前一种方法相反，它成为了运行时机密。
上面的摘录摘自我写的文章《为什么您的移动应用程序需要API密钥？》，您可以阅读完整的here，这是有关API密钥的系列文章中的第一篇。
你的问题

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

如果用logging in from anywhere表示任何物理位置，则可以按照@hanshenrik的建议使用按IP地址进行阻止，但是如果要阻止从其他应用程序（不是您为其发出API密钥的应用程序）进行日志记录，那么您手中有一个非常棘手的问题需要解决，这引出了第一个问题：

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

这取决于访问API的是Web还是移动应用程序。
Web应用程序
在Web应用程序中，我们只需要使用浏览器开发工具检查源代码，或者通过右键单击查看页面源并搜索API密钥，然后将其用于任何工具（如Postman）或所需的任何自动化类型中即可，只需复制呼叫，就像我们在浏览器的“网络”标签中看到的那样即可。
对于服务于Web应用程序的API，您可以采用多个密集层，从reCaptcha V3开始，然后是Web Application Firewall（WAF），最后如果您可以负担得起User Behavior Analytics（UBA）解决方案，则可以采用多层。
Google 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功能。

所有这些解决方案都基于否定性识别模型，换句话说，他们通过识别出什么是不好的，而不是什么是好，来尽最大的努力将好与坏区别开来，因此尽管使用了先进的技术，但它们还是容易出现误报他们中的一些人，例如机器学习和人工智能。
因此，您可能经常会发现自己不必放松放松如何阻止对API服务器的访问，以免影响良好的用户。这也意味着该解决方案需要不断监控，以确认误报不会阻止您的合法用户，同时他们会适当地阻止未经授权的用户。
移动应用
从您对评论的回复：

对于移动应用程序呢？

有人可能会认为，以二进制格式发布移动应用程序后，其API密钥将是安全的，但事实并非如此，从二进制文件中提取它有时几乎与从Web应用程序中提取一样容易。
借助大量开源工具（例如，移动安全框架（MobSF），Frida，XPosed，MitmProxy等），可以轻松地反向工程移动应用程序，但是您可以在this article中看到， MobSF或使用普通Linux发行版中安装的strings实用程序。
Mobile Security Framework

移动安全框架是一种自动化的多合一移动应用程序（Android / iOS / Windows）笔测试框架，能够执行静态分析，动态分析，恶意软件分析和Web API测试。

Frida

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

xPosed

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

MiTM Proxy

面向渗透测试人员和软件开发人员的交互式TLS功能拦截HTTP代理。

关于为移动应用程序提供服务的API，可以使用移动应用程序证明解决方案来使用肯定的识别模型，该解决方案向API服务器保证发出请求的内容可以被信任，而不会出现误报。
移动应用证明
移动应用程序证明服务的作用是在运行时通过在后台运行将与云中运行的服务进行通信的SDK来确保您的移动应用程序未被篡改或未在有根设备中运行，以确保移动应用程序和设备的完整性正在运行。
在成功证明移动应用程序完整性之后，将发布并签名一个短时生存的JWT令牌，并秘密告知只有云服务器中的API服务器和移动应用程序证明服务。在移动应用证明失败的情况下，将使用API​​服务器不知道的秘密对JWT令牌进行签名。
现在，应用程序必须与每个API一起发送，并在请求的标头中调用JWT令牌。这将允许API服务器仅在可以验证JWT令牌中的签名和到期时间时才处理请求，而在验证失败时拒绝请求。
一旦移动应用程序不知道移动应用程序证明服务使用的机密，就无法在运行时对其进行反向工程，即使该应用程序被篡改，在有根设备中运行或通过正在作为连接的连接进行通信中间攻击中一名男子的目标。
移动应用证明服务已经作为Approov处的SAAS解决方案存在（我在这里工作），该服务提供了多个平台的SDK，包括iOS，Android，React Native等。集成还需要在API服务器代码中进行少量检查，以验证由云服务发出的JWT令牌。 API服务器必须能够执行此检查，才能决定服务哪些请求以及拒绝哪些请求。
结论
最后，必须根据要保护的内容的价值以及此类数据的法律要求（例如欧洲的GDPR法规）来选择用于保护API服务器的解决方案。
因此，使用API​​钥匙听起来就像锁上了房屋的门，将钥匙留在了垫子下面，但不使用它们就像是在门关闭的情况下将车停在停车场，而钥匙却在点火。