说我有一个API，用户可以在其中通过OAuth2登录。我仅允许受信任的应用程序与此API的一部分进行交互的选项是什么？例如，我想拥有一个移动应用程序和一个Web应用程序，但是我不希望其他人开发与该API交互的应用程序。
换句话说，Facebook，Twitter和Instagram如何阻止人们从他们的移动应用程序中克隆客户端ID，并像使用官方应用程序一样使用整个API？
答案 0 :(得分：1)
在我解决您的问题之前，我想弄清楚谁和访问API服务器的内容之间的区别。
WHO 是移动应用程序的用户，您可以通过多种方式（例如使用OpenID或OAUTH2流）进行身份验证，授权和标识。
现在，您需要一种方法来识别正在调用API服务器的什么，这比大多数开发人员想象的要棘手得多。 什么是向API服务器发出请求的东西，是真的是您真正的移动应用程序，还是机器人，自动脚本或攻击者使用诸如Postman之类的工具手动在您的API服务器上乱逛？
可以识别什么的开发人员倾向于使用API密钥，这些密钥通常会在其移动应用程序的代码中进行硬编码，有些则花了很多功夫并在运行时计算移动应用程序因此成为动态的秘密，与以前的方法相反，后者是嵌入代码中的静态秘密。
说我有一个API，用户可以在其中通过OAuth2登录。对于仅允许受信任的应用程序与此API的一部分进行交互，我有哪些选择？
您发现自己很难解决...
如果您的API仅服务于移动应用程序，则可以保留您的措辞，但是从创建需要用于服务器Web应用程序的API的那一刻起，您将无法再继续使用措辞allowing only trusted applications，您将不得不满足于某些要求在preventing access of unauthorized applications附近。
Web应用程序的问题在于，您只需要使用浏览器开发工具检查网页源代码，就能将用于标识Web应用程序的所有机密提取到API服务器。
对于移动应用程序，一些开发人员会误以为一旦以二进制形式发布它们就无法提取秘密或很难提取……好吧，让我们看看Linux中的strings命令如何为我们提供帮助：< / p>
$ strings -aw app-debug.apk | grep -C 1 '_API_' -
ic_launcher_round
GRADLE_API_KEY
GRADLE_ENV_API_KEY
abc_action_bar_home_description
您可以通过在创建发行版时混淆代码来防止出现上述情况，但是我们只需要使用一些更复杂的工具，例如Mobile Security Framework（MobSF），就可以使用一系列其他开放源代码工具来实现。反编译二进制文件并对其进行静态分析，以枚举所有攻击媒介并暴露嵌入在代码中的秘密。
Mobile Security Framework是一个自动化的多合一移动应用程序（Android / iOS / Windows）笔测试框架，能够执行静态分析，动态分析，恶意软件分析和Web API测试。
因此，在客户端运行的任何需要秘密访问API的内容都可能以不同的方式被滥用，您可以在this series的有关移动API安全技术的文章中了解更多信息。本文将教您如何使用API密钥，用户访问令牌，HMAC和TLS固定来保护API以及如何绕过它们。
换句话说，Facebook，Twitter和Instagram如何阻止人们从他们的移动应用程序中克隆客户端ID，并像使用官方应用程序一样使用整个API？
我不知道它们专门用于通过克隆的标识符来防止API滥用的方法，但是任何想要保护其API不受非官方客户端滥用的人都将使用Web应用程序防火墙（WAF）和用户行为分析（UBA） ）采用机器学习和人工智能来检测不良行为并阻止其访问API的解决方案。
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功能。
此方法的问题在于，它基于否定检测模型，该模型试图根据模式识别坏人，并且往往会产生误报，从而放宽了阻止策略，以免遗漏合法用户，意味着一些坏家伙总会找到解决方法的。
例如，我想拥有一个移动应用程序和一个Web应用程序，但是我不希望其他人开发与该API交互的应用程序。
对于您的网络应用程序，我会在网站的所有页面上使用reCAPTCHA V3，以使Google区分人与机器人。这种检测是在后台完成的，不需要与用户互动。
Google reCAPTCHA V3：
reCAPTCHA是一项免费服务，可保护您的网站免受垃圾邮件和滥用的侵害。 reCAPTCHA使用高级风险分析引擎和适应性挑战，以防止自动化软件参与您网站上的滥用行为。这样做是为了让您的有效用户轻松通过。
...可帮助您检测网站上的滥用流量，而不会引起用户的摩擦。它会根据与您网站的互动情况返回得分，并为您提供更大的灵活性以采取适当的措施。
仅凭这是一个否定的检测模型，单靠这还不够，而且还会有误报。但这是一个让脚本小子望而却步的好开始。
对于最具决定性的攻击者，您将需要使用已经提到的WAF和UBA解决方案，这种解决方案的部署和维护将更加复杂，但是一旦他们尽力而为，就无法消除它们。 API滥用。
第一步是将移动设备中的机密限制为一个，用于访问API服务器的机密以及您需要从移动应用程序访问的所有其他第三方服务，您应该将其委派给API服务器，这样就不会泄露在移动应用中，可以访问您的第三方服务的键。
您可以看到this repo，这是我为我的下一篇博客文章（尚未发布）创建的一个虚拟Android APP，其中显示了几种隐藏秘密的技术。剧透警报，Android中最好的方法是this one：
#include <jni.h>
#include <string>
#include "api_key.h"
extern "C" JNIEXPORT jstring JNICALL
Java_com_criticalblue_androidhidesecrets_MainActivity_stringFromJNI(
JNIEnv *env,
jobject /* this */) {
// To add the API_KEY to the mobile app when is compiled you need to:
// * copy `api_key.h.example` to `api_key.h`
// * edit the file and replace this text `place-the-api-key-here` with your desired API_KEY
std::string JNI_API_KEY = ANDROID_HIDE_SECRETS_API_KEY_H;
return env->NewStringUTF(JNI_API_KEY.c_str());
}
请记住，上述技术仅在通过二进制静态分析使提取密码变得非常困难时有用。
提取移动应用程序使用的秘密的最简单方法是让攻击者使用以下工具将处于中间攻击中的人安装到他控制的设备中的移动应用程序上
面向渗透测试人员和软件开发人员的交互式TLS拦截HTTP代理。
使用此工具，攻击者可以将自定义ssl证书添加到设备和移动应用程序，以便他可以拦截和读取所有https流量，从而能够了解移动应用程序和API服务器之间的通信是如何顺序发生的发起自动攻击。
构建发行版二进制文件时，请始终混淆代码，例如Android Studio 具有内置的支持，或者您可以使用商业工具来获得更好的结果。
在固定移动应用程序与API服务器之间的连接时，我们阻止中间人攻击，因为移动应用程序将拒绝未使用API服务器证书的连接。
固定是将主机与其预期的X509证书或公钥关联的过程。一旦知道或看到了主机的证书或公钥，便会将证书或公钥关联或“固定”到主机。如果可以接受多个证书或公钥，则该程序将保留一个密码集（取自Jon Larimer和Kenny Root Google I / O谈话）。在这种情况下，所宣传的身份必须与引脚集中的元素之一匹配。
使用移动应用证明解决方案将使API服务器能够知道正在发送请求的内容，从而仅响应来自真正移动应用的请求，而拒绝来自不安全来源的所有其他请求。
移动应用程序证明服务的作用是在运行时通过在后台运行将与云中运行的服务进行通信的SDK来确保您的移动应用程序未被篡改或未在有根设备中运行证明移动应用程序和设备正在运行的完整性。
在成功证明移动应用程序完整性之后，将发布并使用一个秘密的短期生存JWT令牌进行签名，该秘密只有云中的API服务器和移动应用程序证明服务可以识别。如果移动应用程序证明失败，则会使用API服务器不知道的秘密对JWT令牌进行签名。
现在，应用程序必须随每个API一起发送，并在请求的标头中调用JWT令牌。这将允许API服务器仅在可以验证JWT令牌中的签名和到期时间时才处理请求，而在验证失败时拒绝它们。
一旦移动应用程序不知道移动应用程序证明服务使用的机密，即使在应用程序被篡改，在有根设备上运行或通过连接进行通信时，也无法在运行时对其进行反向工程成为中间攻击中一名男子的目标。
因此，该解决方案可在没有误报的积极检测模型中工作，从而不会阻止合法用户，同时又将坏人拒之门外。
移动应用程序认证服务已经作为Approov上的SAAS解决方案存在（我在这里工作），该服务提供了多个平台的SDK，包括iOS，Android，React Native等。集成还需要在API服务器代码中进行少量检查，以验证由云服务发出的JWT令牌。对于API服务器来说，必须进行此检查才能决定要处理的请求和拒绝的请求。
最终，您所拥有的数据到底有多少价值，数据泄露对业务的影响是什么，以及您需要遵循哪些法规来处理这些数据，例如GDPR欧洲。
因此，基于此评估，您需要确定要为服务于Web和移动应用程序的API设置多少防御层。