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

Gibt es beim Entwerfen einer REST-API oder eines REST-Service bewährte Methoden für den Umgang mit Sicherheit (Authentifizierung, Autorisierung, Identitätsverwaltung)?

Beim Erstellen einer SOAP-API haben Sie WS-Security 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 Spezifikationen hat, die mit WS- * vergleichbar sind, hoffe ich, dass Best Practices oder empfohlene Muster entstanden sind.

Jede Diskussion oder Links zu relevanten Dokumenten wäre sehr dankbar. Wenn es darauf ankommt, würden wir WCF mit POX / JSON-serialisierten Nachrichten für unsere REST-APIs / -Dienste verwenden, die mit Version 3.5 von .NET Framework erstellt wurden.

Wie bereits erwähnt, ist Amazon S3 ein gutes Modell für die Arbeit. Ihre Anforderungssignaturen verfügen über einige Funktionen (z. B. das Einfügen eines Zeitstempels), die vor versehentlicher und böswilliger Wiedergabe von Anforderungen schützen.

Das Schöne an HTTP Basic ist, dass praktisch alle HTTP-Bibliotheken dies unterstützen. In diesem Fall müssen Sie natürlich SSL benötigen, da das Senden von Klartext-Passwörtern über das Internet fast überall eine schlechte Sache ist. Bei Verwendung von SSL ist Basic Digest vorzuziehen, da Digest, selbst wenn der Anrufer bereits weiß, dass Anmeldeinformationen erforderlich sind, einen zusätzlichen Roundtrip benötigt, um den Nonce-Wert auszutauschen. Mit Basic senden die Anrufer die Anmeldeinformationen einfach beim ersten Mal.

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

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

Zum Beispiel haben wir uns bei der Entwicklung unserer eigenen Ideen viele Ideen aus dem S3 REST-Service von Amazon geliehen. Wir haben uns jedoch dafür entschieden, das erweiterte Sicherheitsmodell, das auf Anforderungssignaturen basiert, nicht zu verwenden. Der einfachere Ansatz ist die HTTP-Basisauthentifizierung über SSL. Sie müssen entscheiden, was in Ihrer Situation am besten funktioniert.

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

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

Es ist dem Ansatz von flickr sehr ähnlich und erinnert sich an die Milch- Rest-Apis (nicht unbedingt gute Beispiele für erholsame Apis, aber gute Beispiele für den tokenbasierten Ansatz).

Auf Github gibt es eine großartige Checkliste :

Authentifizierung

• Erfinden Sie das Rad bei Authentifizierung, Token-Generierung und Kennwortspeicherung nicht neu. Verwenden Sie die Standards.

• Verwenden Max Retryund Gefängnisfunktionen in Login.

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

JWT (JSON Web Token)

• Verwenden Sie einen zufälligen komplizierten Schlüssel (JWT Secret), um das brutale Erzwingen des Tokens sehr schwer zu machen.

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

• Machen Sie den Token-Ablauf ( TTL, RTTL) so kurz wie möglich.

• Speichern Sie keine sensiblen Daten in der JWTNutzlast, sie können einfach dekodiert werden.

OAuth

• Überprüfen Sie immer redirect_uriserverseitig, um nur URLs auf der Whitelist zuzulassen.

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

• Verwenden Sie den Statusparameter mit einem zufälligen Hash, um CSRFden OAuthAuthentifizierungsprozess zu verhindern .

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

Zugriff

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

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

• Verwenden Sie einen HSTSHeader mit SSL, um einen SSL-Strip-Angriff zu vermeiden.

Eingang

• Verwenden Sie die richtige HTTP-Methode gemäß der Operation: GET(Lesen), POST(Erstellen), PUT/PATCH(Ersetzen / Aktualisieren) und DELETE(Löschen eines Datensatzes) und antworten Sie mit, 405 Method Not Allowedwenn die angeforderte Methode für die angeforderte Ressource nicht geeignet ist.

• Validate Content-Type auf Anfrage AcceptHeader (Content Negotiation), damit nur die unterstützten Format (zB application/xml, application/jsonusw.) und reagieren mit 406 Not AcceptableAntwort , wenn nicht abgestimmt.

• Validate content-typeder gebuchten Daten , wie Sie annehmen (zB application/x-www-form-urlencoded, multipart/form-data, application/jsonusw.).

• Überprüfen Sie die Benutzereingaben, um häufige Sicherheitslücken zu vermeiden (z. B. XSS, SQL-Injection, Remotecode Execution usw.).

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

• Verwenden Sie einen API-Gateway-Dienst, um das Caching und Rate LimitRichtlinien (z. B. Kontingent, Spike-Arrest, Limit für gleichzeitige Raten) zu aktivieren und API-Ressourcen dynamisch bereitzustellen.

wird bearbeitet

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

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

• Inkrementieren Sie IDs nicht automatisch. Verwenden Sie stattdessen UUID.

• Wenn Sie XML-Dateien analysieren, stellen Sie sicher, dass das Parsen von Entitäten 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 zum Hochladen von Dateien.

• 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 eine HTTP-Blockierung zu vermeiden.

• Vergessen Sie nicht, den DEBUG- Modus auszuschalten.

Ausgabe

• X-Content-Type-Options: nosniffHeader senden .

• X-Frame-Options: denyHeader senden .

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

• Entfernen von Fingerabdrücken headers - X-Powered-By, Server, X-AspNet-Versionusw.

• Erzwingen Sie content-typeIhre Antwort. Wenn Sie zurückkehren, application/jsonlautet Ihr Antwortinhaltstyp application/json.

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

• Geben Sie den richtigen Statuscode entsprechend dem abgeschlossenen Vorgang zurück. ( zum Beispiel 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, usw.).

Ich bin ein bisschen überrascht, dass SSL mit Client-Zertifikaten noch nicht erwähnt wurde. Zugegeben, dieser Ansatz ist nur dann wirklich nützlich, wenn Sie sich darauf verlassen können, dass die Benutzergemeinschaft durch Zertifikate identifiziert wird. Eine Reihe von Regierungen / Unternehmen geben sie jedoch an ihre Benutzer aus. Der Benutzer muss sich nicht um die Erstellung einer weiteren Kombination aus Benutzername und Kennwort kümmern. Die Identität wird bei jeder Verbindung festgelegt, sodass die Kommunikation mit dem Server vollständig zustandslos sein kann und keine Benutzersitzungen erforderlich sind. (Um nicht zu implizieren, dass einige / alle anderen genannten Lösungen Sitzungen erfordern)

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

Wenn es in Ihren REST-APIs / Webdiensten beispielsweise um das POSTEN / Abrufen von medizinischen Unterlagen geht, möchten Sie möglicherweise eine Zugriffssteuerungsrichtlinie definieren, wer unter welchen Umständen auf die Daten zugreifen kann. Zum Beispiel:

• Ärzte können die Krankenakte eines Patienten abrufen, mit dem sie eine Pflegebeziehung haben
• Niemand kann medizinische Daten außerhalb der Übungsstunden veröffentlichen (z. B. 9 bis 5).
• Endbenutzer können Krankenakten, die sie besitzen, oder Krankenakten von Patienten erhalten, für die sie der Vormund sind
• Krankenschwestern können die Krankenakte eines Patienten aktualisieren, der zur gleichen Einheit wie die Krankenschwester gehört.

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

Die anderen Standards hier sind für die folgenden:

• OAuth: id. Föderation und Delegation von Autorisierungen, z. B. einen Dienst in meinem Namen für einen anderen Dienst handeln 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 Messaging-Format (SOAP) auf Anwendungsebene und befassen sich mit Aspekten des Messaging, z. B. Zuverlässigkeit, Sicherheit, Vertraulichkeit, Integrität, Atomizität, Ereignisse ... Keine decken die Zugriffskontrolle ab und alle sind SOAP-spezifisch.

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

Folgendes sind interessante Ressourcen:

• die OASIS XACML- Website
• der NIST ABAC Standard

Ich habe OAuth einige Male verwendet und auch einige andere Methoden (BASIC / DIGEST). Ich schlage OAuth von ganzem Herzen vor. 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 in Bezug auf Sicherheit in Bezug auf REST gesehen habe, ist bei 1 RainDrop vorbei . 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 recherchiert habe. Dies wurde bei Mix vorgeführt und Sie können das Posting hier finden .

Danke für den exzellenten Rat. Wir haben schließlich einen benutzerdefinierten HTTP-Header verwendet, um ein Identitätstoken vom Client an den Service zu übergeben, um die Integration unserer RESTful-API in das kommende Zermatt Identity-Framework von Microsoft vorzubereiten. Ich habe das Problem hier und unsere Lösung hier beschrieben . Ich habe auch den Rat von tweakt befolgt und RESTful Web Services gekauft - ein sehr gutes Buch, wenn Sie eine RESTful-API jeglicher Art erstellen .

OWASP (Open Web Application Security Project) enthält einige Spickzettel, die alle Aspekte der Entwicklung von Webanwendungen abdecken. Dieses Projekt ist eine sehr wertvolle und zuverlässige Informationsquelle. In Bezug auf REST-Services können Sie dies ü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 nach erholsamer ws-Sicherheit gesucht und am Ende haben wir auch Token per Cookie vom Client zum Server verwendet, um die Anforderungen zu authentifizieren. Ich habe Spring Security für die Autorisierung von Anforderungen im Dienst verwendet, da ich jede Anforderung basierend auf festgelegten Sicherheitsrichtlinien, die bereits in DB 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. Erstens sind die Standards sehr komplex. Komplexität ist kein guter Freund von Sicherheits- und Implementierungsschwachstellen wie XML-Signatur-Wrapping-Angriffen .

In Bezug auf die .NET-Umgebung werde ich nicht viel helfen, aber „Erstellen von Webdiensten mit Java“ (ein Baustein mit ~ 10 Autoren) hat mir sehr geholfen , die WS- * -Sicherheitsarchitektur und insbesondere ihre Macken zu verstehen.

REST selbst bietet keine Sicherheitsstandards, aber Dinge wie OAuth und SAML werden schnell zu Standards in diesem Bereich. Authentifizierung und Autorisierung sind jedoch nur ein kleiner Teil dessen, was Sie berücksichtigen müssen. Viele der bekannten Sicherheitslücken in Bezug auf Webanwendungen gelten sehr stark für REST-APIs. Sie müssen die Überprüfung von Eingaben, das Knacken von Sitzungen, unangemessene Fehlermeldungen, interne Sicherheitslücken von Mitarbeitern usw. berücksichtigen. Es ist ein großes Thema.

Ich möchte hinzufügen (in Übereinstimmung mit stinkeymatt), die einfachste Lösung wäre, Ihrer Site SSL-Zertifikate hinzuzufügen. Mit anderen Worten, stellen Sie sicher, dass Ihre URL HTTPS: // lautet. Das wird Ihre Transportsicherheit abdecken (Bang for the Buck). Mit RESTful- URLs sollten Sie es einfach halten (im Gegensatz zu WS * security / SAML). Sie können oAuth2 / openID connect oder sogar Basic Auth (in einfachen Fällen) verwenden. Sie benötigen jedoch weiterhin SSL / HTTPS. Überprüfen Sie die Sicherheit von ASP.NET Web API 2 hier: http://www.asp.net/web-api/overview/security (Artikel und Videos)

Als @Nathan endete, ist dies ein einfacher HTTP-Header, und einige hatten OAuth2- und clientseitige SSL-Zertifikate angegeben. Der Kern davon ist Folgendes: Ihre REST-API sollte nicht mit Sicherheit umgehen müssen, da dies wirklich außerhalb des Bereichs der API liegen sollte.

Stattdessen sollte eine Sicherheitsschicht darüber gelegt werden, unabhängig davon, ob es sich um einen HTTP-Header hinter einem Webproxy handelt (ein gängiger Ansatz wie SiteMinder, Zermatt oder sogar Apache HTTPd) oder so kompliziert wie OAuth 2.

Der Schlüssel ist, dass die Anforderungen ohne Interaktion mit dem Endbenutzer funktionieren sollten. Sie müssen lediglich sicherstellen, dass die Verbindung zur REST-API authentifiziert ist. In Java EE haben wir den Begriff a userPrincipal, der auf einem erhalten werden kann HttpServletRequest. Im Deployment-Deskriptor wird auch verwaltet, dass ein URL-Muster sicher sein kann, sodass der REST-API-Code nicht mehr überprüft werden muss.

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 von der Aussage, die ich oben hatte, und das ist die Verwendung eines Nonce, um Wiederholungen zu verhindern (dies können Angriffe sein oder jemand, der nur zweimal dieselben Daten übermittelt). Dieser Teil kann nur in der Anwendungsschicht behandelt werden.

Für die Sicherheit von Webanwendungen sollten Sie sich OWASP ( https://www.owasp.org/index.php/Main_Page ) ansehen, das Cheatsheets für verschiedene Sicherheitsangriffe bereitstellt. Sie können so viele Maßnahmen wie möglich ergreifen, um Ihre Anwendung zu sichern. In Bezug auf die API-Sicherheit (Autorisierung, Authentifizierung, Identitätsverwaltung) gibt es, wie bereits erwähnt, mehrere Möglichkeiten (Basic, Digest und OAuth). In OAuth1.0 gibt es Lücken, sodass Sie OAuth1.0a verwenden können (OAuth2.0 wird aufgrund von Bedenken hinsichtlich der Spezifikation nicht häufig übernommen).

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

Ein API-Gateway wäre eine flexible und hoch konfigurierbare Lösung. Ich habe KONG ziemlich oft getestet und benutzt und mochte wirklich, was ich sah. KONG bietet eine eigene Admin-REST-API, mit der Sie Benutzer verwalten können.

Express-gateway.io ist neuer und auch ein API-Gateway.