我最近閱讀了很多關于將敏感資訊保護到 React Native 應用程式的帖子和文章。據我了解，您無法完全保護您的敏感資訊，只會讓黑客更難獲得它們。
因此，從這個角度來看，我想知道從外部服務器（即 Rest API）獲取這些敏感資訊（即 API 密鑰）是否不是“更安全”。
我解釋：
我知道中間人攻擊，但讓我的移動應用程式呼叫我的 API 以通過 HTTPS 請求獲取 API 密鑰會更安全（更靈活）嗎？這樣，應用程式二進制檔案中就不會保留任何敏感資訊。
為了保護中間人攻擊，我可以經常更改這些 API 密鑰值，以便它們僅在短時間內保持有效。
我想聽聽任何人關于這種系統的優點和缺點。
uj5u.com熱心網友回復：
API 的誤解
為了讓您為我的回答做好準備，我將首先澄清一些關于公共/私有 API 以及誰與什么真正訪問您的后端的常見誤解。
公共和私有 API
我經常看到開發人員認為他們的 API 是私有的，因為他們沒有檔案，沒有在任何地方做廣告，以及許多其他原因。
事實是，當你發布一個移動應用程式時，它與之通信的所有 API 現在都屬于公共領域，如果這些 API 沒有適當的身份驗證和授權機制，那么它背后的所有資料都可以被該應用程式中的任何人訪問。反向工程您的移動應用程式如何作業的互聯網。即使 API 已進行身份驗證，它們也可能容易受到錯誤實作的影響，并且根據OWASP API 安全性前 10 名漏洞串列，有些完全缺乏授權機制或存在錯誤的機制。
WHO 和 WHAT 訪問 API 服務器的區別
我寫了一系列關于 API 和移動安全的文章，在文章為什么你的移動應用程式需要 Api 密鑰？你可以詳細閱讀之間的區別誰和什么是訪問您的API服務器，但我會在這里提取它的主要花費：
向 API 服務器發出請求的內容是什么。它真的是您的移動應用程式的真實實體，還是機器人、自動化腳本或攻擊者使用 Postman 之類的工具手動瀏覽您的 API 服務器？
在誰是移動應用，我們可以驗證，授權和以多種方式確定，比如使用OpenID登錄連接或流的oauth2的用戶。
因此，考慮誰是您的 API 服務器將能夠對資料進行身份驗證和授權訪問的用戶，并考慮代表用戶發出該請求的軟體是什么。
API 密鑰服務
我知道中間人攻擊，但讓我的移動應用程式呼叫我的 API 以通過 HTTPS 請求獲取 API 密鑰會更安全（更靈活）嗎？這樣，應用程式二進制檔案中就不會保留任何敏感資訊。
雖然您確實在應用程式二進制檔案中沒有任何敏感資訊，但您還沒有解決問題。在我看來，您的暴露程度更高，因為您現在正在從公共和開放 API 端點獲取 API 密鑰。
我說這是開放，因為你不具備任何保障的是什么它確實是您的移動應用的真正和篡改版本發出請求。
因此，現在攻擊者需要做的就是對您的移動應用程式進行 MitM 攻擊或對其進行反編譯，以查看您從哪個 API 端點獲取 API 密鑰以發出請求，然后從他們的自動化腳本/機器人中復制該程序，因此不會您不再將它們硬編碼在應用程式二進制檔案中，這真的很重要。
API 密鑰輪換
為了保護中間人攻擊，我可以經常更改這些 API 密鑰值，以便它們僅在短時間內保持有效。
In light of the above explanation , on the API Keys Service section, you can even make the API keys restricted to be used only for one single request that the attacker will still succeed, because the attacker will be able to query the API endpoint to obtain API keys as if he was what the backend expects, a genuine and untampered version of your mobile app.
So, to be clear I am in favour of API keys rotation but only if you can get them into your mobile app from a secured external source, but your approach is open to be accessed by anyone on the internet.
I would like to hear anyone about PROS and CONS of such a system.
The system you are describing is not advisable to implement, because without being secured it's just a security disaster asking to occur. Securing it with an API key it's just going back to the initial problem with the disadvantage that your giving back to the mobile the sensitive info you want to keep away from hackers.
The best approach for you is to use a Reverse Proxy to keep the API keys private and secured from prying eyes.
The Reverse Proxy Approach
So, from that point of view, I would like to know if it wouldn't be "safer" to get those sensitive info (i.e. API keys) from an external server (i.e. Rest API).
What you are looking for is to implement a Reverse Proxy, that is usually used to protect access to third party APIs and your own APIs, by having the mobile app delegating the API requests to the Reverse Proxy, instead of asking for the API keys to make them from inside the mobile app.
The Reverse Proxy approach will avoid to have several API keys harcoded in the mobile app, but you still need one API key to protect access to the Reverse Proxy, therefore you are still vulnerable to the MitM attacks and to static reverse engineering of your mobile app.
The advantage now is that all your sensitive API keys are private and in an environment you can control and employ as many security measures you need to ensure that the request are indeed from what your backend expects, a genuine and untampered version of your mobile app.
Learn more about using a Reverse Proxy by reading the article I wrote Using a Reverse Proxy to Protect Third Party APIs:
In this article you will start by learning what Third Party APIs are, and why you shouldn’t access them directly from within your mobile app. Next you will learn what a Reverse Proxy is, followed by when and why you should use it to protect the access to the Third Party APIs used in your mobile app.
While the article focus on third party APIs the principle also applies to use with your own APIs.
Preventing MitM Attacks
When certificate pinning is implemented in a mobile app to secure the https channel then the sensitive data on the API requests is more safeguarded from being extracted.
I recommend you to read the section Preventing MitM Attacks in this answer I gave to another question where you will learn how to implement static certificate pinning and how to bypass it.
Despite being possible to bypass certificate pinning I still strongly recommend it to be implemented, because it reduces the attack surface on your mobile app.
A Possible Better Solution
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.
The solution will be the use of a Mobile App Attestation solution that will allow your backend to have an high degree of confidence that the request is from what it expects, a genuine and untampered version of your mobile app.
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
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.
For Mobile Apps
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.
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/331874.html
上一篇：讓整個區域都可以點擊
下一篇：Azure最佳實踐