Das Szenario:
Eine Webanwendung, die nach der Registrierung eines neuen Benutzers eine E-Mail mit einer URL sendet, die auf einem iOS-Gerät angetippt wurde. Die iOS-App wird gestartet. Dieses Szenario ist ein klassisches Szenario, in dem Nutzer die mobile App verwenden können.
Bei der Implementierung (mithilfe des URL-Schemas) fragen wir uns, wie sicher diese Methode ist? Theoretisch könnte sich eine bösartige App zum selben URL-Schema anmelden und laut Apple:
Hinweis: Wenn mehr als eine Drittanbieter-App registriert wird, um dasselbe URL-Schema zu handhaben, gibt es derzeit keinen Prozess, um zu ermitteln, welche App dieses Schema erhält.
Implementieren von benutzerdefinierten URL-Schemas von Apple
Wenn in einem solchen Szenario ein Benutzer auf die URL in der E-Mail klickt, ist unbekannt, welche der beiden (oder mehr Apps) gestartet wird - unsere oder die bösartige. Nehmen wir an, eine andere App wird gestartet - wenn sie wirklich bösartig ist, könnte sie theoretisch die Anmeldeseite unserer App nachahmen und die Anmeldeinformationen des Benutzers erfassen.
Gibt es Best Practices, die ein solches Szenario behandeln? Ich habe viele Artikel zu diesem Thema gelesen, alle behaupten, dass die einzige Lösung darin besteht, auf Apple zu warten, damit diese URL-Schemata einzigartig werden. Beispiel1 , Beispiel2
Ich würde gerne über jede Lösung des Problems hören, wenn es sie gibt, Vielen Dank im Voraus!
Wir müssen davon ausgehen, dass die bösartige App alle in dieser URL enthaltenen Daten abfangen kann und dass es dem Autor freisteht, jegliches in Ihrer App enthaltene Verhalten rückgängig zu machen, damit es Ihre Benutzeroberfläche und jede von Ihrer App durchgeführte Überprüfung nachahmen kann. Wir können jedoch davon ausgehen, dass die schädliche App in einer eigenen Sandbox enthalten ist, sodass Ihre App privat mit Ihrem Backend kommunizieren kann. Die bösartige App kann eine solche Kommunikation nachahmen, erlaubt uns jedoch, ein Geheimnis zu erstellen, das der schädlichen App unbekannt ist. Das gibt uns zumindest die Möglichkeit, Gegenmaßnahmen zu entwickeln.
Eine Option könnte sein:
Nun haben wir Daten an Ihre App gesendet, die möglicherweise an eine schädliche App weitergeleitet werden, die die bösartige App jedoch nicht lesen kann. Das ist eine Teillösung. Wir müssen dennoch vorsichtig sein, um eine Benutzeroberfläche zu entwickeln, die einen Benutzer nicht dazu verleitet, auf einen Phishing-Angriff zu verzichten, da die URL den Betrüger immer noch starten könnte.
Die codierten Daten können ein Token sein, mit dem wir den Benutzer authentifizieren können und daher nie eine erneute Authentifizierung in der App erfordern. Dann gibt es keinen Anmeldebildschirm zum Nachahmen (obwohl eine schlaue Fälschung immer noch ausreichen könnte, um Benutzer dazu zu verleiten, ihre Anmeldeinformationen preiszugeben).
Eine Alternative könnte darin bestehen, ein ähnliches pro-Benutzer-Geheimnis zu verwenden, das auf dem Client als ein Salz gespeichert ist, um es mit dem Benutzerpasswort zu kombinieren. Das Passwort alleine reicht dann möglicherweise nicht aus, um sich zu authentifizieren, damit eine bösartige App, die ihre Anmeldeinformationen erfasst, nicht sofort auf ihr Konto zugreifen kann.
Ein anderes Design könnte sein, dass der Benutzer seine Erfahrung auf eine erkennbare Weise anpassen kann. Sie können das ausgewählte Profilbild auf dem Anmeldebildschirm anzeigen. Wenn diese Auswahl nur Ihrer App bekannt ist, sollte ein Nachahmer nicht in der Lage sein, sie zuverlässig zu duplizieren (wiederum keine Garantie, dass die Benutzer die Täuschung wahrnehmen).
All dies führt zu Kompromissen; Benutzer können immer noch dazu gebracht werden, Informationen zu schädlichen Apps zu enthüllen, egal wie unterschiedlich sie von Ihrem legitimen Client erscheinen, clientseitige Geheimnisse können durch andere Angriffe extrahiert werden und Sie benötigen einen Plan zur Unterstützung von Benutzern, die Geräte wechseln, verlieren oder aktualisieren. Sie müssen entscheiden, ob dies tatsächlich die Sicherheit Ihrer Benutzer verbessert und ob es sich lohnt, die Kosten zu implementieren.
Versuchen Sie etwas wie folgt:
Geben Sie in Ihrer E-Mail an, dass ein Klick auf die URL die App startet und Sie zum ersten Mal anmeldet und den Benutzer auffordert, sein neues Passwort einzugeben. Fügen Sie in die URL ein Token ein, das, wenn es von Ihrer App verarbeitet wird, eine einmalige Anmeldung durchführt und den Benutzer auf die Seite "Neues Passwort" versetzt.
Wenn eine bösartige App auch Ihre benutzerdefinierte URL registriert und den Link gestohlen hat, sollte sie (hoffentlich) nicht viel damit anfangen können. Selbst wenn sie Ihre Schnittstelle replizieren und den Benutzer nach einem neuen Passwort fragen, wird es nichts erreichen.
edit: Nachdem du darüber nachgedacht hast, solange du einen aktiven Angreifer hast, bist du ziemlich fertig. Der Angreifer kann weiterhin Ihre App emulieren und damit effektiv MITTM unabhängig von Ihrer Tätigkeit nutzen, solange er die ursprüngliche URL entführen kann. Meine Lösung würde nur in den einfachsten Fällen funktionieren, nicht wirklich zuverlässig.
Tags und Links ios security url-scheme phishing