javascript - 如何只接受来 self 自己的应用程序的请求？

Question

因此，我想知道如何仅确保对我的静态api的CRUD操作仅由我自己的应用程序接受，而不受外部人员接受？我的应用程序由制作RESTful API的Node js后端和与RESTful API进行通信的前端Android组成。我见过JWT令牌，但是它仅适用于登录系统，但是我有一个没有登录系统的应用程序。

原因是我不想让局外人从我的api中读取或什至写入数据，例如POSTMAN。如何确保使用我的应用的人可以对我的API执行CRUD操作？

Answer 1

WHO与访问API服务器之间的区别

在我们理解可以解决您的问题的选项之前，我想澄清一下开发人员中关于WHO和WHAT正在访问API服务器的常见误解。

为了更好地了解WHO和WHAT访问API服务器之间的区别，让我们使用以下图片：



预期的通信渠道表示合法用户在没有任何恶意意图的情况下正按预期使用该移动应用程序，使用该移动应用程序的未修改版本，并直接与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的CRUD操作仅由我自己的应用程序接受，而不受外部人员接受？


保护和锁定API服务器到您自己的应用程序不是一件容易的事，因为用于标识WHO或WHAT的任何秘密都相对容易被攻击者抓住。您可以阅读文章How to Extract an API Key from a Mobile App by Static binary analysis，在此我将演示如何借助几种开源工具（如使用Mobile Security Framework）将其提取，或者您可以阅读使用开源工具的另一篇文章Steal that API Key with a Man in the Middle Attack。 MiTM Proxy在中间攻击中发动人以提取API密钥。

到现在为止，您可能已经意识到，很难保护API服务器免受攻击者的滥用，因为在他们提取秘密以标识WHO和WHAT正在提出请求之后，他们可以使用您关注的工具，邮递员或其他任何人来攻击您的API服务器，并假装是WHO和WHAT的合法身份。

您现在可能会问...我该如何保护我的API服务器？

防御API服务器

最佳做法是，移动应用程序或Web应用程序应仅与您控制下的API服务器通信，对第三方API服务的任何访问都必须由您控制的同一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，可以通过使用移动应用程序证明解决方案来使用肯定的识别模型，该解决方案向API服务器保证可以信任请求而不会出现误报。

行动应用程式证明

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

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

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

一旦移动应用程序不知道移动应用程序证明服务使用的机密，就无法在运行时对其进行反向工程，即使该应用程序被篡改，在有根设备中运行或通过正在作为连接的连接进行通信中间攻击中一名男子的目标。

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

结论


  原因是我不想让局外人从我的api读取或什至从POSTMAN写入数据。


好吧，Postman默认使用自定义的HTTP标头，因此很容易阻止来自它的请求，但这仅在用户未禁用Postamn的此功能且攻击者始终禁用它们的情况下才有效，因此此措施将不会非常有效，而Postman并不是唯一的工具，那么您需要在防御上比这更加复杂。


  如何确保使用我的应用的人可以对我的API执行CRUD操作？


我想您想表示只有使用您的应用程序的人才能执行CRUD操作。

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

因此，我建议您实施一个移动应用证明解决方案，因为它是一个可以解决您的问题的积极模型。