Frage Best Practices zum Sichern einer REST-API / eines Webdienstes [geschlossen]


Welche Best Practices für den Umgang mit Sicherheit (Authentifizierung, Autorisierung, Identitätsmanagement) gibt es beim Erstellen einer REST-API oder eines REST-Services?

Beim Erstellen einer SOAP-API haben Sie WS-Sicherheit als Leitfaden und es gibt viel Literatur zu diesem Thema. Ich habe weniger Informationen zum Sichern von REST-Endpunkten gefunden.

Obwohl ich verstehe, dass REST absichtlich keine WS-ähnlichen Spezifikationen hat, hoffe ich, dass Best Practices oder empfohlene Muster entstanden sind.

Jede Diskussion oder Links zu relevanten Dokumenten würden sehr geschätzt werden. Wenn es darauf ankommt, würden wir WCF mit serialisierten POX / JSON-Nachrichten für unsere REST-APIs / Services verwenden, die mit v3.5 von .NET Framework erstellt wurden.


747
2017-08-11 05:44


Ursprung


Antworten:


Wie gesagt, Amazon S3 ist ein gutes Modell, mit dem man arbeiten kann. Ihre Anforderungssignaturen verfügen über einige Funktionen (z. B. die Aufnahme eines Zeitstempels), mit denen sowohl versehentliche als auch böswillige Anforderungswiederholungen verhindert werden können.

Das Schöne an HTTP Basic ist, dass praktisch alle HTTP-Bibliotheken es unterstützen. In diesem Fall benötigen Sie natürlich SSL, da das Senden von Klartext-Passwörtern über das Internet fast immer eine schlechte Sache ist. Basic ist bei der Verwendung von SSL dem Digest vorzuziehen, da der Digest selbst dann, wenn er bereits weiß, dass Anmeldeinformationen erforderlich sind, einen zusätzlichen Roundtrip zum Austausch des Nonce-Werts benötigt. Bei Basic senden die Anrufer die Anmeldeinformationen einfach beim ersten Mal.

Sobald die Identität des Clients festgestellt ist, ist die Autorisierung wirklich nur ein Implementierungsproblem. Sie können die Autorisierung jedoch an eine andere Komponente mit einem vorhandenen Autorisierungsmodell delegieren. Das Schöne an Basic ist, dass Ihr Server eine Kopie des Client-Passworts im Klartext erhält, die Sie einfach an eine andere Komponente Ihrer Infrastruktur weitergeben können.


280
2017-08-11 08:45



Abgesehen von HTTP gibt es keine Standards für REST. Es gibt etablierte REST-Dienste da draußen. Ich schlage vor, Sie werfen einen Blick auf sie und bekommen ein Gefühl dafür, wie sie funktionieren.

Zum Beispiel haben wir viele Ideen aus dem S3-REST-Service von Amazon ausgeliehen, als wir unsere eigenen entwickelten. Wir haben uns jedoch dafür entschieden, das erweiterte Sicherheitsmodell basierend auf Anforderungssignaturen nicht zu verwenden. Der einfachere Ansatz ist HTTP Basic Auth über SSL. Sie müssen entscheiden, was in Ihrer Situation am besten funktioniert.

Außerdem empfehle ich das Buch sehr RESTful Webdienste von O'reilly. Es erklärt die Kernkonzepte und bietet einige Best Practices. Sie können das von Ihnen bereitgestellte Modell im Allgemeinen übernehmen und es Ihrer eigenen Anwendung zuordnen.


108
2017-08-11 06:07



Vielleicht möchten Sie auch einen Blick darauf werfen OAuth, ein aufkommendes offenes Protokoll für die tokenbasierte Autorisierung, das spezifisch auf http apis abzielt.

Es ist dem Ansatz sehr ähnlich flickr und erinnere dich an die Milch "Ruhe" -Apis (nicht unbedingt gute Beispiele für erholsame Apis, aber gute Beispiele für den Token-basierten Ansatz).


68
2017-09-18 02:55



Ich bin irgendwie überrascht, dass SSL mit Client-Zertifikaten noch nicht erwähnt wurde. Zugegeben, dieser Ansatz ist nur dann sinnvoll, wenn Sie darauf zählen können, dass die Benutzergemeinschaft durch Zertifikate identifiziert wird. Aber eine Reihe von Regierungen / Unternehmen stellen sie ihren Benutzern zur Verfügung. Der Benutzer muss sich keine Gedanken über die Erstellung einer weiteren Kombination aus Benutzername und Passwort machen, und die Identität wird für jede einzelne Verbindung festgelegt, sodass die Kommunikation mit dem Server vollständig zustandslos erfolgen kann und keine Benutzersitzungen erforderlich sind. (Nicht zu implizieren, dass einige / alle der anderen genannten Lösungen Sitzungen erfordern)


40
2017-09-25 19:39



Jeder in diesen Antworten hat echte Zugriffskontrolle / Autorisierung übersehen.

Wenn Ihre REST-APIs / -Webdienste zum Beispiel das Senden / Abrufen medizinischer Datensätze erfordern, möchten Sie möglicherweise eine Zugriffskontrollrichtlinie definieren, um festzulegen, wer auf die Daten und unter welchen Umständen zugreifen darf. Zum Beispiel:

  • Ärzte können die Krankenakte eines Patienten, mit dem sie eine Pflegebeziehung haben, erhalten
  • Niemand kann medizinische Daten außerhalb der Übungsstunden POST (z. B. 9 bis 5)
  • Endnutzer können medizinische Unterlagen, die ihnen gehören, oder Krankenakten von Patienten, für die sie Vormund sind, erhalten
  • Pflegepersonal kann die Krankenakte eines Patienten aktualisieren, der zur selben Einheit wie die Krankenschwester gehört.

Um diese differenzierten Berechtigungen zu definieren und zu implementieren, müssen Sie eine attributbasierte Zugriffssteuerungssprache namens XACML, die eXtensible Access Control Markup Language, verwenden.

Die anderen Standards hier sind für folgendes:

  • OAuth: ID. Föderation und Delegierung von Berechtigungen, z. einen Dienst in meinem Auftrag auf einem anderen Dienst agieren lassen (Facebook kann auf meinem Twitter posten)
  • SAML: Identitätsverbund / Web-SSO. Bei SAML geht es sehr darum, wer der Benutzer ist.
  • WS-Security / WS-* Standards: Diese konzentrieren sich auf die Kommunikation zwischen SOAP-Diensten. Sie sind spezifisch für das Nachrichtenformat auf Anwendungsebene (SOAP) und sie befassen sich mit Aspekten der Nachrichtenübermittlung, z. Zuverlässigkeit, Sicherheit, Vertraulichkeit, Integrität, Atomarität, Vielseitigkeit ... Keine Abdeckung für Zugriffskontrolle und alle sind spezifisch für SOAP.

XACML ist technologieunabhängig. Es kann auf Java-Anwendungen, .NET, Python, Ruby ... Webservices, REST-APIs und mehr angewendet werden.

Die folgenden sind interessante Ressourcen:


34
2017-09-24 22:22



Ich habe OAuth einige Male benutzt und auch einige andere Methoden (BASIC / DIGEST) benutzt. Ich schlage OAuth von ganzem Herzen vor. Der folgende Link ist das beste Tutorial, das ich bei der Verwendung von OAuth gesehen habe:

http://hueniverse.com/oauth/guide/


25
2018-01-09 21:25



Es gibt eine große Checkliste auf Github:

Authentifizierung

  • Erfinden Sie das Rad nicht neu in Authentifizierung, Token-Generierung, Passwortspeicherung. Benutze die Standards.

  • Benutzen Max Retry und Jail-Funktionen in der Anmeldung.

  • Verwenden Sie die Verschlüsselung für alle sensiblen Daten.

JWT (JSON-Web-Token)

  • Verwenden Sie einen zufälligen komplizierten Schlüssel (JWT Secret), um Brute den Token sehr hart zu zwingen.

  • Extrahieren Sie den Algorithmus nicht aus der Nutzlast. Erzwinge den Algorithmus im Backend (HS256 oder RS256).

  • Token Ablauf machen (TTL, RTTL) so kurz wie möglich.

  • Speichern Sie keine sensiblen Daten in der JWT Nutzlast, kann es leicht entschlüsselt werden.

OAuth

  • Immer validieren redirect_uri serverseitig, um nur URLs auf der weißen Liste zuzulassen.

  • Versuchen Sie immer, Code und nicht Token zu tauschen (nicht zulassen response_type=token).

  • Verwenden Sie den Zustandsparameter mit einem zufälligen Hash, um dies zu verhindern CSRF auf der OAuth Authentifizierungsprozess.

  • Definieren Sie den Standardbereich und validieren Sie die Bereichsparameter für jede Anwendung.

Zugriff

  • Begrenzen Sie Anforderungen (Throttling), um DDoS- / Brute-Force-Angriffe zu vermeiden.

  • Verwenden Sie HTTPS auf der Serverseite, um MITM (Man In The Middle Attack) zu vermeiden

  • Benutzen HSTS Header mit SSL, um SSL-Angriff zu vermeiden.

Eingang 

  • Verwenden Sie die richtige HTTP-Methode entsprechend der Operation: GET (lesen), POST (erstellen), PUT/PATCH (ersetzen / aktualisieren), und DELETE (um einen Datensatz zu löschen) und antworten Sie mit 405 Method Not Allowed wenn die angeforderte Methode für die angeforderte Ressource nicht geeignet ist.

  • Validieren Sie den Inhaltstyp auf Anfrage Accept Header (Content Negotiation), um nur Ihr unterstütztes Format (z. application/xml, application/jsonusw.) und antworten Sie mit 406 Not Acceptable Antwort, wenn nicht abgestimmt.

  • Bestätigen content-type der gebuchten Daten, wie Sie sie akzeptieren (z. application/x-www-form-urlencoded, multipart/form-data, application/json, etc).

  • Validieren Sie Benutzereingaben, um häufige Sicherheitslücken zu vermeiden (z. B. XSS, SQL-Injection, Remotecodeausführung usw.).

  • Verwenden Sie keine vertraulichen Daten (Anmeldeinformationen, Kennwörter, Sicherheitstoken oder API-Schlüssel) in der URL, sondern verwenden Sie den Standard Authorization Header.

  • Verwenden Sie einen API-Gateway-Dienst, um das Caching zu aktivieren. Rate Limit Richtlinien (z. B. Quote, Spike Arrest, Concurrent Rate Limit) und API-Ressourcen dynamisch bereitstellen.

wird bearbeitet

  • Überprüfen Sie, ob alle Endpunkte hinter der Authentifizierung geschützt sind, um einen fehlerhaften Authentifizierungsprozess zu vermeiden.

  • Benutzereigene Ressourcen-ID sollte vermieden werden. Verwenden Sie / me / orders anstelle von / user / 654321 / orders.

  • IDs nicht automatisch erhöhen. Verwenden Sie stattdessen UUID.

  • Stellen Sie beim Parsen von XML-Dateien sicher, dass die Entitätsanalyse nicht aktiviert ist, um XXE (externe XML-Entitätsangriffe) zu vermeiden.

  • Wenn Sie XML-Dateien syntaktisch analysieren, stellen Sie sicher, dass die Entity-Erweiterung nicht aktiviert ist, um Milliarden Laughs / XML-Bomben durch Exponential-Expansionen zu vermeiden.

  • Verwenden Sie ein CDN für Dateiuploads.

  • Wenn Sie mit einer großen Datenmenge arbeiten, verwenden Sie Workers and Queues, um so viel wie möglich im Hintergrund zu verarbeiten und die Antwort schnell zurückzugeben, um HTTP-Blockierungen zu vermeiden.

  • Vergessen Sie nicht, die DEBUGGEN Modus aus.

Ausgabe

  • Senden X-Content-Type-Options: nosniff Header.

  • Senden X-Frame-Options: deny Header.

  • Senden Content-Security-Policy: default-src 'none' Header.

  • Entfernen Sie Fingerabdruck-Header - X-Powered-By, Server, X-AspNet-Version etc.

  • Macht content-type für Ihre Antwort, wenn Sie zurückkommen application/json dann ist deine Antwort content-type application/json.

  • Geben Sie keine vertraulichen Daten wie Anmeldeinformationen, Kennwörter oder Sicherheitstoken zurück.

  • Geben Sie den richtigen Statuscode entsprechend der abgeschlossenen Operation ein. (z.B. 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, etc).


22
2017-11-08 20:29