我目前正在設計一個本機應用程式，它將有一個簡單的用戶名/密碼登錄。在有效的身份驗證中，后端服務器發出 JWT 訪問令牌和重繪 令牌，最終在后續 API 呼叫中使用這些令牌。
我擔心的是，使用這種方法，我的應用程式很容易受到網路釣魚攻擊，黑客可以使用惡意攔截器反編譯和重新編譯我的應用程式。
為了克服這個問題，我正在考慮設計我的登錄 API，這樣accessToken登錄refreshTokenAPI 將在myapp://some-path?accessToken=X&refreshToken=Y. 這將確保如果網路釣魚應用程式正在呼叫我的 API，則accessToken和refreshToken被發送到原始 APP。
這是一個正確的方法嗎？如果沒有，會建議哪種設計？
uj5u.com熱心網友回復：
那會有什么幫助？如果我要進入您的應用程式進行破解和重新編譯，我將接管整個應用程式。我不會留下舊版本的副本，我只是要替換網址。因此，當您重定向到 myapp://somepath 時，它將重定向到同一個被黑的應用程式。
其次，重定向將如何做任何事情？發出 HTTP 請求不會導致應用程式在客戶端上啟動。它會導致 HTTP 請求回傳一個回應代碼為 301 的 HTTPResponse 物件。因此，您的重定向 URL 無論如何都不會啟動。
第三，為時已晚。當您擁有訪問和重繪 令牌時，您已經登錄。這意味著被黑客入侵的應用程式擁有您的密碼和憑據。2FA 在這里可能會有所幫助，使其更難攻擊，但前提是它基于時間，即使這樣它也只是減少了視窗。
如果用戶正在安裝您的應用程式的黑客版本并愿意登錄，那么您已經迷路了。
uj5u.com熱心網友回復：
你的問題
我目前正在設計一個本機應用程式，它將有一個簡單的用戶名/密碼登錄。在有效的身份驗證中，后端服務器發出 JWT 訪問令牌和重繪 令牌，最終在后續 API 呼叫中使用這些令牌。
您需要記住，離開后端或存盤在移動應用程式中的任何秘密都不再是秘密，而是公開的東西，即使您使用 TLS（在某些情況下可能被截獲）和證書固定（在某些情況下可以繞過），因為攻擊者可以通過大量開源工具和技術對您的移動應用程式進行逆向工程，其中之一是您提到的靜態反編譯：
我擔心的是，使用這種方法，我的應用程式很容易受到網路釣魚攻擊，黑客可以使用惡意攔截器反編譯和重新編譯我的應用程式。
一旦它被反編譯，攻擊者就可以對你的代碼做任何他想做的事，而不僅僅是添加攔截器。眾所周知，Google Play 商店充滿了克隆和重新打包的應用程式，這些應用程式將使用與正版應用程式相同的后端。你甚至有一個 repo RePack: A repository of repackaged Android apps，它說明了這個問題：
RePack 是從 AndroZoo 收集的超過 15,000 個重新打包的 Android 應用程式對的存盤庫。應用程式的 SHA256 可在 repackaging_pairs.txt 檔案中找到。實際的 APK 在 AndroZoo 資料集中可用，可以通過提供 SHA256 作為輸入來下載。請關注此頁面以了解如何從 AndroZoo 下載應用程式。
重新打包后，這些應用程式可用于簡單地向其添加廣告并充當您服務的假應用程式，利潤將流向攻擊者，或可用于分發惡意軟體和/或監視用戶，如文章700,000所示去年在 Google Play 商店中發現的惡意 Android 應用程式：
谷歌已經確認，它必須在 2017 年從 Google Play 商店中洗掉近 700,000 個潛在惡意應用程式——比上一年增加了 70%。
逆向工程
事實是，在客戶端運行的任何東西都可以很容易地被攻擊者在他控制的設備上進行逆向工程。
在對移動應用程式進行逆向工程時，攻擊者的第一步可能是執行靜態二進制分析以提取所有靜態機密并識別攻擊向量，您可以在我的文章 How to Extract an API key from a Mobile App with Static Binary分析：
可用于逆向工程的開源工具范圍很廣，我們真的無法在本文中觸及這個主題的表面，而是將重點放在使用移動安全框架 (MobSF)來演示如何逆向工程我們的移動應用程式的 APK。MobSF 是一組開源工具，它們在一個有吸引力的儀表板中顯示其結果，但在 MobSF 和其他地方使用的相同工具可以單獨使用以實作相同的結果。
在本文中，我們將使用Android Hide Secrets研究存盤庫，它是一個虛擬移動應用程式，使用多種不同的技術隱藏 API 密鑰。
提取機密的另一種方法是執行中間人 (MitM) 攻擊以攔截 TLS 連接并提取所有機密并了解移動應用程式如何與后端和任何其他第三方 API 互動，您可以看到我是怎么做的它在文章 Steal that Api Key with a Man in the Middle Attack 中：
為了幫助演示如何竊取 API 密鑰，我在 Github 上構建并發布了適用于 Android 的Currency Converter Demo應用程式，它使用了我們在早期Android Hide Secrets應用程式中使用的相同JNI/NDK技術來隱藏 API 密鑰.
因此，在本文中，您將學習如何設定和運行中間人攻擊，以攔截您控制的移動設備中的 https 流量，從而竊取 API 密鑰。最后，您將了解如何緩解中間人攻擊。
等等，我想你現在在想，但我將使用證書固定來保護我的 TLS 通道，沒問題只需在繞過證書固定一文中查看如何在攻擊者控制的設備中輕松繞過證書固定
在本文中，您將學習如何重新打包移動應用程式以禁用證書固定，并且在此程序中，您還將學習如何創建具有可寫系統的 Android 模擬器，以允許將代理服務器的自定義證書頒發機構添加到Android 作業系統信任庫。這將允許我們繞過證書鎖定并通過中間人攻擊攔截移動設備與其后端之間的請求。
雖然重新打包移動應用程式以繞過固定是一個很好的解決方案，但我更喜歡在運行時動態地執行它，正如我在文章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.
Now you may be thinking that you have lost the battle and shouldn't care about adding protections because they will end-up to be bypassed. Well, I have to tell you that software security shares the same traits as the defences in the medieval castles, where they used it in layers, in order to make the assault to the castle as hard as possible, and hopefully impossible. So, you need to adopt the same posture as them and put as many security layers as you can afford, and required by law, in order to make the attackers efforts time consuming and to require more expertise then most of them may have.
YOUR QUESTIONS
In order to overcome this, I was thinking of designing my Login API, so that rather than having an accessToken and a refreshToken in the payload response of the API, the Login API will issue a 301 Redirect on myapp://some-path?accessToken=X&refreshToken=Y. This will ensure that if a phishing app is calling my APIs, the accessToken and the refreshToken are sent to the original APP.
Is this a correct approach?
So, I think that by now is obvious that your solution will not be effective and will be easily defeated with repackaging the mobile app, MitM attack it or simply by instrumenting the code at runtime.
If not, which design would be suggested?
You should use a security approach where the API backend is able to recognize that what is making the request is indeed a genuine and untampered/repacked/cloned version of your mobile app, not just who is making the request, as when user authentication is solely used to protect unauthorised access to an API.
The Difference Between WHO and WHAT is Accessing the API Server
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:
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.
So think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
POSSIBLE 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.
You will see that you can use a plethora of defence layers, like in medieval castles, and that the solution you may want to employ, to guarantee with an high degree of confidence that what is doing the request to the backend is indeed your genuine mobile app, is the Mobile App Attestation.
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/qukuanlian/420039.html
標籤：
上一篇：如何在顫振中制作強密碼？[復制]