谁和什么正在访问API服务器

Question

我创建了一个Restful API，一个网站（ReactJS / Ruby on Rails）和一个移动应用（React Native）。

我正在使用API在网站和移动应用上显示和处理数据。

在网站上，我正在使用 jQuery AJAX请求，看起来像这样：

...some other code
componentDidMount () {
  $.getJSON('https://example.com/api/v1/accounts?key=MASTER-API-KEY', (data) => {
    this.setState({
      accounts: data.accounts
    });
  });
}
...some other code

在移动应用中，我使用的是获取，看起来像这样：

...some other code
fetch('https://example.com/api/v1/accounts?key=MASTER-API-KEY', {
  method: 'GET',
...some other code

用户还具有自己的API密钥，这些API密钥基于用户级别具有有限的特权。

如果只有他们发送了有效的API密钥，我已经可以处理请求。但是在网站和应用程序上，我使用的是可以访问所有内容的主API密钥。

我相信可以在网站上的源文件中看到它，并且可以在移动应用中对其进行反向工程。

我为网站提供的可能解决方案是在服务器中进行该过程而不是使用AJAX，但是如何在我的ReactJS组件上访问它？

对于移动应用程序，我应该切换到使用Swift / Java并在那里进行请求而不是获取吗？

Answer 1

在React中，我制作了一个.env文件并将其配置添加到其中。

.env文件：

REACT_APP_SPOTIFY_REDIRECT_URI="xxxxxx"
REACT_APP_SPOTIFY_PUBLIC_CLIENT_ID="xxxxxxx"

如果我想使用这些参数，请通过以下行调用：

const consumer_public_key = process.env.REACT_APP_SPOTIFY_PUBLIC_CLIENT_ID;

对此我不确定，但是您需要在要成功调用react的参数的前缀上写REACT_APP _。

Answer 2

谁和什么正在访问API服务器

我首先要明确区分什么和 WHO 正在访问API服务器。

WHO 是移动应用程序的用户，您可以通过多种方式（例如使用OpenID或OAUTH2流）进行身份验证，授权和标识。

现在，您需要一种方法来识别正在调用API服务器的什么，这比大多数开发人员想象的要棘手得多。什么是向API服务器发出请求的东西，是真的是您真正的移动应用程序，还是机器人，自动脚本或攻击者使用诸如Postman之类的工具手动在您的API服务器上乱逛？

可以识别什么的开发人员倾向于使用API密钥，这些密钥通常会在其移动应用程序的代码中进行硬编码，有些则花了很多功夫并在运行时计算移动应用程序因此成为动态的秘密，与以前的方法相反，后者是嵌入代码中的静态秘密。

API密钥问题

如果只有他们发送了有效的API密钥，我已经可以处理请求。但是在网站和应用程序上，我使用的是可以访问所有内容的主API密钥。我相信可以在网站的源文件中看到它，并且可以在移动应用中对其进行反向工程。

在网络应用中，我们只需要使用浏览器开发工具检查源代码，或者右键单击查看页面源并搜索API密钥即可。

在移动应用程序上，我们可以使用Linux上的string命令对二进制文件进行快速监视来开始：

$ strings -aw app-debug.apk | grep -C 1 '_API_' -
ic_launcher_round
GRADLE_API_KEY
GRADLE_ENV_API_KEY
abc_action_bar_home_description

要获得更完整和详细的扫描信息，MobSF将帮助您对移动应用程序二进制文件进行反向工程，以提取API密钥并枚举其他攻击媒介。

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

因此，在客户端运行的任何需要秘密访问API的内容都可能以不同的方式被滥用，您可以在this series的有关移动API安全技术的文章中了解更多信息。本文将教您如何使用API密钥，用户访问令牌，HMAC和TLS固定来保护API以及如何绕过它们。

捍卫API服务器

但是如何在我的ReactJS组件上访问它？

很抱歉，但是我没有足够的知识为您提供帮助，但请继续阅读以了解如何保护API服务器。

我为网站提供的可能解决方案是在服务器中进行该过程，而不是使用AJAX ...？

对于移动应用程序，我应该切换到使用Swift / Java并在那里进行请求而不是获取吗？

移动应用程序或Web应用程序只能与您控制的API服务器通信，并且对第三方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解决方案存在（我在这里工作），该服务提供了多个平台的SDK，包括iOS，Android，React Native等。集成还需要在API服务器代码中进行少量检查，以验证由云服务发出的JWT令牌。对于API服务器来说，必须进行此检查才能决定要处理的请求和拒绝的请求。

结论

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

因此，使用API钥匙听起来就像锁上了房屋的门，将钥匙留在了垫子下面，但不使用它们就像是在门关闭的情况下将车停在停车场，而钥匙却在点火开关中。

Answer 3

如果您正在节点上进行开发，这应该可以工作（据我所知）：

using process.env by hackernoon

如何保护主API密钥？

3 个答案:

谁和什么正在访问API服务器

API密钥问题

捍卫API服务器

移动应用证明

结论