it-swarm.com.de

Stellen Sie sicher, dass der Webdienst nur von autorisierten Anwendungen aufgerufen wird

Vorwort

Mit meiner mobilen App können Benutzer Konten für meinen Dienst erstellen. Ich kann mich nicht nur bei externen Authentifizierungsanbietern wie Facebook anmelden, sondern dem Benutzer auch die Möglichkeit geben, ein Konto mit einer E-Mail-Adresse zu erstellen.

Normalerweise werden alle Anrufe an meinen Webdienst über die Basisauthentifizierung über HTTPS authentifiziert. Die Funktion zum Erstellen eines Kontos (auch über HTTPS) verfügt jedoch über keine Authentifizierung, da der Benutzer noch keine Anmeldeinformationen hat.

Wenn ich eine Website schreibe, würde ich Captcha verwenden, um zu verhindern, dass meine Datenbank per Skript mit gefälschten Konten gefüllt wird.

Frage

Wie kann ich überprüfen, ob neue Benutzeranforderungen von einer Instanz meiner Anwendung und nicht von einem Bot stammen?

Wenn alle Daten über HTTPS gesendet werden, reicht es aus, wenn die Anwendung ein gespeichertes Kennwort hat, um "Hey, ich bin es!" Zu sagen? Was sind die besten Methoden, um so etwas zu tun?

Ausarbeitung

Der Server ist in Java mit Spring Framework und Spring Security geschrieben. Er wird auf App Engine gehostet. Die Kosten sind ein Problem (sowohl Netzwerk als auch Berechnung). Die App ist ein Handyspiel Keine vertraulichen Informationen wie Kreditkartennummern speichern. Ich verfolge jedoch die Einkäufe von Benutzern in den Apple und Android) Stores. Mein größtes Anliegen ist die Spielerfahrung. Ich möchte nicht, dass ein Hacker das System herunterfährt und die Freude an dem Spiel ruiniert. Außerdem muss ich sicherstellen, dass der Spieler beim Erstellen eines Kontos so wenig Hindernissen wie möglich ausgesetzt ist.

pdate/Klarstellung

Ich suche nach einer Möglichkeit, um sicherzustellen, dass alle Anrufe an den Dienst von einer Instanz meiner Anwendung kommen. Benutzerkonten sind bereits geschützt, da der zustandslose Dienst erfordert, dass sie ihre Anmeldeinformationen bei jeder Anforderung senden. Es gibt keine Sitzungen und keine Cookies.

Ich muss Bot-Spam bei ungesicherten Anrufen wie dem Erstellen eines neuen Kontos stoppen. Ich kann Captcha nicht verwenden, da es nicht in den Ablauf der Anwendung passt.

33
sbsmith

Unter dem Strich müssen Sie ein Geheimnis in Ihre App einbetten. Es ist eine unglückliche Wahrheit, dass DRM (was mehr oder weniger das ist, was Sie erreichen wollen) unmöglich ist. Eine Person mit Zugriff auf Ihre App kann immer das eingebettete Geheimnis wiederherstellen, unabhängig davon, was Sie tun, um es zu schützen.

Es gibt jedoch viele Dinge, die Sie tun können, um die Wiederherstellung Ihres eingebetteten Geheimnisses zu erschweren.

  • Erstellen Sie es zur Laufzeit - Speichern Sie das Geheimnis nicht in einer Zeichenfolge oder Konfigurationsdatei irgendwo in Ihrer App. Leiten Sie es stattdessen aus einer Reihe von Berechnungen zur Laufzeit ab. Dies verhindert, dass Angreifer Ihre App einfach mit einem Hexeditor durchsuchen.

  • Senden Sie es niemals über das Kabel - Verwenden Sie ein Challenge-Response-System mit einer Nonce von> 128 Bit. Auf diese Weise kann ein Angreifer den SSL-Stream nicht mitM ( Das ist einfach, wenn er das mobile Gerät steuert. Denken Sie daran) und sehen Sie das Geheimnis im klaren.

Versuchen Sie in jedem Fall, einen bewährten Schlüsselverschlüsselungsmechanismus und ein Authentifizierungsprotokoll zu finden. Rollen Sie nicht Ihre eigenen.

26
lynks

Meistens können Sie nicht überprüfen, ob dies "Ihre App" ist: Reverse Engineering funktioniert, sodass jeder, der Zugriff auf Ihre App hat (z. B. sie auf sein Telefon herunterladen kann), an den Eingeweiden zupfen und sie mit seiner emulieren kann PC. @Lynks gibt Ihnen einige Hinweise, wie dieses Reverse Engineering zu einem frustrierenderen Unterfangen werden kann, aber täuschen Sie sich nicht: Wenn der Angreifer ausreichend motiviert ist, verlangsamen ihn diese Mechanismen um höchstens ein paar Tage.


Wenn es keine gute Antwort auf eine Frage gibt, kann es sich lohnen, den Boden so zu verschieben, dass sich die Frage ändert. Hier besteht das Hauptproblem beim Versuch, sicherzustellen, dass "Ihre App" auf der Clientseite ausgeführt wird, darin, dass es so etwas wie "Ihre App" gibt: Wenn jemand den Inhalt dieser App öffnet, lernt er alles, was ist um überall über alle Instanzen dieser App zu erfahren.

Hier ist ein Versuch, Ihr Problem zu lösen. Kennzeichnen Sie jede App-Instanz mit einem bestimmten Wert. "Tagging" bedeutet hier, dass beim Herunterladen der App ein Token in die App eingebettet wird und für jeden Download ein neuer Token-Wert erstellt wird. Damit jeder Benutzer seine eigene App mit Token bekommt. Die Idee ist, dass das Token Ihrem Server zur Kontoerstellung vorgelegt werden muss. Wenn Ihr Server zu viele Anforderungen mit demselben Token sieht, kann er diese automatisch ablehnen und dieses bestimmte Token verbieten.

Um weiterhin viele Konten automatisch zu erstellen, müsste der Angreifer auch das Herunterladen neuer App-Instanzen (jede mit ihrem eigenen Token-Wert) und das Abrufen des Token-Werts aus der heruntergeladenen App automatisieren. Angenommen, Ihr Server befindet sich am anderen Ende des App-Downloads, können Sie auch einen solchen Massendownload erkennen und von dort aus blockieren.

Damit dieses Schema funktioniert, müssen Sie in der Lage sein, bei Bedarf Token-Werte auf dem App-Download-Server zu erstellen (dies kann jedoch mit dem Apps-Installationssystem auf vorhandenen Smartphones schwierig einzurichten sein) und dies auf dem Kontoerstellungsserver Entscheiden Sie, ob ein Token-Wert echt ist oder nicht. HMAC ist das richtige kryptografische Werkzeug dafür.


Seien Sie sich bewusst, dass diese Art von Lösung bei weitem nicht perfekt ist. Dies sind Spiele und Tricks, um die Messlatte für den Angreifer höher zu legen: Wenn Sie ein System wie das von mir beschriebene entwerfen und installieren, muss ein erfolgreicher Angreifer den App-Download von vielen verschiedenen IP-Adressen automatisieren, um unter dem Radar zu bleiben Ihrer Heuristiken zur Erkennung solcher Dinge; Automatisieren Sie dann auch das Reverse Engineering, um die Token-Werte wiederherzustellen (verwenden Sie dazu die von @Lynks erläuterten Techniken). Leiten Sie dann die Werte an seine Bots weiter, die Konten erstellen. All dies ist theoretisch immer noch machbar: Schließlich können menschliche Benutzer die App herunterladen und Konten erstellen, und es gibt keine Möglichkeit, von außen wirklich den Unterschied zwischen einem durchschnittlichen menschlichen Benutzer zu machen , ein Schimpanse und ein Bot.

Wenn Sie den Angriff jedoch so komplex gestalten können, dass der Angreifer ihn für "die Mühe nicht wert" hält, gewinnen Sie.

17
Tom Leek

Wenn ich eine Website schreibe, würde ich Captcha verwenden, um zu verhindern, dass meine Datenbank per Skript mit gefälschten Konten gefüllt wird.

Nehmen Sie das also in die API auf. Wenn ein Benutzer ein Konto erstellen möchte:

  1. Der Client fordert ein CAPTCHA an.
  2. Der Server generiert ein CAPTCHA, speichert es und sendet eine Kopie an den Client.
  3. Der Kunde legt das Kontoerstellungsformular zusammen mit dem CAPTCHA vor.
  4. Der Benutzer füllt das Formular aus und beantwortet das CAPTCHA.
  5. Der Client fordert die Erstellung des neuen Kontos an und sendet die CAPTCHA-Antwort mit dieser Anfrage.

    • Wenn die CAPTCHA-Antwort falsch ist, löscht der Server seine Kopie des CAPTCHA (sodass der Client es nicht erneut versuchen kann) und antwortet mit einem Fehler.

Sie können auch etwas wie HashCash verwenden, um es jemandem zu erschweren, einen Brute-Force-Angriff durchzuführen. Stellen Sie jedoch sicher, dass HashCash schneller generiert werden kann, als ein Benutzer das Formular vernünftigerweise ausfüllen kann.

4
Brendan Long

Was Sie benötigen, ist eine ähnliche Anwendungsauthentifizierung. Es ist das gleiche Konzept wie die Authentifizierung, die Sie für API-Aufrufe mit Websites wie Twitter, Facebook und Foursquare durchführen. Sie erlauben niemandem, nur ihre API abzufragen. Stattdessen generieren sie einen API-Schlüssel und ein API-Geheimnis für Ihre App. Wenn Ihre Anwendung diese Schlüssel dem Server vorlegt, dürfen Sie deren APIs verwenden.

0
AdnanG

Wenn Sie sicherstellen möchten, dass Benutzer die API nur über Ihre App verwenden, müssen Sie regelmäßig alle Endpunkte und auch Ihre Client-App ändern. Jeder, der mithilfe Ihrer API eine eigene Client-App erstellt hat, hat jetzt eine Client-App, die nicht funktioniert. Jetzt könnten sie ihre App mit den richtigen API-Endpunkten erneut erstellen, aber wenn Sie die Endpunkte ständig ändern, geben sie schließlich einfach auf.

Eine Alternative könnte auch darin bestehen, sowohl die alten API-Endpunkte zu haben, die nur dann eine Fehlermeldung zurückgeben, wenn jemand versucht, sie aufzurufen, als auch die neuen (geänderten) API-Endpunkte, die von Ihrer aktualisierten Client-App verwendet werden. Sperren Sie alle IP-Adressen, die noch Ihre alten API-Endpunkte verwenden, damit der Hacker/Dieb, wenn er seine Client-App eines Drittanbieters aktualisiert, um sie an Ihre aktualisierten Endpunkte anzupassen, keine Benutzerbasis mehr hat, da alle Benutzer, die die alten API-Endpunkte verwendet haben, jetzt gesperrt sind. Dies wird diese Person auch davon abhalten, Ihre Daten weiterhin zu stehlen, indem Sie sie in ihrer eigenen Client-App anzeigen

0
Maurice