如何识别调用 API 端点的应用程序或网站？
How to identify the app or website which calls an API endpoint?
我们正在 PHP 制作 API。我们希望 API 端点仅由某些指定的应用程序和网站调用（而不是通过 Postman 或任何类似软件）。我们试图通过调用发送一些 身份验证密钥 但有 工具 可用于甚至从 signed APK（在 whatsApp 的 apk 上测试），因此密钥可能会泄露。
因此，我们试图弄清楚是否有办法向我们的 API endpoint 识别调用方应用程序或网站，然后我们将在 PHP 中验证身份并提供 response 相应地。
有什么办法可以实现吗？如果没有，还有其他解决方法吗？
提前致谢。
挑战
We want the API endpoints to be called only by some specified apps and websites(Not via Postman or any similar software).
好吧，您遇到了一个巨大的挑战，而且是一个非常需要解决的挑战。
在我深入研究细节之前，我可以说，捍卫仅服务于移动应用程序的 API 比捍卫同时服务于移动应用程序和 Web 应用程序的 API 更容易。
作为剧透警报，我可以说对于 Web 应用程序，API 服务器最好的机会是使用人工智能来防御没有真正的请求，而对于移动应用程序，解决方案更有效和简单，当 API 服务器能够证明发出请求的移动应用程序是真实且未修改的应用程序时。
逆向工程
网络构建的本质使得在客户端反省代码变得非常容易，也就是您只需点击 F12 或右键单击即可查看页面的页面源代码，因此很容易对任何自我防御代码进行逆向工程或提取任何用于识别应用程序的秘密到 API 服务器。
对于移动应用程序来说，这不是那么容易，但也不是那么难，因为我们有优秀的开源工具来帮助我们，比如 Mobile Security Framework(MoBSF) 在一个网络界面下聚合了多个工具，将使逆向工程和提取签名 APK 的源代码和秘密变得轻而易举，就像您使用 What's App 实现的那样：
We have tried to send some authentication key with the call but there are tools which can be used to get the entire code even from a signed APK(tested on the apk of whatsApp), so the key could get leaked.
移动应用程序中的秘密很难通过静态二进制分析提取，正如我在 this article:
中展示的那样
During this article we will use the Android Hide Secrets research repository that is a dummy mobile app with API keys hidden using several different techniques.
以上文章展示了如何使用原生JNI/NDK interface to hide the secrets in C code, thus making it very hard to extract, but then you can't do it via static analysis, you do it dynamically with a MiTM Proxy attack, as I describe in this other文章：
In order to help to demonstrate how to steal an API key, I have built and released in Github the Currency Converter Demo app for Android, which uses the same JNI/NDK technique we used in the earlier Android Hide Secrets app to hide the API key.
谁与什么正在访问 API 服务器之间的区别
So, we are trying to figure out if there is a way to identify the caller app or website to our API endpoint then we would verify the identity in PHP and give the response accordingly.
因此，使用所有这些工具并轻松访问对应用程序进行逆向工程，API 服务器区分 谁 是来自 What 正在执行请求，了解 Who 和 What 之间的区别对于开发人员来说至关重要为其 API 服务器和应用程序定义安全策略。一旦这是一个经常被开发人员误解的概念，我建议您阅读 this section 我写的一篇文章，其中更详细地解释了它，并引用了我的文章：
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.
因此，考虑 Who 作为用户，您的 API 服务器将能够验证和授权对数据的访问，并考虑 什么 作为代表用户发出该请求的软件，例如 Postman 或 cURL。
消除了这种差异后，您现在可以更好地决定如何解决 API 服务器和应用程序的安全问题。
确定请求中的人员和内容
Is there any way to achieve this? If not, then is there any other work around?
要识别请求中的 Who，您可以求助于传统的身份验证和授权机制或使用 OAuth2 or OpenID Connect。
要识别请求中的 What 是挑战所在，因为您的 API 服务器需要区分 Who 来自 What，一些高级方法将使用 User Behavior Analytics(UBA) 来实现。
UBA 解决方案的一个示例是 [Google reCAPTCHA V3]，它不需要用户交互并根据请求到达的可能性向 API 服务器给出分数是否来自人类。
虽然这是在尽最大努力区分人与机器的基础上工作的，但它无法提供很高的信心，确保您不会 运行 出现误报，但 UBA 的解决方案是您最好的机会对于 API 服务网络应用程序的服务器
对于服务于移动应用程序的 API 服务器，我们可以利用移动应用程序证明概念来有效地了解 什么 正在执行请求，我建议你去阅读 我给出的问题 How to secure an API REST for mobile app?，这将建议你找到一个最终的解决方案像这样：
阅读我链接的答案，了解移动应用证明将如何允许从移动应用中删除秘密，并让您的 API 服务器高度自信地知道 什么 正在执行请求。
您想加倍努力吗？
在任何对安全问题的回应中，我总是喜欢引用 OWASP 基金会的出色工作。
对于网络应用程序
The OWASP Top 10 is a powerful awareness document for web application security. It represents a broad consensus about the most critical security risks to web applications. Project members include a variety of security experts from around the world who have shared their expertise to produce this list.
The Web Security Testing Guide:
The OWASP Web Security Testing Guide includes a "best practice" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues.
对于移动应用程序
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
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.
链接参考
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.
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.
Mobile Security Framework is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing framework capable of performing static analysis, dynamic analysis, malware analysis and web API testing.
OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 supersedes the work done on the original OAuth protocol created in 2006. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification and its extensions are being developed within the IETF OAuth Working Group.
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
OpenID Connect performs many of the same tasks as OpenID 2.0, but does so in a way that is API-friendly, and usable by native and mobile applications. OpenID Connect defines optional mechanisms for robust signing and encryption. Whereas integration of OAuth 1.0a and OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself.
Using Android Studio 2.2 and higher, you can use the NDK to compile C and C++ code into a native library and package it into your APK using Gradle, the IDE's integrated build system. Your Java code can then call functions in your native library through the Java Native Interface (JNI) framework.
我们正在 PHP 制作 API。我们希望 API 端点仅由某些指定的应用程序和网站调用（而不是通过 Postman 或任何类似软件）。我们试图通过调用发送一些 身份验证密钥 但有 工具 可用于甚至从 signed APK（在 whatsApp 的 apk 上测试），因此密钥可能会泄露。
因此，我们试图弄清楚是否有办法向我们的 API endpoint 识别调用方应用程序或网站，然后我们将在 PHP 中验证身份并提供 response 相应地。
有什么办法可以实现吗？如果没有，还有其他解决方法吗？
提前致谢。
挑战
We want the API endpoints to be called only by some specified apps and websites(Not via Postman or any similar software).
好吧，您遇到了一个巨大的挑战，而且是一个非常需要解决的挑战。
在我深入研究细节之前，我可以说，捍卫仅服务于移动应用程序的 API 比捍卫同时服务于移动应用程序和 Web 应用程序的 API 更容易。
作为剧透警报，我可以说对于 Web 应用程序，API 服务器最好的机会是使用人工智能来防御没有真正的请求，而对于移动应用程序，解决方案更有效和简单，当 API 服务器能够证明发出请求的移动应用程序是真实且未修改的应用程序时。
逆向工程
网络构建的本质使得在客户端反省代码变得非常容易，也就是您只需点击 F12 或右键单击即可查看页面的页面源代码，因此很容易对任何自我防御代码进行逆向工程或提取任何用于识别应用程序的秘密到 API 服务器。
对于移动应用程序来说，这不是那么容易，但也不是那么难，因为我们有优秀的开源工具来帮助我们，比如 Mobile Security Framework(MoBSF) 在一个网络界面下聚合了多个工具，将使逆向工程和提取签名 APK 的源代码和秘密变得轻而易举，就像您使用 What's App 实现的那样：
We have tried to send some authentication key with the call but there are tools which can be used to get the entire code even from a signed APK(tested on the apk of whatsApp), so the key could get leaked.
移动应用程序中的秘密很难通过静态二进制分析提取，正如我在 this article:
中展示的那样During this article we will use the Android Hide Secrets research repository that is a dummy mobile app with API keys hidden using several different techniques.
以上文章展示了如何使用原生JNI/NDK interface to hide the secrets in C code, thus making it very hard to extract, but then you can't do it via static analysis, you do it dynamically with a MiTM Proxy attack, as I describe in this other文章：
In order to help to demonstrate how to steal an API key, I have built and released in Github the Currency Converter Demo app for Android, which uses the same JNI/NDK technique we used in the earlier Android Hide Secrets app to hide the API key.
谁与什么正在访问 API 服务器之间的区别
So, we are trying to figure out if there is a way to identify the caller app or website to our API endpoint then we would verify the identity in PHP and give the response accordingly.
因此，使用所有这些工具并轻松访问对应用程序进行逆向工程，API 服务器区分 谁 是来自 What 正在执行请求，了解 Who 和 What 之间的区别对于开发人员来说至关重要为其 API 服务器和应用程序定义安全策略。一旦这是一个经常被开发人员误解的概念，我建议您阅读 this section 我写的一篇文章，其中更详细地解释了它，并引用了我的文章：
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.
因此，考虑 Who 作为用户，您的 API 服务器将能够验证和授权对数据的访问，并考虑 什么 作为代表用户发出该请求的软件，例如 Postman 或 cURL。
消除了这种差异后，您现在可以更好地决定如何解决 API 服务器和应用程序的安全问题。
确定请求中的人员和内容
Is there any way to achieve this? If not, then is there any other work around?
要识别请求中的 Who，您可以求助于传统的身份验证和授权机制或使用 OAuth2 or OpenID Connect。
要识别请求中的 What 是挑战所在，因为您的 API 服务器需要区分 Who 来自 What，一些高级方法将使用 User Behavior Analytics(UBA) 来实现。
UBA 解决方案的一个示例是 [Google reCAPTCHA V3]，它不需要用户交互并根据请求到达的可能性向 API 服务器给出分数是否来自人类。
虽然这是在尽最大努力区分人与机器的基础上工作的，但它无法提供很高的信心，确保您不会 运行 出现误报，但 UBA 的解决方案是您最好的机会对于 API 服务网络应用程序的服务器
对于服务于移动应用程序的 API 服务器，我们可以利用移动应用程序证明概念来有效地了解 什么 正在执行请求，我建议你去阅读
阅读我链接的答案，了解移动应用证明将如何允许从移动应用中删除秘密，并让您的 API 服务器高度自信地知道 什么 正在执行请求。
您想加倍努力吗？
在任何对安全问题的回应中，我总是喜欢引用 OWASP 基金会的出色工作。
对于网络应用程序
The OWASP Top 10 is a powerful awareness document for web application security. It represents a broad consensus about the most critical security risks to web applications. Project members include a variety of security experts from around the world who have shared their expertise to produce this list.
The Web Security Testing Guide:
The OWASP Web Security Testing Guide includes a "best practice" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues.
对于移动应用程序
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
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.
链接参考
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.
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.
Mobile Security Framework is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing framework capable of performing static analysis, dynamic analysis, malware analysis and web API testing.
OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 supersedes the work done on the original OAuth protocol created in 2006. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification and its extensions are being developed within the IETF OAuth Working Group.
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. OpenID Connect performs many of the same tasks as OpenID 2.0, but does so in a way that is API-friendly, and usable by native and mobile applications. OpenID Connect defines optional mechanisms for robust signing and encryption. Whereas integration of OAuth 1.0a and OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself.
Using Android Studio 2.2 and higher, you can use the NDK to compile C and C++ code into a native library and package it into your APK using Gradle, the IDE's integrated build system. Your Java code can then call functions in your native library through the Java Native Interface (JNI) framework.