如何保护移动应用程序的 API REST？ （如果嗅探请求给你 "key"）
How to secure an API REST for mobile app? (if sniffing requests gives you the "key")
这可能是一个新手问题，但我会尝试发起一场有趣的辩论。
我知道有一些用于 API 基本身份验证、API 密钥、OAuth 2.0 的身份验证方法...所有这些方法都在请求。
尽管您使用 SSL，但破解移动应用程序“通常很容易”（我现在正在考虑 Android：反编译应用程序，更改清单以允许自定义 SSL，再次编译并嗅探SSL 代理所有请求）。
在这些请求中，我发现了很多可以在来自控制台的其他调用中使用的授权密钥，可以毫无问题地模拟应用程序。
所以，现在我已经在移动应用程序中破解了一些 API，我的问题是：有什么方法可以在移动应用程序中保护 API 吗？
我想知道一个安全化层是否会限制每个“密钥”的请求数量。
我错了吗？我错过了什么吗？这是一个愚蠢的问题吗？
Am I wrong?
Is this a stupid question?
不，你没有看错，这根本不是一个愚蠢的问题，因为攻击移动应用程序的 API 服务器确实很容易，你会惊讶地知道有多少高级开发人员不知道这有多容易，我注意到更多的时候不是，这是由于他们对 what vs who 的误解正在访问 API 服务器。
what 和 who 之间的区别是访问 API 服务器。
这在我写的 this article 中有更详细的讨论，我们可以在其中阅读：
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
因此，如果引用的文字不足以让您明白，请继续阅读整篇文章。
冒充手机APP
In those request I've found a lot of auth keys that I can use in other calls from a console, simulating the app with no problems.
如果 auth keys 你的意思是那些通过用户登录提供用户名和密码的人，那么他们只是在请求中识别 who。
对于其他密钥，如 api-keys、access-tokens 或用于命名它们的任何其他约定，它们的目的是向 API 服务器提供一种机制，仅授权来自正版移动应用程序的请求，他们确实试图让 API 服务器识别 什么 正在执行请求，你是否已经发现使用代理：
Although you use SSL, it's "usually easy" to hack mobile apps (I'm thinking in Android right now: decompiling the app, changing manifest to allow custom SSL, compiling again and sniffing through a SSL proxy all the requests).
所以，归根结底，攻击者所需要的只是使用代理来了解 API 服务器的工作方式，以及模拟 API 调用所需的条件是通过移动应用程序本身完成的。
加固和屏蔽移动应用程序
So, now I've hacked some API's in mobile apps, my question is: is there any way to secure an API in a mobile app?
您可以使用移动强化和屏蔽解决方案，这将尝试阻止移动应用程序在 compromised/rooted 设备上运行，当某些检测框架正在运行时，modified/tampered 应用程序 and/or在运行时使用，但它们都有在移动应用程序中执行所有决策的缺点，因此容易被 alreay dito 检测框架操纵或完全绕过，其中一个很好的例子是 Frida :
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
虽然使用应用内解决方案比不使用任何东西要好，但它仍然不是理想的解决方案，因为决定做什么的控制权在客户端，而不是在服务器端，因此攻击者可以求助于使用 Frida 在运行时自省代码并学习如何模拟移动应用程序。
保护 API 服务器
基本API安全防御
现在您了解了 who 与 what 之间的区别正在访问您的 API 服务器并且您知道攻击者可以学习如何冒充您的正版移动应用程序您可能想阅读 my article 有关保护 API:
的基本技术
In this article we will explore the most common techniques used to protect an API, including how important it is to use HTTPS to protect the communication channel between mobile app and API, how API keys are used to identify the mobile app on each API request, how user agents, captchas and IP addresses are used for bot mitigation, and finally how user authentication is important for the mobile security and api security. We will discuss each of these techniques and discuss how they impact the business risk profile, i.e. how easy they are get around.
这只是大多数 API 可能已经使用的非常基本的技术，但可以通过一些更高级的技术来加强它们。
更高级API安全防御
您可以开始阅读有关 Mobile API Security Techniques to understand how API keys, HMAC, OAUTH and certificate pinning 的这一系列文章，这些文章可用于增强安全性，同时了解它们如何 abused/defeated。
之后，根据您的预算和资源，您可以采用一系列不同的方法和技术来保护您的 API 服务器，我将开始列举一些最常用的方法和技术。
您可以从 reCaptcha V3, followed by Web Application Firewall(WAF) and finally if you can afford it a User Behavior Analytics(UBA) 解决方案开始。
Google reCAPTCHA V3:
reCAPTCHA is a free service that protects your website from spam and abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive challenges to keep automated software from engaging in abusive activities on your site. It does this while letting your valid users pass through with ease.
...helps you detect abusive traffic on your website without any user friction. It returns a score based on the interactions with your website and provides you more flexibility to take appropriate actions.
WAF - Web Application Firewall:
A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. A WAF is differentiated from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws, such as SQL injection, cross-site scripting (XSS), file inclusion, and security misconfigurations.
UBA - User Behavior Analytics:
User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.
所有这些解决方案都基于负面识别模型，换句话说，它们通过识别什么是坏的而不是什么是好的来尽力区分好坏，因此它们容易出现误报，尽管他们中的一些人使用了先进的技术，比如机器学习和人工智能。
因此，您可能会经常发现自己不得不放松阻止对 API 服务器的访问，以免影响好的用户。这也意味着此解决方案需要持续监控，以验证误报不会阻止您的合法用户，同时它们会适当地阻止未经授权的用户。
关于 API 为移动应用程序提供服务，可以通过实施移动应用程序证明解决方案来使用积极的识别模型，该解决方案在任何请求之前证明您的移动应用程序和设备的完整性 运行发送到 API 服务器。
一个可能更好的解决方案
移动应用程序和 API 服务器的当前实现可能如下所示：
这种方法使得 API 密钥容易被攻击者通过代理拦截（红线）提取，就像您已经注意到的使用代理拦截它们一样。
更好的方法是这样的：
等等，但我在移动应用程序中没有看到任何 API 键：
Am I missing something ?
是的，移动应用证明解决方案。
要处于不需要通过移动应用传送任何秘密的位置，则需要求助于移动应用证明概念，并且从 this article section 我将引用相关部分解释它的作用：
The role of a Mobile App Attestation service is to authenticate what is sending the requests, thus only responding to requests coming from genuine mobile app instances and rejecting all other requests from unauthorized sources.
In order to know what is sending the requests to the API server, a Mobile App Attestation service, at run-time, will identify with high confidence that your mobile app is present, has not been tampered/repackaged, is not running in a rooted device, has not been hooked into by an instrumentation framework(Frida, xPosed, Cydia, etc.), and is not the object of a Man in the Middle Attack (MitM). This is achieved by running an SDK in the background that will communicate with a service running in the cloud to attest the integrity of the mobile app and device it is running on.
On a successful attestation of the mobile app integrity, a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud know. In the case that attestation fails the JWT token is signed with an incorrect secret. Since the secret used by the Mobile App Attestation service is not known by the mobile app, it is not possible to reverse engineer it at run-time even when the app has been tampered with, is running in a rooted device or communicating over a connection that is the target of a MitM attack.
The mobile app must send the JWT token in the header of every API request. This allows the API server to only serve requests when it can verify that the JWT token was signed with the shared secret and that it has not expired. All other requests will be refused. In other words a valid JWT token tells the API server that what is making the request is the genuine mobile app uploaded to the Google or Apple store, while an invalid or missing JWT token means that what is making the request is not authorized to do so, because it may be a bot, a repackaged app or an attacker making a MitM attack.
A great benefit of using a Mobile App Attestation service is its proactive and positive authentication model, which does not create false positives, and thus does not block legitimate users while it keeps the bad guys at bay.
移动应用证明使您的移动应用不再在其代码中嵌入秘密，而现在它只需要将其从移动应用证明服务接收到的 JWT 令牌传递给反向代理或后端。现在反向代理或后端可以验证 JWT 令牌，并且在成功验证后，他们可以非常自信地接受请求，这些请求来自他们期望的 what，一个真实的真实实例移动应用程序，具有不公开 API 密钥以访问您的API 服务器或任何第三方服务的额外好处。
加倍努力
我不能不向您推荐 OWASP 基金会所做的出色工作。
对于移动应用程序
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
对于APIS
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
这可能是一个新手问题，但我会尝试发起一场有趣的辩论。
我知道有一些用于 API 基本身份验证、API 密钥、OAuth 2.0 的身份验证方法...所有这些方法都在请求。
尽管您使用 SSL，但破解移动应用程序“通常很容易”（我现在正在考虑 Android：反编译应用程序，更改清单以允许自定义 SSL，再次编译并嗅探SSL 代理所有请求）。
在这些请求中，我发现了很多可以在来自控制台的其他调用中使用的授权密钥，可以毫无问题地模拟应用程序。
所以，现在我已经在移动应用程序中破解了一些 API，我的问题是：有什么方法可以在移动应用程序中保护 API 吗？
我想知道一个安全化层是否会限制每个“密钥”的请求数量。
我错了吗？我错过了什么吗？这是一个愚蠢的问题吗？
Am I wrong? Is this a stupid question?
不，你没有看错，这根本不是一个愚蠢的问题，因为攻击移动应用程序的 API 服务器确实很容易，你会惊讶地知道有多少高级开发人员不知道这有多容易，我注意到更多的时候不是，这是由于他们对 what vs who 的误解正在访问 API 服务器。
what 和 who 之间的区别是访问 API 服务器。
这在我写的 this article 中有更详细的讨论，我们可以在其中阅读：
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
因此，如果引用的文字不足以让您明白，请继续阅读整篇文章。
冒充手机APP
In those request I've found a lot of auth keys that I can use in other calls from a console, simulating the app with no problems.
如果 auth keys 你的意思是那些通过用户登录提供用户名和密码的人，那么他们只是在请求中识别 who。
对于其他密钥，如 api-keys、access-tokens 或用于命名它们的任何其他约定，它们的目的是向 API 服务器提供一种机制，仅授权来自正版移动应用程序的请求，他们确实试图让 API 服务器识别 什么 正在执行请求，你是否已经发现使用代理：
Although you use SSL, it's "usually easy" to hack mobile apps (I'm thinking in Android right now: decompiling the app, changing manifest to allow custom SSL, compiling again and sniffing through a SSL proxy all the requests).
所以，归根结底，攻击者所需要的只是使用代理来了解 API 服务器的工作方式，以及模拟 API 调用所需的条件是通过移动应用程序本身完成的。
加固和屏蔽移动应用程序
So, now I've hacked some API's in mobile apps, my question is: is there any way to secure an API in a mobile app?
您可以使用移动强化和屏蔽解决方案，这将尝试阻止移动应用程序在 compromised/rooted 设备上运行，当某些检测框架正在运行时，modified/tampered 应用程序 and/or在运行时使用，但它们都有在移动应用程序中执行所有决策的缺点，因此容易被 alreay dito 检测框架操纵或完全绕过，其中一个很好的例子是 Frida :
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
虽然使用应用内解决方案比不使用任何东西要好，但它仍然不是理想的解决方案，因为决定做什么的控制权在客户端，而不是在服务器端，因此攻击者可以求助于使用 Frida 在运行时自省代码并学习如何模拟移动应用程序。
保护 API 服务器
基本API安全防御
现在您了解了 who 与 what 之间的区别正在访问您的 API 服务器并且您知道攻击者可以学习如何冒充您的正版移动应用程序您可能想阅读 my article 有关保护 API:
的基本技术In this article we will explore the most common techniques used to protect an API, including how important it is to use HTTPS to protect the communication channel between mobile app and API, how API keys are used to identify the mobile app on each API request, how user agents, captchas and IP addresses are used for bot mitigation, and finally how user authentication is important for the mobile security and api security. We will discuss each of these techniques and discuss how they impact the business risk profile, i.e. how easy they are get around.
这只是大多数 API 可能已经使用的非常基本的技术，但可以通过一些更高级的技术来加强它们。
更高级API安全防御
您可以开始阅读有关 Mobile API Security Techniques to understand how API keys, HMAC, OAUTH and certificate pinning 的这一系列文章，这些文章可用于增强安全性，同时了解它们如何 abused/defeated。
之后，根据您的预算和资源，您可以采用一系列不同的方法和技术来保护您的 API 服务器，我将开始列举一些最常用的方法和技术。
您可以从 reCaptcha V3, followed by Web Application Firewall(WAF) and finally if you can afford it a User Behavior Analytics(UBA) 解决方案开始。
Google reCAPTCHA V3:
reCAPTCHA is a free service that protects your website from spam and abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive challenges to keep automated software from engaging in abusive activities on your site. It does this while letting your valid users pass through with ease.
...helps you detect abusive traffic on your website without any user friction. It returns a score based on the interactions with your website and provides you more flexibility to take appropriate actions.
WAF - Web Application Firewall:
A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. A WAF is differentiated from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws, such as SQL injection, cross-site scripting (XSS), file inclusion, and security misconfigurations.
UBA - User Behavior Analytics:
User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.
所有这些解决方案都基于负面识别模型，换句话说，它们通过识别什么是坏的而不是什么是好的来尽力区分好坏，因此它们容易出现误报，尽管他们中的一些人使用了先进的技术，比如机器学习和人工智能。
因此，您可能会经常发现自己不得不放松阻止对 API 服务器的访问，以免影响好的用户。这也意味着此解决方案需要持续监控，以验证误报不会阻止您的合法用户，同时它们会适当地阻止未经授权的用户。
关于 API 为移动应用程序提供服务，可以通过实施移动应用程序证明解决方案来使用积极的识别模型，该解决方案在任何请求之前证明您的移动应用程序和设备的完整性 运行发送到 API 服务器。
一个可能更好的解决方案
移动应用程序和 API 服务器的当前实现可能如下所示：
这种方法使得 API 密钥容易被攻击者通过代理拦截（红线）提取，就像您已经注意到的使用代理拦截它们一样。
更好的方法是这样的：
等等，但我在移动应用程序中没有看到任何 API 键：
Am I missing something ?
是的，移动应用证明解决方案。
要处于不需要通过移动应用传送任何秘密的位置，则需要求助于移动应用证明概念，并且从 this article section 我将引用相关部分解释它的作用：
The role of a Mobile App Attestation service is to authenticate what is sending the requests, thus only responding to requests coming from genuine mobile app instances and rejecting all other requests from unauthorized sources.
In order to know what is sending the requests to the API server, a Mobile App Attestation service, at run-time, will identify with high confidence that your mobile app is present, has not been tampered/repackaged, is not running in a rooted device, has not been hooked into by an instrumentation framework(Frida, xPosed, Cydia, etc.), and is not the object of a Man in the Middle Attack (MitM). This is achieved by running an SDK in the background that will communicate with a service running in the cloud to attest the integrity of the mobile app and device it is running on.
On a successful attestation of the mobile app integrity, a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud know. In the case that attestation fails the JWT token is signed with an incorrect secret. Since the secret used by the Mobile App Attestation service is not known by the mobile app, it is not possible to reverse engineer it at run-time even when the app has been tampered with, is running in a rooted device or communicating over a connection that is the target of a MitM attack.
The mobile app must send the JWT token in the header of every API request. This allows the API server to only serve requests when it can verify that the JWT token was signed with the shared secret and that it has not expired. All other requests will be refused. In other words a valid JWT token tells the API server that what is making the request is the genuine mobile app uploaded to the Google or Apple store, while an invalid or missing JWT token means that what is making the request is not authorized to do so, because it may be a bot, a repackaged app or an attacker making a MitM attack.
A great benefit of using a Mobile App Attestation service is its proactive and positive authentication model, which does not create false positives, and thus does not block legitimate users while it keeps the bad guys at bay.
移动应用证明使您的移动应用不再在其代码中嵌入秘密，而现在它只需要将其从移动应用证明服务接收到的 JWT 令牌传递给反向代理或后端。现在反向代理或后端可以验证 JWT 令牌，并且在成功验证后，他们可以非常自信地接受请求，这些请求来自他们期望的 what，一个真实的真实实例移动应用程序，具有不公开 API 密钥以访问您的API 服务器或任何第三方服务的额外好处。
加倍努力
我不能不向您推荐 OWASP 基金会所做的出色工作。
对于移动应用程序
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
对于APIS
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.