我有一个存储私人信息的网站，可以通过使用秘密 api 密钥的请求访问它。
我的 Android 应用程序必须访问该私人信息，为此它使用存储和使用秘密 api 密钥的代理服务器与网站通信
问题在于，仅仅使用Wireshark，或者在app资源文件中找到字符串，就可以看到代理服务器的url，并使用它从网站获取私有数据
我怎样才能使这个系统安全？我如何确定除了 Android 应用程序之外没有其他人可以使用代理？
谢谢！
【问题讨论】：
标签： android node.js security authorization android-volley
我有一个存储私人信息的网站，可以通过使用秘密 api 密钥的请求访问。
从您将秘密放在客户端的那一刻起，它就不再是秘密了，因为现在是公开的，任何人都可以通过对应用程序进行逆向工程或使用代理拦截流量或仅使用工具查看流量来查看它你提到了，Wireshark。
我的 Android 应用程序必须访问该私人信息，为此它使用存储并使用秘密 api 密钥与网站通信的代理服务器
使用代理服务器并不能解决问题，因为代理服务器不知道 什么 在调用它。就目前而言，代理服务器对知道如何调用它的公众开放，正如您已经知道并指出的那样：
问题是仅仅使用Wireshark，或者在app资源文件中查找字符串，有人可以看到代理服务器的url并使用它从网站获取私有数据。
另一种方法是使用像MiTM Proxy 这样的代理工具，我认为这将允许更轻松地提取 API 密钥，正如您在文章 Steal that API Key with a Man in the Middle Attack 中看到的那样：
虽然我们可以使用 JNI/NDK 等高级技术在移动应用程序代码中隐藏 API 密钥，但它不会阻止某人执行中间人攻击以窃取 API 密钥。事实上，中间人攻击很容易，甚至可以由非开发人员实现。
我怎样才能使这个系统安全？我如何确定除了 Android 应用程序之外没有其他人可以使用代理？
好吧，你给自己买了一个很难解决的问题，很多人会说这只会让攻击者更难解决，这在某种程度上是正确的，因为很多开发人员并不知道移动应用认证概念，允许后端服务器仅处理来自原始应用的请求。
在我向您解释这个概念之前，我想澄清开发人员对 WHO 与 WHAT 访问后端服务器的一个常见误解。
为了更好地理解 WHO 和 WHAT 访问 API 服务器之间的区别，让我们使用这张图片：
预期通信通道表示移动应用程序正按您的预期被合法用户使用，没有任何恶意，使用未篡改的移动应用程序版本，并直接与 API 服务器通信，而不会受到中间人的攻击。
实际的渠道可能代表几种不同的场景，例如有恶意的合法用户可能正在使用重新打包的移动应用程序版本，黑客使用移动应用程序的正版版本，而中间人正在攻击它，了解移动应用程序和 API 服务器之间的通信是如何完成的，以便能够自动攻击您的 API。许多其他情况也是可能的，但我们不会在这里一一列举。
我希望现在您可能已经知道为什么 WHO 和 WHAT 不一样，但如果不一样，一会儿就会清楚。
WHO 是移动应用的用户，我们可以通过多种方式进行身份验证、授权和识别，例如使用 OpenID Connect 或 OAUTH2 流。
通常，OAuth 代表资源所有者向客户端提供对服务器资源的“安全委托访问”。它指定了资源所有者授权第三方访问其服务器资源而不共享其凭据的过程。 OAuth 专为与超文本传输协议 (HTTP) 一起使用而设计，本质上允许授权服务器在资源所有者的批准下将访问令牌颁发给第三方客户端。然后第三方使用访问令牌访问资源服务器托管的受保护资源。
OpenID Connect 1.0 是 OAuth 2.0 协议之上的简单身份层。它允许客户端根据授权服务器执行的身份验证来验证最终用户的身份，并以可互操作和类似 REST 的方式获取有关最终用户的基本配置文件信息。
虽然用户身份验证可能会让 API 服务器知道 谁 正在使用 API，但它不能保证请求源自您所期望的 WHAT，即原始版本的移动应用。
现在我们需要一种方法来识别 什么 正在调用 API 服务器，而这里的事情变得比大多数开发人员想象的要棘手。 WHAT 是向 API 服务器发出请求的事物。它是真正的移动应用程序实例，还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动探索 API 服务器？
令您惊讶的是，您最终可能会发现它可能是使用重新打包版本的移动应用程序或试图游戏化并利用应用程序提供的服务的自动化脚本的合法用户之一。
好吧，为了识别什么，开发人员倾向于使用 API 密钥，通常他们将其硬编码在他们的移动应用程序的代码中。一些开发人员加倍努力并在运行时在移动应用程序中计算密钥，因此它成为运行时机密，而不是前一种方法，即在代码中嵌入静态机密。
上面的文章摘自我写的一篇文章，标题为为什么你的移动应用需要一个API KEY？，你可以阅读全文here，这是第一篇有关 API 密钥的系列文章中的文章。
我怎样才能使这个系统安全？
根据您的预算和资源，您可能会采用一系列不同的方法和技术来保护您的 API 服务器，我将开始列举一些最常用的方法，但在此之前，我想离开这个注意：
作为最佳实践，移动应用或网络应用应仅与您控制的 API 服务器通信，并且对第三方 API 服务的任何访问都必须由您控制的同一 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 功能。
所有这些解决方案都基于否定识别模型，换句话说，它们会尽力通过识别什么是坏的而不是什么来区分好与坏，因此它们很容易出现误报，尽管其中一些人使用的先进技术，例如机器学习和人工智能。
因此，您可能会发现自己经常不得不放松阻止对 API 服务器的访问的方式，以免影响好用户。这也意味着此解决方案需要持续监控，以验证误报不会阻止您的合法用户，同时它们是否正确阻止了未经授权的用户。
关于服务于移动应用程序的 API，可以通过使用移动应用程序证明解决方案来使用积极的识别模型，该解决方案向 API 服务器保证请求可以被信任而没有误报的可能性，我将把它解释为回复你的第二个问题。
我如何确定除了 Android 应用程序之外没有其他人可以使用代理？
正如我在回答开头提到的，移动应用证明概念可能是您解决问题的最佳选择。
移动应用证明解决方案的作用是确保您的移动应用在运行时没有被篡改，没有在有根设备中运行，没有被 xPosed 或 Frida 等框架检测，没有受到中间人攻击，这是通过在后台运行 SDK 来实现的。在云中运行的服务将挑战应用程序，并根据响应证明移动应用程序和设备正在运行的完整性，因此 SDK 永远不会对任何决定负责。
将您自己的脚本注入黑盒进程。挂钩任何功能、监视加密 API 或跟踪私有应用程序代码，无需源代码。编辑，点击保存，立即查看结果。所有这些都无需编译步骤或程序重新启动。
Xposed 是一个模块框架，可以在不触及任何 APK 的情况下改变系统和应用的行为。这很棒，因为这意味着模块可以在不同版本甚至 ROM 上工作而无需任何更改（只要原始代码没有太大更改）。它也很容易撤消。
一个交互式的支持 TLS 的拦截 HTTP 代理，供渗透测试人员和软件开发人员使用。
成功证明移动应用程序的完整性后，会发出一个短期 JWT 令牌，并使用只有云中的 API 服务器和移动应用程序证明服务知道的秘密进行签名。如果移动应用证明失败，JWT 令牌会使用 API 服务器不知道的秘密进行签名。
现在，应用程序必须在每个 API 调用中发送请求标头中的 JWT 令牌。这将允许 API 服务器仅在可以验证 JWT 令牌中的签名和过期时间时服务请求，并在验证失败时拒绝它们。
一旦移动应用程序不知道移动应用程序证明服务使用的秘密，即使应用程序被篡改、在有根设备中运行或通过正在成为中间人攻击的目标。
Mobile App Attestation 服务已经作为 Approov（我在这里工作）的 SAAS 解决方案存在，它为多个平台提供 SDK，包括 iOS、Android、React Native 等。集成还需要对 API 服务器代码进行小检查，以验证云服务发布的 JWT 令牌。此检查对于 API 服务器能够决定服务哪些请求和拒绝哪些请求是必要的。
最后，为保护您的 API 服务器而使用的解决方案必须根据您要保护的内容的价值以及该类型数据的法律要求（例如欧洲的 GDPR 法规）来选择。
OWASP Mobile Security Project - Top 10 risks
OWASP 移动安全项目是一个集中资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制以减少其影响或被利用的可能性。
【讨论】：