Buone pratiche nel trattare con l'abuso di schema URL personalizzato per rendere attacco di phishing ios

Question

Lo scenario:

Un'applicazione web che una volta che un nuovo utente completa la registrazione, una e-mail verrà inviato, contenente un URL che una volta toccato da un dispositivo iOS, verrà lanciata l'app iOS. Questo scenario è uno scenario classico per consentire agli utenti di utilizzare l'app mobile.

Durante l'implementazione (utilizzando lo schema URL), iniziamo a chiederci quanto è sicuro questo metodo? Teoricamente - un'applicazione dannosa potrebbe firmare fino allo stesso schema URL, e secondo Apple:

Nota: Se più di un app di terze parti registra per gestire lo stesso schema URL, non esiste attualmente alcun processo di determinazione a quale app verrà assegnato questo schema.

Implementing Custom URL Schemes by Apple

In tale scenario, se un utente sta colpendo l'url all'interno della posta elettronica, non si sa quale dei due (o più applicazioni) sarà lanciato - il nostro o quello dannoso. Diciamo che è stata lanciata un'app diversa - se è davvero dannosa, in teoria potrebbe simulare la pagina di accesso della nostra app e prendere le credenziali dell'utente.

Esistono buone pratiche che gestiscono tale scenario? Ho letto molti articoli riguardanti il ​​problema, tutti affermano che l'unica soluzione è aspettare che Apple renda unici questi schemi di URL. example1, example2

Mi piacerebbe sentir parlare di qualsiasi soluzione al problema, se esiste, Grazie in anticipo!

Answer 1

Dobbiamo supporre che l'app dannosa possa intercettare qualsiasi dato incluso in questo url e che l'autore sia stato libero di decodificare qualsiasi comportamento incluso nella tua app in modo da poter imitare l'interfaccia utente e qualsiasi convalida che la tua app tenta di eseguire. Tuttavia, possiamo anche presumere che l'app dannosa sia contenuta nella sua sandbox in modo che la tua app possa comunicare con il tuo back-end in privato. L'app dannosa può imitare qualsiasi comunicazione di questo tipo, ma questo ci consente di costruire una sconosciuta segreta all'app dannosa. Questo ci dà almeno l'opportunità di progettare alcune contromisure.

Una possibilità potrebbe essere:

1. Nell'ambito di registrazione costruire una coppia di chiavi pubblica/privata e conservarlo nella vostra app.
2. Inviare la chiave pubblica al proprio back-end Web come parte del processo di registrazione.
3. Codifica il carico utile del tuo URL utilizzando quella chiave pubblica.

Ora abbiamo inviato i dati alla tua app che potrebbe essere reindirizzata a un'app dannosa ma che l'app dannosa non è in grado di leggere. Questa è una soluzione parziale. Dobbiamo ancora stare attenti a progettare un'interfaccia utente che non incoraggi l'utente a cadere per un attacco di phishing poiché l'URL potrebbe ancora lanciare l'impostore.

I dati codificati potrebbero essere un token che possiamo utilizzare per autenticare l'utente e, pertanto, non richiedere mai che vengano nuovamente autenticati all'interno dell'app. Quindi non esiste una schermata di accesso da imitare (anche se una falsificazione intelligente potrebbe essere ancora sufficiente per indurre gli utenti a divulgare le proprie credenziali).

Un'alternativa potrebbe essere quella di utilizzare un segreto per utente simile memorizzato sul client come un sale da combinare con la password dell'utente. La sola password potrebbe quindi non essere sufficiente per l'autenticazione, pertanto un'app dannosa che acquisisce le proprie credenziali non è immediatamente in grado di accedere al proprio account.

Un altro design potrebbe essere quello di consentire all'utente di personalizzare la propria esperienza in modo riconoscibile. Potresti mostrare la loro immagine del profilo selezionata sullo schermo di accesso. Se tale selezione è nota solo alla tua app, un imitatore non dovrebbe essere in grado di duplicarlo in modo affidabile (anche in questo caso, nessuna garanzia significa che gli utenti prenderanno l'inganno).

Tutto questo introduce dei compromessi; gli utenti potrebbero comunque essere indotti a rivelare informazioni a app dannose, a prescindere dalla loro diversità dal client legittimo, i segreti del lato client possono essere estratti da altri attacchi e serve un piano per supportare gli utenti che cambiano, perdono o aggiornano i dispositivi. Devi decidere se tutto ciò migliora la sicurezza dei tuoi utenti e se vale la pena di implementarli.

Answer 2

provare qualcosa di simile:

Nella tua e-mail, lo stato che cliccando sulla URL lancerà l'applicazione e si accede per la prima volta, poi chiedere all'utente di digitare la nuova password. Includere un token nell'URL che, quando gestito dalla tua app, effettui un accesso una tantum e metti l'utente su una pagina "Nuova password".

Se un'app dannosa ha anche registrato l'URL personalizzato e rubato il link, dovrebbero (si spera) non essere in grado di fare molto con esso. Anche se replicano la tua interfaccia e chiedono all'utente una nuova password, non otterranno alcun risultato.

modifica: Dopo aver riflettuto ulteriormente, finché hai un attaccante attivo, sei praticamente fregato. L'utente malintenzionato potrebbe continuare a emulare la tua app, efficacemente MITMing te, indipendentemente da ciò che fai, purché sia ​​in grado di dirottare quell'URL iniziale. La mia soluzione funzionerebbe solo nei casi più basilari, non molto affidabili.