我們想撰寫一個 React Native 應用程式：
-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 - Keychain Services 和
Android - Keystore
on the React Native 檔案：https : //reactnative.dev/docs/security
和 SafeNet(Android) 或 DevieCheck(IOS)（在我閱讀的本機檔案或文章中從未提到過）
我們應該在我們的用例中使用哪些安全層來使 api 最安全，我該如何在 React Native 中實作它們？
我們想使用來自 api 的資料來驗證傳遞給智能合約的相同資料的正確性，該智能合約對它們進行比較和評估。
uj5u.com熱心網友回復：
你的問題
我們想使用來自 api 的資料來驗證傳遞給智能合約的相同資料的正確性，該智能合約對它們進行比較和評估。
我祝賀您花時間了解位于區塊鏈前面的 API 需要受到保護以防止濫用，以防止區塊鏈攝取不需要的資料。
捍衛 API 不是一件容易的事，但是如果您仔細閱讀我要說的所有內容，我希望到最后您會對 API 和移動安全有一個新的看法，這將使您能夠設計和構建一個健壯和安全的解決方案。
提出請求的人與提出請求的人
- 該應用程式是唯一可以向我們的 api 發送資料的應用程式
這是一個很難解決的問題，但也不是不可能解決的問題。要理解為什么你需要首先知道的區別誰是在請求和什么是使它，否則你增加任何安全可能無法保護您的API預期。
WHO和WHAT訪問API服務器的區別
我寫了一系列關于 API 和移動安全的文章，在文章為什么你的移動應用程式需要 Api 密鑰？你可以詳細閱讀之間的區別誰和什么是訪問您的API服務器，但我會在這里提取它的主要花費：
向 API 服務器發出請求的內容是什么。它真的是您的移動應用程式的真實實體，還是機器人、自動化腳本或攻擊者使用 Postman 等工具手動瀏覽您的 API 服務器？
在誰是移動應用，我們可以驗證，授權和以多種方式確定，比如使用OpenID登錄連接或流的oauth2的用戶。
因此，考慮誰是您的 API 服務器將能夠對資料進行身份驗證和授權訪問的用戶，并考慮代表用戶發出該請求的軟體是什么。
資料的完整性
- 通過藍牙從設備獲取資料 - 應用程式應該將資料發送到我們的 api - 重要的是不要以任何方式調整或更改資料
這也很難解決。在收集資料并將其發送到 API 的程序中，可以通過多種方式篡改資料。
使用檢測框架處理資料
- 通過藍牙從設備獲取資料
在從設備收集資料時，可以使用檢測框架在將資料發送到 API 之前對其進行操作。一個流行的檢測框架是Frida：
將您自己的腳本注入黑盒行程。掛鉤任何函式，監視加密 API 或跟蹤私有應用程式代碼，無需源代碼。編輯，點擊保存，立即查看結果。所有這些都無需編譯步驟或程式重新啟動。
因此，攻擊者會注入一個腳本來在運行時監聽收集資料的方法或將資料發送到 API 的方法，然后篡改正在發送的資料。
- 應用程式應該將資料發送到我們的 api
使用中間人攻擊操作資料
另一種選擇是攻擊者也使用 Frida 進行中間人攻擊，以允許像mitmproxy這樣的工具攔截和修改請求。您可以通過閱讀我的文章如何在 Android 應用程式上使用 Frida 繞過證書鎖定來了解如何使用 Frida 執行 MitM 攻擊：
今天，我將展示如何使用 Frida 檢測框架在運行時連接到移動應用程式并檢測代碼，以便即使在移動應用程式實作了證書鎖定的情況下也能成功執行 MitM 攻擊。
繞過證書鎖定并不太難，只是有點費力，它允許攻擊者詳細了解移動應用程式如何與其 API 通信，然后使用相同的知識來自動化攻擊或圍繞它構建其他服務。
The injection of Frida scripts at runtime allows for almost unlimited possibilities in how to tamper with your data integrity or whatever the mobile app is doing at runtime.
POSSIBLE SOLUTIONS
Secure Storage
I already read a lot about:
iOS - Keychain Services and Android - Keystore on the React Native docs: https://reactnative.dev/docs/security
Using this mechanism is recommended, but you need to be aware that anything that is stored in secure storage will need to be accessed and used by the mobile app at some point, and this is when the attacker can use an instrumentation framework to hook at runtime into the mobile app code. For example, when retrieving a securely stored secret the attacker can extract it to use outside of the mobile app to automate API requests as if they were from the mobile app.
So, use it to make it harder for less skilled attackers to tamper with your mobile app, but always remember that more skilled attackers may find their way around it.
Protecting Data Integrity in the Mobile App
-it's important that the data is not tempered with or changed in any way
To protecting data from being tampered with before it arrives to the API server it's necessary that you employ some solutions, like 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.
The issue of using only RASP is that the API server doesn't have visibility for the ongoing attacks on the mobile app, therefore not able to refuse requests from a mobile app under attack. Also, RASP can be bypassed by skilled attackers with the use of instrumentations frameworks, and the API server will not be aware of this happening, therefore will continue to serve requests, because it doesn't have a mechanism to know that what is making the request is indeed a genuine and un-tampered version of your mobile app.
Defending the API Server
I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.
One of the solutions proposed is to use a Mobile App Attestation solution that runs outside the mobile device, for example on the cloud, therefore doesn't make client side decisions about the state of the mobile app and device is running on, instead they are done in the cloud service and transmitted to the API server as signed JWT token, that the API server can then used to verify that what is making the request is indeed the genuine and un-tampered version of the official mobile app.
Android Safetynet and iOS Devicecheck
And SafeNet(Android) or DevieCheck(IOS) (never mentioned on react native docs or articles I read)
Using the Android SafetyNet and iOS DeviceCheck runtime protections is for sure a good starting point, but you need to be aware of their scope, limitations and complexity. They can be complemented with a robust Mobile App Attestation solution to give you an higher level of security and confidence that your API server will be able to know when the request is not from what it expects, a genuine and un-tampered version of your mobile app.
Security Layers
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?
I would not be approaching here how to implement it in React, because that is a huge topic and the exact code will depend on your current implementation, but I will summarize here the key points.
Security is always about adding as many layers as you can afford and are required by law, standards and business requirements. To summarize you should consider the following topics:
- Don't hardcode secrets in your mobile app code, but if you really want to do it, at least use Native C code.
- Obfuscate your mobile app code, because this will make it harder to reverse engineer the mobile app code in order to use instrumentations frameworks.
- Use runtime protections in your mobile app code and give preference to the ones that don't make decisions on the client side and allow for the API server to verify that the request is indeed from what it expects, a genuine and un-tampered version of your mobile app, like describe in the Mobile App Attestation I mentioned previously.
- Use certificate pinning to the public key to prevent MitM attacks, but wit h the awareness that it can be bypassed. I recommend you to read the section
Preventing MitM Attacksin this answer I gave to another question where you will learn how to implement static certificate pinning. If you can, try to use instead dynamic certificate pinning to allow to remotely update the pins used by your mobile app. - In your API server you can use rate limiting but do not give back in the headers the info about the rate limit available, because that is like putting the key to your front door under the mat.
- You can use Artificial Intelligence solutions, but be aware that they work in a negative identification model and are prone to false negatives and positives. If using a mobile app runtime protection that lets the API server know when is under attack then the use of AI solutions can be postponed until the API server needs to use other type of clients, like web apps.
This is not an exclusive list of topics you can consider to use in order to secure your mobile app and API server, but are the ones I think that more important for you to focus on.
DO YOU WANT TO GO THE EXTRA MILE?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10
OWASP API 安全專案旨在通過強調不安全 API 中的潛在風險并說明如何減輕這些風險來為軟體開發人員和安全評估人員提供價值。為了實作這一目標，OWASP API 安全專案將創建和維護一個前 10 個 API 安全風險檔案，以及創建或評估 API 時最佳實踐的檔案門戶。
對于移動應用程式
OWASP 移動安全專案 - 十大風險
OWASP 移動安全專案是一個集中資源，旨在為開發人員和安全團隊提供構建和維護安全移動應用程式所需的資源。通過該專案，我們的目標是對移動安全風險進行分類并提供開發控制以減少其影響或被利用的可能性。
OWASP - 移動安全測驗指南：
移動安全測驗指南 (MSTG) 是移動應用安全開發、測驗和逆向工程的綜合手冊。
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/379278.html