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

https://stackoverflow.com/questions/7551

08-06-2019
|

Frage

Gibt es beim Entwerfen einer REST-API oder eines REST-Dienstes etablierte Best Practices für den Umgang mit Sicherheit (Authentifizierung, Autorisierung, Identitätsmanagement)?

Beim Erstellen einer SOAP-API können Sie sich an WS-Security orientieren 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 Spezifikationen analog zu WS-* hat, hoffe ich, dass Best Practices oder empfohlene Muster entstanden sind.

Für jede Diskussion oder jeden Link zu relevanten Dokumenten wären wir sehr dankbar.Wenn es darauf ankommt, würden wir WCF mit POX/JSON-serialisierten Nachrichten für unsere REST-APIs/Dienste verwenden, die mit v3.5 des .NET Frameworks erstellt wurden.

Lösung

Wie Tweakt sagte, ist Amazon S3 ein gutes Modell zum Arbeiten.Ihre Anforderungssignaturen verfügen über einige Funktionen (z. B. die Integration eines Zeitstempels), die zum Schutz vor versehentlicher und böswilliger Wiederholung von Anforderungen beitragen.

Das Schöne an HTTP Basic ist, dass es praktisch von allen HTTP-Bibliotheken unterstützt wird.In diesem Fall müssen Sie natürlich SSL benötigen, da das Versenden von Passwörtern im Klartext über das Internet fast überall eine schlechte Sache ist.Bei der Verwendung von SSL ist Basic gegenüber Digest vorzuziehen, denn selbst wenn der Anrufer bereits weiß, dass Anmeldeinformationen erforderlich sind, erfordert Digest einen zusätzlichen Roundtrip, um den Nonce-Wert auszutauschen.Bei Basic sendet der Anrufer einfach beim ersten Mal die Zugangsdaten.

Sobald die Identität des Clients festgestellt ist, ist die Autorisierung eigentlich nur noch ein Implementierungsproblem.Sie könnten die Autorisierung jedoch an eine andere Komponente mit einem vorhandenen Autorisierungsmodell delegieren.Das Schöne an Basic ist auch hier, dass Ihr Server am Ende eine Klartextkopie des Client-Passworts erhält, die Sie bei Bedarf einfach an eine andere Komponente in Ihrer Infrastruktur weitergeben können.

Andere Tipps

Es gibt keine anderen Standards für REST als HTTP.Es gibt etablierte REST-Dienste.Ich schlage vor, dass Sie einen Blick darauf werfen und ein Gefühl dafür bekommen, wie sie funktionieren.

Beispielsweise haben wir bei der Entwicklung unseres eigenen Dienstes viele Ideen vom S3-REST-Dienst von Amazon übernommen.Wir haben uns jedoch gegen die Verwendung des erweiterten Sicherheitsmodells entschieden, das auf Anforderungssignaturen basiert.Der einfachere Ansatz ist die HTTP-Basic-Authentifizierung über SSL.Sie müssen entscheiden, was in Ihrer Situation am besten funktioniert.

Außerdem kann ich das Buch wärmstens empfehlen RESTful-Webdienste von O'reilly.Es erklärt die Kernkonzepte und bietet einige Best Practices.Im Allgemeinen können Sie das von ihnen bereitgestellte Modell verwenden und es Ihrer eigenen Anwendung zuordnen.

Vielleicht möchten Sie auch einen Blick darauf werfen OAuth, ein aufstrebendes offenes Protokoll für tokenbasierte Autorisierung, das speziell auf http-APIs abzielt.

Es ist dem Ansatz von sehr ähnlich flickr Und Erinnere dich an die Milch „Rest“-APIs (nicht unbedingt gute Beispiele für Restful-APIs, aber gute Beispiele für den tokenbasierten Ansatz).

Es gibt eine tolle Checkliste auf Github:

Authentifizierung

Erfinden Sie das Rad bei Authentifizierung, Token-Generierung und Passwortspeicherung nicht neu.Nutzen Sie die Standards.
Verwenden Max Retry und Gefängnisfunktionen in der Anmeldung.
Verwenden Sie Verschlüsselung für alle sensiblen Daten.

JWT (JSON-Web-Token)

Verwenden Sie einen zufälligen, komplizierten Schlüssel (JWT-Geheimnis), um das brutale Erzwingen des Tokens sehr zu erschweren.
Extrahieren Sie den Algorithmus nicht aus der Nutzlast.Erzwingen Sie den Algorithmus im Backend (HS256 oder RS256).
Token-Ablauf festlegen (TTL, RTTL) so kurz wie möglich.
Speichern Sie keine sensiblen Daten im JWT Nutzlast kann leicht dekodiert werden.

OAuth

Immer validieren redirect_uri serverseitig, um nur URLs auf der Whitelist zuzulassen.
Versuchen Sie immer, gegen Code und nicht gegen Token einzutauschen (nicht zulassen). response_type=token).
Um dies zu verhindern, verwenden Sie den Statusparameter mit einem zufälligen Hash CSRF auf der OAuth Authentifizierungsprozess.
Definieren Sie den Standardbereich und validieren Sie die Bereichsparameter für jede Anwendung.

Zugang

Begrenzen Sie Anfragen (Throttling), um DDoS-/Brute-Force-Angriffe zu vermeiden.
Verwenden Sie HTTPS auf der Serverseite, um MITM (Man In The Middle Attack) zu vermeiden.
Verwenden HSTS Header mit SSL, um SSL-Strip-Angriffe 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 zuzulassen (z. B. application/xml, application/json, usw.) und antworten Sie mit 406 Not Acceptable Antwort, wenn keine Übereinstimmung vorliegt.
Bestätigen content-type der veröffentlichten Daten, wie Sie akzeptieren (z.B. application/x-www-form-urlencoded, multipart/form-data, application/json, usw).
Validieren Sie Benutzereingaben, um häufige Schwachstellen zu vermeiden (z. B.XSS, SQL-Injection, Remote-Code-Ausführung usw.).
Verwenden Sie in der URL keine vertraulichen Daten (Anmeldeinformationen, Passwörter, Sicherheitstokens oder API-Schlüssel), sondern verwenden Sie Standard Authorization Header.
Verwenden Sie einen API-Gateway-Dienst, um Caching zu aktivieren. Rate Limit Richtlinien (z.B.Kontingent, Spike Arrest, Concurrent Rate Limit) und stellen Sie API-Ressourcen dynamisch bereit.

wird bearbeitet

Überprüfen Sie, ob alle Endpunkte durch die Authentifizierung geschützt sind, um einen fehlerhaften Authentifizierungsprozess zu vermeiden.
Eine benutzereigene Ressourcen-ID sollte vermieden werden.Verwenden Sie /me/orders anstelle von /user/654321/orders.
IDs nicht automatisch erhöhen.Verwenden Sie stattdessen UUID.
Wenn Sie XML-Dateien analysieren, stellen Sie sicher, dass die Entitätsanalyse nicht aktiviert ist, um XXE (Angriff auf externe XML-Entitäten) zu vermeiden.
Wenn Sie XML-Dateien analysieren, stellen Sie sicher, dass die Entitätserweiterung nicht aktiviert ist, um Billion Laughs/XML-Bomben durch exponentielle Entitätserweiterungsangriffe zu vermeiden.
Verwenden Sie ein CDN für Datei-Uploads.
Wenn Sie große Datenmengen verarbeiten, verwenden Sie Worker und Warteschlangen, um so viel wie möglich im Hintergrund zu verarbeiten und die Antwort schnell zurückzugeben, um HTTP-Blockierung zu vermeiden.
Vergessen Sie nicht, das Gerät einzuschalten DEBUGGEN Modus AUS.

Ausgabe

Schicken X-Content-Type-Options: nosniff Header.
Schicken X-Frame-Options: deny Header.
Schicken Content-Security-Policy: default-src 'none' Header.
Fingerabdruck-Header entfernen – X-Powered-By, Server, X-AspNet-Version usw.
Gewalt content-type für Ihre Antwort, wenn Sie zurückkommen application/json dann lautet Ihr Antwortinhaltstyp application/json.
Geben Sie keine sensiblen Daten wie Anmeldeinformationen, Passwörter oder Sicherheitstokens zurück.
Geben Sie den richtigen Statuscode entsprechend dem abgeschlossenen Vorgang zurück.(z.B. 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, usw).

Ich bin etwas überrascht, dass SSL mit Client-Zertifikaten noch nicht erwähnt wurde.Zugegebenermaßen ist dieser Ansatz nur dann wirklich sinnvoll, wenn man sich darauf verlassen kann, dass die Benutzergemeinschaft durch Zertifikate identifiziert wird.Aber eine Reihe von Regierungen/Unternehmen stellen sie ihren Benutzern zur Verfügung.Der Benutzer muss sich nicht darum kümmern, eine weitere Kombination aus Benutzername und Passwort zu erstellen, und die Identität wird bei jeder einzelnen Verbindung hergestellt, sodass die Kommunikation mit dem Server völlig zustandslos erfolgen kann und keine Benutzersitzungen erforderlich sind.(Damit soll nicht impliziert werden, dass für eine/alle der anderen genannten Lösungen Sitzungen erforderlich sind)

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

Wenn es bei Ihren REST-APIs/Webdiensten beispielsweise um das POSTing/GETing von Krankenakten geht, möchten Sie möglicherweise Zugriffskontrollrichtlinien definieren, die festlegen, wer unter welchen Umständen auf die Daten zugreifen kann.Zum Beispiel:

Ärzte können die Krankenakte eines Patienten abrufen, mit dem sie ein Pflegeverhältnis haben
Niemand darf medizinische Daten außerhalb der Praxiszeiten posten (z. B.9 zu 5)
Endbenutzer können medizinische Aufzeichnungen, die ihnen gehören, oder medizinische Aufzeichnungen von Patienten, deren Vormund sie sind, ERHALTEN
Krankenschwestern können die Krankenakte eines Patienten AKTUALISIEREN, der derselben Abteilung wie die Krankenschwester angehört.

Um diese fein abgestuften Autorisierungen zu definieren und zu implementieren, müssen Sie eine attributbasierte Zugriffskontrollsprache namens XACML, die eXtensible Access Control Markup Language, verwenden.

Die anderen Standards hier gelten für Folgendes:

OAuth:Ausweis.Zusammenschluss und Delegation von Berechtigungen, z.B.Lassen Sie einen Dienst in meinem Namen für einen anderen Dienst agieren (Facebook kann auf meinem Twitter posten)
SAML:Identitätsföderation / Web-SSO.Bei SAML geht es vor allem darum, wer der Benutzer ist.
WS-Sicherheit / WS-*-Standards:Diese konzentrieren sich auf die Kommunikation zwischen SOAP-Diensten.Sie sind spezifisch für das Application-Level-Messaging-Format (SOAP) und befassen sich mit Aspekten der Nachrichtenübermittlung, z.Zuverlässigkeit, Sicherheit, Vertraulichkeit, Integrität, Atomizität, Eventing ...Keines deckt die Zugriffskontrolle ab und alle sind spezifisch für SOAP.

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

Die folgenden Ressourcen sind interessant:

die OASIS XACML Webseite
Die NIST ABAC-Standard

Ich habe OAuth ein paar Mal verwendet und auch einige andere Methoden (BASIC/DIGEST).Ich empfehle OAuth von ganzem Herzen.Der folgende Link ist das beste Tutorial, das ich zur Verwendung von OAuth gesehen habe:

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

Einer der besten Beiträge, die ich je zum Thema Sicherheit im Zusammenhang mit REST gefunden habe, ist hier 1 Regentropfen.Die MySpace-APIs verwenden OAuth auch aus Sicherheitsgründen und Sie haben vollen Zugriff auf ihre benutzerdefinierten Kanäle im RestChess-Code, mit dem ich viel experimentiert habe.Dies wurde bei Mix vorgeführt und Sie können den Beitrag finden Hier.

Vielen Dank für die hervorragende Beratung.Am Ende haben wir einen benutzerdefinierten HTTP-Header verwendet, um ein Identitätstoken vom Client an den Dienst zu übergeben, als Vorbereitung für die Integration unserer RESTful-API in das kommende Zermatt Identity Framework von Microsoft.Ich habe das Problem beschrieben Hier und unsere Lösung Hier.Ich habe es auch genommen optimieren's Rat und gekauft RESTful-Webdienste – ein sehr gutes Buch, wenn Sie eine RESTful-API jeglicher Art erstellen.

OWASP (Open Web Application Security Project) verfügt über einige Spickzettel, die alle Aspekte der Webanwendungsentwicklung abdecken.Dieses Projekt ist eine sehr wertvolle und zuverlässige Informationsquelle.In Bezug auf REST-Dienste können Sie Folgendes überprüfen: https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

Ich würde OAuth 2/3 empfehlen.Weitere Informationen finden Sie unter http://oauth.net/2/

Ich habe viel über restful ws security recherchiert und am Ende haben wir auch ein Token per Cookie vom Client zum Server verwendet, um die Anfragen zu authentifizieren.Ich habe Spring Security für die Autorisierung von Anfragen im Dienst verwendet, weil ich jede Anfrage basierend auf festgelegten Sicherheitsrichtlinien, die bereits in der Datenbank vorhanden waren, authentifizieren und autorisieren musste.

Die Tatsache, dass die SOAP-Welt ziemlich gut mit Sicherheitsstandards abgedeckt ist, bedeutet nicht, dass sie standardmäßig sicher ist.An erster Stelle stehen die Standards sehr Komplex.Komplexität ist kein besonders guter Freund von Sicherheits- und Implementierungsschwachstellen wie z XML-Signatur-Wrapping-Angriffe sind hier endemisch.

Was die .NET-Umgebung betrifft, werde ich nicht viel helfen, aber „Webdienste mit Java erstellen“ (ein Baustein mit ~10 Autoren) hat mir geholfen eine Menge beim Verständnis der WS-*-Sicherheitsarchitektur und insbesondere ihrer Besonderheiten.

REST selbst bietet keine Sicherheitsstandards, aber Dinge wie OAuth und SAML werden in diesem Bereich schnell zu Standards.Authentifizierung und Autorisierung sind jedoch nur ein kleiner Teil dessen, was Sie berücksichtigen müssen.Viele der bekannten Schwachstellen im Zusammenhang mit Webanwendungen gelten vor allem für REST-APIs.Sie müssen Eingabevalidierung, Sitzungsknacken, unangemessene Fehlermeldungen, interne Schwachstellen von Mitarbeitern usw. berücksichtigen.Es ist ein großes Thema.

Ich möchte hinzufügen (im Einklang mit stinkeymatt): Die einfachste Lösung wäre, SSL-Zertifikate zu Ihrer Site hinzuzufügen.Mit anderen Worten: Stellen Sie sicher, dass Ihre URL HTTPS:// ist.Das deckt Ihre Transportsicherheit ab (ein Knallerpreis).Bei RESTful-URLs geht es darum, die Verwendung einfach zu halten (im Gegensatz zu WS*-Sicherheit/SAML). oAuth2/openID verbinden oder sogar Basic Auth (in einfachen Fällen).Sie benötigen jedoch weiterhin SSL/HTTPS.Bitte überprüfen Sie die ASP.NET Web API 2-Sicherheit hier: http://www.asp.net/web-api/overview/security (Artikel und Videos)

Als @Nathan schließlich herauskam, handelte es sich um einen einfachen HTTP-Header, und einige hatten gesagt, dass es sich um OAuth2- und clientseitige SSL-Zertifikate handelte.Der Kern davon ist Folgendes...Ihre REST-API sollte sich nicht um die Sicherheit kümmern müssen, da dies eigentlich außerhalb des Bereichs der API liegen sollte.

Stattdessen sollte eine Sicherheitsschicht darüber gelegt werden, sei es ein HTTP-Header hinter einem Web-Proxy (ein gängiger Ansatz wie SiteMinder, Zermatt oder sogar Apache HTTPd) oder so kompliziert wie OAuth 2.

Das Wichtigste ist, dass die Anfragen ohne jegliche Interaktion des Endbenutzers funktionieren sollten.Es muss lediglich sichergestellt werden, dass die Verbindung zur REST-API authentifiziert ist.In Java EE haben wir den Begriff a userPrincipal das kann auf einem erhalten werden HttpServletRequest.Im Bereitstellungsdeskriptor wird außerdem verwaltet, dass ein URL-Muster sicher sein kann, sodass der REST-API-Code keine Überprüfung mehr erfordert.

In der WCF-Welt würde ich verwenden ServiceSecurityContext.Current um den aktuellen Sicherheitskontext abzurufen.Sie müssen Ihre Anwendung so konfigurieren, dass eine Authentifizierung erforderlich ist.

Es gibt eine Ausnahme zu der Aussage, die ich oben gemacht habe, und zwar die Verwendung einer Nonce, um Wiederholungen zu verhindern (bei denen es sich um Angriffe handeln kann oder darum, dass jemand einfach dieselben Daten zweimal übermittelt).Dieser Teil kann nur in der Anwendungsschicht bearbeitet werden.

Für Web Application Security sollten Sie einen Blick auf OWASP werfen (https://www.owasp.org/index.php/Main_Page), das Cheatsheets für verschiedene Sicherheitsangriffe bereitstellt.Sie können so viele Maßnahmen wie möglich ergreifen, um Ihre Anwendung zu sichern.Bezüglich der API-Sicherheit (Autorisierung, Authentifizierung, Identitätsmanagement) gibt es wie bereits erwähnt mehrere Möglichkeiten (Basic, Digest und OAuth).Es gibt Lücken in OAuth1.0, sodass Sie OAuth1.0a verwenden können (OAuth2.0 wird aufgrund von Bedenken hinsichtlich der Spezifikation nicht weit verbreitet).

Es ist schon eine Weile her, aber die Frage ist immer noch relevant, auch wenn sich die Antwort möglicherweise etwas geändert hat.

Ein API-Gateway wäre eine flexible und hochgradig konfigurierbare Lösung.Ich habe es getestet und verwendet KONG ziemlich viel und mir hat wirklich gefallen, was ich gesehen habe.KONG bietet eine eigene Admin-REST-API, mit der Sie Benutzer verwalten können.

Express-gateway.io ist neueren Datums und ebenfalls ein API-Gateway.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow