it-swarm-eu.dev

Wie sichere ich meine REST API)?

Im Detail ist hier das Problem:

Ich erstelle eine Android App, die meine REST API im Backend verbraucht. Ich muss zunächst eine Registrierungs- und Anmelde-API erstellen. Nachdem ich eine Weile mit Google gesucht habe, habe ich das Gefühl, dass ich nur zwei Ansätze verfolgen kann.

  • Während der Registrierung verwende ich https und erhalte die Anmeldeinformationen des Benutzers. Speichern Sie es in meiner Datenbank unter dem Benutzernamen (Serverseite). Während der Anmeldung verwende ich erneut https und frage nach den Anmeldeinformationen des Benutzers. Überprüfen Sie das Hash-Passwort in der Datenbank und geben Sie ihm eine Sitzungs-ID zurück, die ich erst ablaufen lassen möchte, wenn er sich abmeldet. Außerdem werden alle anderen API-Aufrufe (GET/POST), die der Benutzer ausführt, mit dieser Sitzungs-ID versehen, damit ich den Benutzer überprüfen kann.

Aber im obigen Ansatz bin ich gezwungen, https für jeden API-Aufruf zu verwenden, sonst bin ich anfällig für Man in The Middle Attack , dh wenn jemand über meine Sitzungs-ID schnüffelt, kann er ähnliche GET/POST-Anforderungen rekonstruieren, die ich nicht möchte. Habe ich mit der obigen Annahme Recht ?

  • Die zweite Option besteht darin, dem Pfad Amazon Web Services zu folgen, in dem ich die Authentifizierung mit öffentlichem/privatem Schlüssel verwende. Wenn sich ein Benutzer registriert, verwende ich eine https API, um seine Anmeldeinformationen in der Datenbank zu speichern. Von da an verwende ich das Hash-Passwort des Benutzers als privaten Schlüssel. Alle weiteren API-Aufrufe, die der Benutzer ausführt, haben einen Hash-Blob der Anforderungs-URL unter Verwendung des privaten Schlüssels des Benutzers. Auf der Serverseite rekonstruiere ich den Hash mit dem gespeicherten privaten Schlüssel. Wenn der Hash übereinstimmt, lasse ich den Benutzer seine Aufgabe erledigen, andernfalls lehne ich ab. In dieser Option muss ich https nur für die Registrierungs-API verwenden. Das REST kann weitergehen http.

Der Nachteil ist jedoch, dass ich gezwungen bin, meine Registrierungs-API in einem separaten virtuellen Verzeichnis zu hosten (ich verwende IIS und bin mir nicht sicher, ob ich sowohl http als auch https hosten kann) APIs im selben virtuellen Verzeichnis). Daher bin ich gezwungen, die Registrierungs-API in einer separaten Projektdatei zu entwickeln. Auch hier habe ich Recht mit der obigen Annahme ?

Bearbeiten: Ich verwende ASP.NET MVC4, um die Web-API zu erstellen.

Der Grund, warum ich https für alle meine REST) nicht verwenden möchte API-Aufrufe sind meiner Meinung nach nicht leicht und erzeugen mehr Netzwerknutzdaten, die möglicherweise nicht für eine mobile App geeignet sind. Weitere Verschlüsselung/Entschlüsselung und zusätzlicher Handshake können die Akkulaufzeit eines Mobiltelefons weiter beeinträchtigen? Oder nicht signifikant ?

Welchen der beiden oben genannten Ansätze würden Sie vorschlagen ?

PS: Wir sind überall mit Https gefahren, und es war die beste Entscheidung. Mehr davon auf meinem Blog .

84
noob Mama

Ich würde überall mit SSL/TLS arbeiten (da Sie beide Seiten kontrollieren, sollte es machbar sein, TLS 1.2 zu erzwingen). Es ist relativ einfach zu bedienen und Sie erhalten viele Sicherheitsfunktionen kostenlos. Wenn Sie beispielsweise kein SSL verwenden, müssen Sie sich über Wiederholungsangriffe Gedanken machen.

Wenn Sie sich Sorgen um die Leistung machen, stellen Sie sicher, dass die Wiederaufnahme der Sitzung sowohl vom Server als auch vom Client unterstützt wird. Dies macht spätere Handshakes viel billiger. Da der Handshake in SSL im Vergleich zur Verschlüsselung der tatsächlichen Daten recht teuer ist, wird die Gesamtlast erheblich reduziert.

Wenn Sie HTTP 2 verwenden, können Sie sogar mehrere Anforderungen über eine einzige Verbindung senden. Auf diese Weise vermeiden Sie den vollständigen Overhead von TCP und SSL-Handshake bei späteren Anforderungen).

54
CodesInChaos

Ich empfehle die Verwendung von OAuth. Sie sollten es auf jeden Fall nachlesen, wenn Sie nicht damit vertraut sind. Als Plus können Sie Identitätsanbieter von Drittanbietern verwenden, sodass Ihre Benutzer ihre Google/Windows Live/etc.-Konten für Ihre Anwendung verwenden können, wodurch die Registrierung geschont wird.

Selbst wenn Sie Ihr eigenes Authentifizierungsframework erstellen möchten, empfehle ich nicht, nicht ablaufende Sitzungen zu verwenden. Die Sitzung sollte nach einer ausreichenden Leerlaufzeit ablaufen, da dies sonst mehr Raum für die Ausnutzung bietet (z. B. Sitzungsentführung).

23

Kommt darauf an, wie sicher es sein muss . Jedes Mal, wenn Sie die Lösung komplexer gestalten, Sie hinterlassen wahrscheinlich auch ein klaffendes Loch. Es ist besser, eine Art branchenübliches Autorisierungs- und Authentifizierungsmodul zu verwenden.

Sie werden wahrscheinlich in Ordnung sein, solange Sie:

  • verschlüsselung des Passworts (mit etwas wie AES oder Blowfish)
  • das Passwort salzen
  • senden der Daten über HTTPS

Eine Alternative ist OAuth.

Wenn jemand dich schlimm genug hacken will, wird er immer einen Weg finden. Das Geheimnis besteht darin, die Zeit und den Aufwand so weit zu erhöhen, dass es sich nicht lohnt, wenn jemand es tut. Wenn Sie also keine großen Mengen an Kunden- und/oder Finanzdaten haben und kein hochkarätiges Unternehmen sind, sollte eine Standard-Sicherheitsimplementierung wie die oben genannte in Ordnung sein.

4
Dan Blows

Sie werden niemals 100% sicher sein, dass Ihre API sicher ist.

Der Hauptgrund dafür ist, dass Sie Ihren Kunden/Benutzern wahrscheinlich eine Binärdatei übergeben, die einfach funktioniert. Dann haben sie weltweit die Zeit, diese Binärdatei zu zerlegen, um nach Schlüsseln/Geheimnissen zu suchen, die zur sicheren Authentifizierung auf Ihrem API-Server verwendet werden. Der Client-API-Endpunkt ist der schwächste Punkt, da er das Gerät besitzt, auf dem Ihre Binärdatei ausgeführt wird. Daher können sie die Zertifikate bearbeiten, die ihr Gerät als gültig erachtet oder nicht.

Ein klares Beispiel für das, worüber ich spreche, ist dieser Artikel ("Ein Tutorial für das Reverse Engineering der privaten API Ihrer Software: Hacken Ihrer Couch"). Und ich möchte diese Antwort abschließen, indem ich einen der letzten Absätze darin zitiere:

Ist es möglich, die Verwendung einer privaten API durch Clients von Drittanbietern vollständig zu verhindern? Das glaube ich nicht. Die Verwendung von SSL-Pinning würde das Sniffing in API-Anforderungen mithilfe einer einfachen transparenten Proxy-Technik verhindern, wie zuvor beschrieben. Selbst wenn Sie die Binärdatei verschleiern, kann ein motivierter Hacker mit einigen Ressourcen und Zeit die App-Binärdatei immer rückentwickeln und den privaten Schlüssel/das private Zertifikat erhalten. Ich denke, die Annahme, dass der Client-Endpunkt sicher ist, ist von Natur aus falsch. Ein API-Client ist eine Schwachstelle.

2
knocte

In JEE haben wir den Begriff der Container-verwalteten Sicherheit. In diesem Fall richte ich meine Restful Services für die Verwendung der Standardauthentifizierung ein, bei der standardmäßig die HTTP-Kennwortauthentifizierung für einen auf dem App-Server eingerichteten Bereich verwendet wird. Dies umgeht die Notwendigkeit eines HTML-Formulars für die Anmeldung oder die Komplexität der Bereitstellung clientseitiger Zertifikate.

Die Anwendung geht lediglich davon aus, dass ein Benutzerprinzipal und möglicherweise andere Daten wie Identifikationsdetails vorhanden sind, die mit der Anforderung übergeben werden. Dies schließt die erholsamen APIs ein.

In meinem Setup habe ich ein OAuth2 JASPIC Server Auth Modul [ Source ] implementiert, das das OAuth Token) speichert, das symmetrisch verschlüsselt ist, wo das Der Schlüssel befindet sich auf dem Server, der auch eine begrenzte Lebensdauer im Cookie hat, und verwendet diesen als Authentifizierung für die Anwendung.

Auf diese Weise halte ich die Anwendung von der Authentifizierungssemantik fern und als Bonus, wenn ich Funktionsintegrationstests mit Selenium durchführen möchte, kann ich ein Downgrade auf HTTP-Kennwörter durchführen, anstatt einen komplexen Test durchzuführen, der eine Verbindung zu einem OAuth Anbieter die ganze Zeit.

Außerdem werde ich weiterhin SSL verwenden, um sicherzustellen, dass Ihr Transport zumindest sicher ist. Wenn Sie kein SSL verwenden, wird die Anwendung häufiger Angriffe auf Ihre Anwendung zu komplex.

Wohlgemerkt, dies ist JEE, aber die Mechanismen können auf jede Technologie angewendet werden.

2

Nur HTTPS ist ein Muss.

Da Sie sowohl die App als auch die API steuern, würde ich Certificate Pinning implementieren. Das Feststecken von Zertifikaten kann besiegt werden, ist jedoch eine gute Abschreckung gegen den Gelegenheitsinspektor.

Sie können mit Payload Encryption eine weitere Ebene hinzufügen. Dies geht zu Lasten eines soliden Schlüsselverteilungs- und Schlüsselrotationsprozesses.

Wenn Ihre App Zugriffstoken oder Sitzungscookies zur Autorisierung für bestimmte APIs verwendet, stellen Sie sicher, dass diese eine Zeitüberschreitung aufweisen. Ich beobachte so oft Inhaber-Token, die tagelang, monatelang oder nie verfallen.

Goldene Regel: Ein mobiles Betriebssystem ist eine feindliche Umgebung. Behandle es mit Sorgfalt und mangelndem Vertrauen.

1
rustyMagnet

Ich denke, es ist nicht leicht und schafft mehr Netzwerknutzlast

Dies hat einige Auswirkungen auf die Latenz. Wenn Sie also Daten in der Größenordnung von 10 Millisekunden verarbeiten müssen, kann dies eine Überlegung sein. Aber selbst im Jahr 2012 kann eine sehr einfache Hardware den Rechenaufwand mit vernachlässigbaren Auswirkungen bewältigen.

die möglicherweise nicht am besten für eine mobile App geeignet ist

Dann ist das oben genannte kein Problem.

0
symcbean