React Native 安全问题与数据交换 api
React Native security concerns with data exchange to api
我们想要编写一个 React 本机应用程序：
-gets data over bluetooth from devices
-the app should send the data to our api
-it's important that the data is not tempered with or changed in any way
-the app is the only one that can send data to our api
我已经阅读了很多关于：
iOS - 钥匙串服务和
Android - 密钥库
在 React Native 文档上：https://reactnative.dev/docs/security
和 SafeNet(Android) 或 DevieCheck(IOS)（在我阅读的 React Native 文档或文章中从未提及）
我们应该为我们的用例使用哪些安全层来使 api 最安全，我如何在 React Native 中实现它们？
我们想使用来自 api 的数据来验证传递给比较和评估它们的智能合约的相同数据的正确性。
你的问题
We want to use the data from the api to verify the correctness of the same data passed to a smart contract that compares and evaluates them.
祝贺您花时间了解位于区块链前面的 API 需要防止滥用，以防止区块链摄取不需要的数据。
捍卫 API 不是一件容易的事，但如果您仔细阅读我要说的所有内容，我希望到最后您会对 API 和移动安全有一个新的看法，这将使您能够设计和构建稳健且安全的解决方案。
谁在请求中与什么在提出请求
-the app is the only one that can send data to our api
这是一个很难解决的问题，但并非不可能。要理解为什么你需要首先知道请求中的 who 和 what 之间的区别，否则你添加的任何安全性可能不会按预期保护您的 API。
访问 API 服务器的 WHO 和 WHAT 的区别
我写了一系列关于API和移动安全的文章，在文章Why Does Your Mobile App Need An Api Key?中你可以详细阅读who和之间的区别什么 正在访问您的 API 服务器，但我将在这里提取主要内容：
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 服务器将能够验证和授权对数据的访问，并考虑 what 作为代表用户提出请求的软件。
数据完整性
-gets data over bluetooth from devices
-the app should send the data to our api
-it's important that the data is not tempered with or changed in any way
这个也很难解决。在收集数据并将其发送到 API 的过程中，数据可能会以多种方式被篡改。
使用检测框架处理数据
-gets data over bluetooth from devices
当从设备收集数据时，可以使用检测框架在将数据发送到 API 之前处理数据。一个流行的检测框架是 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.
因此，攻击者将注入脚本以在运行时侦听收集数据的方法或将数据发送到 API 的方法，然后篡改正在发送的数据。
- the app should send the data to our api
使用 MitM 攻击操纵数据
另一种选择是攻击者也使用 Frida 执行 MitM 攻击以允许像 mitmproxy to intercept and modify the request. You can learn how to perform a MitM attack with Frida by reading my article How to Bypass Certificate Pinning with Frida on an Android App:
这样的工具
Today I will show how to use the Frida instrumentation framework to hook into the mobile app at runtime and instrument the code in order to perform a successful MitM attack even when the mobile app has implemented certificate pinning.
Bypassing certificate pinning is not too hard, just a little laborious, and allows an attacker to understand in detail how a mobile app communicates with its API, and then use that same knowledge to automate attacks or build other services around it.
在运行时注入 Frida 脚本允许几乎无限的可能性来篡改您的数据完整性或移动应用程序在运行时所做的任何事情。
可能的解决方案
安全存储
I already read a lot about:
iOS - Keychain Services and
Android - Keystore
on the React Native docs: https://reactnative.dev/docs/security
建议使用此机制，但您需要注意，移动应用程序有时需要访问和使用存储在安全存储中的任何内容，此时攻击者可以使用工具在运行时挂接到移动应用程序代码的框架。例如，当检索安全存储的秘密时，攻击者可以提取它以在移动应用程序外部使用，以自动执行 API 请求，就好像它们来自移动应用程序一样。
因此，使用它可以让不太熟练的攻击者更难篡改您的移动应用程序，但请始终记住，更熟练的攻击者可能会找到绕过它的方法。
保护移动应用程序中的数据完整性
-it's important that the data is not tempered with or changed in any way
为了保护数据在到达 API 服务器之前不被篡改，您有必要采用一些解决方案，例如 RASP:
Runtime application self-protection (RASP) is a security technology that uses runtime instrumentation to detect and block computer attacks by taking advantage of information from inside the running software.
RASP technology is said to improve the security of software by monitoring its inputs, and blocking those that could allow attacks, while protecting the runtime environment from unwanted changes and tampering.
仅使用 RASP 的问题是 API 服务器对移动应用程序的持续攻击不可见，因此无法拒绝来自受到攻击的移动应用程序的请求。此外，RASP 可以被熟练的攻击者使用检测框架绕过，并且 API 服务器不会意识到这种情况的发生，因此将继续为请求提供服务，因为它没有机制知道 提出的请求确实是您移动应用程序的正版 un-tampered。
捍卫 API 服务器
我建议您阅读 this answer 我提出的问题 How to secure an API REST for mobile app?，尤其是部分 加固和屏蔽移动应用程序、保护API服务器和可能更好的解决方案。
提出的解决方案之一是使用在移动设备外部运行的移动应用证明解决方案，例如在云上，因此不会做出关于移动应用和设备状态的客户端决定运行 上，而是在云服务中完成并作为签名的 JWT 令牌传输到 API 服务器，然后 API 服务器可以用来验证 what 正在请求确实是正版和 un-tampered 版本的官方移动应用程序。
Android Safetynet 和 iOS Devicecheck
And SafeNet(Android) or DevieCheck(IOS) (never mentioned on react native docs or articles I read)
正在使用Android SafetyNet 和 iOS DeviceCheck 运行时保护无疑是一个很好的起点，但您需要了解它们的范围、限制和复杂性。它们可以与强大的移动应用证明解决方案相辅相成，为您提供更高级别的安全性和信心，您的 API 服务器将能够知道请求何时不是来自 what 它需要一个正版 un-tampered 版本的移动应用程序。
安全层
What security layers should we use for our use case to make the api most secure and how can I implement them in react native?
我不会在这里讨论如何在 React 中实现它，因为这是一个很大的话题，确切的代码将取决于您当前的实现，但我将在这里总结要点。
安全始终是根据法律、标准和业务要求在您负担得起的范围内添加尽可能多的层。总而言之，您应该考虑以下主题：
- 不要在您的移动应用程序代码中硬编码秘密，但如果您真的想这样做，至少使用本机 C 代码。
- 混淆您的移动应用程序代码，因为这将使对移动应用程序代码进行逆向工程以使用检测框架变得更加困难。
- 在您的移动应用程序代码中使用运行时保护，并优先考虑那些不在客户端做出决定并允许 API 服务器验证请求确实来自 它期望什么，一个真正的 un-tampered 版本的移动应用程序，就像我之前提到的移动应用程序证明中描述的那样。
- 使用证书固定到 public 密钥来防止 MitM 攻击，但要知道它可以被绕过。我建议您阅读 this answer 中的
Preventing MitM Attacks 部分我给了另一个问题，您将在其中学习如何实现静态证书固定。如果可以，请尝试使用动态证书固定来允许远程更新您的移动应用程序使用的密码。
- 在您的 API 服务器中，您可以使用速率限制，但不要在 headers 中返回有关可用速率限制的信息，因为这就像将您前门的钥匙放在下面垫子。
- 您可以使用人工智能解决方案，但请注意它们在负面识别模型中工作，并且容易出现误报和误报。如果使用让 API 服务器知道何时受到攻击的移动应用程序运行时保护，则可以推迟使用 AI 解决方案，直到 API 服务器需要使用其他类型的客户端，如 Web 应用程序。
这不是您可以考虑使用以保护您的移动应用程序和 API 服务器的唯一主题列表，但我认为这些主题对您来说更重要。
您想加倍努力吗？
在任何对安全问题的回答中，我总是喜欢引用 OWASP 基金会的优秀作品。
对于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.
对于移动应用程序
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.
我们想要编写一个 React 本机应用程序：
-gets data over bluetooth from devices
-the app should send the data to our api
-it's important that the data is not tempered with or changed in any way
-the app is the only one that can send data to our api
我已经阅读了很多关于：
iOS - 钥匙串服务和
Android - 密钥库
在 React Native 文档上：https://reactnative.dev/docs/security
和 SafeNet(Android) 或 DevieCheck(IOS)（在我阅读的 React Native 文档或文章中从未提及）
我们应该为我们的用例使用哪些安全层来使 api 最安全，我如何在 React Native 中实现它们？
我们想使用来自 api 的数据来验证传递给比较和评估它们的智能合约的相同数据的正确性。
你的问题
We want to use the data from the api to verify the correctness of the same data passed to a smart contract that compares and evaluates them.
祝贺您花时间了解位于区块链前面的 API 需要防止滥用，以防止区块链摄取不需要的数据。
捍卫 API 不是一件容易的事，但如果您仔细阅读我要说的所有内容，我希望到最后您会对 API 和移动安全有一个新的看法，这将使您能够设计和构建稳健且安全的解决方案。
谁在请求中与什么在提出请求
-the app is the only one that can send data to our api
这是一个很难解决的问题，但并非不可能。要理解为什么你需要首先知道请求中的 who 和 what 之间的区别，否则你添加的任何安全性可能不会按预期保护您的 API。
访问 API 服务器的 WHO 和 WHAT 的区别
我写了一系列关于API和移动安全的文章，在文章Why Does Your Mobile App Need An Api Key?中你可以详细阅读who和之间的区别什么 正在访问您的 API 服务器，但我将在这里提取主要内容：
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 服务器将能够验证和授权对数据的访问，并考虑 what 作为代表用户提出请求的软件。
数据完整性
-gets data over bluetooth from devices -the app should send the data to our api -it's important that the data is not tempered with or changed in any way
这个也很难解决。在收集数据并将其发送到 API 的过程中，数据可能会以多种方式被篡改。
使用检测框架处理数据
-gets data over bluetooth from devices
当从设备收集数据时，可以使用检测框架在将数据发送到 API 之前处理数据。一个流行的检测框架是 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.
因此，攻击者将注入脚本以在运行时侦听收集数据的方法或将数据发送到 API 的方法，然后篡改正在发送的数据。
- the app should send the data to our api
使用 MitM 攻击操纵数据
另一种选择是攻击者也使用 Frida 执行 MitM 攻击以允许像 mitmproxy to intercept and modify the request. You can learn how to perform a MitM attack with Frida by reading my article How to Bypass Certificate Pinning with Frida on an Android App:
这样的工具Today I will show how to use the Frida instrumentation framework to hook into the mobile app at runtime and instrument the code in order to perform a successful MitM attack even when the mobile app has implemented certificate pinning.
Bypassing certificate pinning is not too hard, just a little laborious, and allows an attacker to understand in detail how a mobile app communicates with its API, and then use that same knowledge to automate attacks or build other services around it.
在运行时注入 Frida 脚本允许几乎无限的可能性来篡改您的数据完整性或移动应用程序在运行时所做的任何事情。
可能的解决方案
安全存储
I already read a lot about:
iOS - Keychain Services and Android - Keystore on the React Native docs: https://reactnative.dev/docs/security
建议使用此机制，但您需要注意，移动应用程序有时需要访问和使用存储在安全存储中的任何内容，此时攻击者可以使用工具在运行时挂接到移动应用程序代码的框架。例如，当检索安全存储的秘密时，攻击者可以提取它以在移动应用程序外部使用，以自动执行 API 请求，就好像它们来自移动应用程序一样。
因此，使用它可以让不太熟练的攻击者更难篡改您的移动应用程序，但请始终记住，更熟练的攻击者可能会找到绕过它的方法。
保护移动应用程序中的数据完整性
-it's important that the data is not tempered with or changed in any way
为了保护数据在到达 API 服务器之前不被篡改，您有必要采用一些解决方案，例如 RASP:
Runtime application self-protection (RASP) is a security technology that uses runtime instrumentation to detect and block computer attacks by taking advantage of information from inside the running software.
RASP technology is said to improve the security of software by monitoring its inputs, and blocking those that could allow attacks, while protecting the runtime environment from unwanted changes and tampering.
仅使用 RASP 的问题是 API 服务器对移动应用程序的持续攻击不可见，因此无法拒绝来自受到攻击的移动应用程序的请求。此外，RASP 可以被熟练的攻击者使用检测框架绕过，并且 API 服务器不会意识到这种情况的发生，因此将继续为请求提供服务，因为它没有机制知道 提出的请求确实是您移动应用程序的正版 un-tampered。
捍卫 API 服务器
我建议您阅读 this answer 我提出的问题 How to secure an API REST for mobile app?，尤其是部分 加固和屏蔽移动应用程序、保护API服务器和可能更好的解决方案。
提出的解决方案之一是使用在移动设备外部运行的移动应用证明解决方案，例如在云上，因此不会做出关于移动应用和设备状态的客户端决定运行 上，而是在云服务中完成并作为签名的 JWT 令牌传输到 API 服务器，然后 API 服务器可以用来验证 what 正在请求确实是正版和 un-tampered 版本的官方移动应用程序。
Android Safetynet 和 iOS Devicecheck
And SafeNet(Android) or DevieCheck(IOS) (never mentioned on react native docs or articles I read)
正在使用Android SafetyNet 和 iOS DeviceCheck 运行时保护无疑是一个很好的起点，但您需要了解它们的范围、限制和复杂性。它们可以与强大的移动应用证明解决方案相辅相成，为您提供更高级别的安全性和信心，您的 API 服务器将能够知道请求何时不是来自 what 它需要一个正版 un-tampered 版本的移动应用程序。
安全层
What security layers should we use for our use case to make the api most secure and how can I implement them in react native?
我不会在这里讨论如何在 React 中实现它，因为这是一个很大的话题，确切的代码将取决于您当前的实现，但我将在这里总结要点。
安全始终是根据法律、标准和业务要求在您负担得起的范围内添加尽可能多的层。总而言之，您应该考虑以下主题：
- 不要在您的移动应用程序代码中硬编码秘密，但如果您真的想这样做，至少使用本机 C 代码。
- 混淆您的移动应用程序代码，因为这将使对移动应用程序代码进行逆向工程以使用检测框架变得更加困难。
- 在您的移动应用程序代码中使用运行时保护，并优先考虑那些不在客户端做出决定并允许 API 服务器验证请求确实来自 它期望什么，一个真正的 un-tampered 版本的移动应用程序，就像我之前提到的移动应用程序证明中描述的那样。
- 使用证书固定到 public 密钥来防止 MitM 攻击，但要知道它可以被绕过。我建议您阅读 this answer 中的
Preventing MitM Attacks部分我给了另一个问题，您将在其中学习如何实现静态证书固定。如果可以，请尝试使用动态证书固定来允许远程更新您的移动应用程序使用的密码。 - 在您的 API 服务器中，您可以使用速率限制，但不要在 headers 中返回有关可用速率限制的信息，因为这就像将您前门的钥匙放在下面垫子。
- 您可以使用人工智能解决方案，但请注意它们在负面识别模型中工作，并且容易出现误报和误报。如果使用让 API 服务器知道何时受到攻击的移动应用程序运行时保护，则可以推迟使用 AI 解决方案，直到 API 服务器需要使用其他类型的客户端，如 Web 应用程序。
这不是您可以考虑使用以保护您的移动应用程序和 API 服务器的唯一主题列表，但我认为这些主题对您来说更重要。
您想加倍努力吗？
在任何对安全问题的回答中，我总是喜欢引用 OWASP 基金会的优秀作品。
对于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.
对于移动应用程序
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.