REST ist eine äußerst beliebte Webanwendungsarchitektur. Zum Aufrufen von Funktionen auf dem Server werden normale HTTP-Anforderungen mit angegebenen Parametern verwendet (JSON oder XML werden normalerweise zum Strukturieren von Parametern verwendet), und es gibt keinen strengen Standard für die REST-Architektur, der Flexibilität (und natürlich ein bisschen Chaos) bietet.
Mit REST können Sie sich dem Thema Sicherheit flexibel nähern oder sich, wie viele andere Sünden, der Frage überhaupt nicht nähern. Basierend auf
OWASP haben wir eine Liste mit Tipps zusammengestellt, mit denen Sie die Sicherheit Ihrer REST-Anwendung verbessern können.
Als Ausgangspunkt in den seltenen Fällen, in denen es hier benötigt wird, verwenden wir Python und Django.
Regel 0
Https
Einfach einrichten. Bitte. Der Schutz der übermittelten Daten hat niemandem geschadet. Selbst wenn Sie der Meinung sind, dass im Moment nichts zu schützen ist, ist dies nicht immer der Fall und Sie müssen HTTPS dennoch konfigurieren. Konfigurieren Sie es also sofort besser, und allen wird es gut gehen.
Regel 1
Authentifizierung
Es scheint ein offensichtlicher Rat zu sein, den viele jedoch lieber vernachlässigen. Die Anwendung sollte immer authentifiziert sein, auch wenn Sie jetzt glauben, dass Sie sie nur innerhalb des Unternehmens verwenden werden und es keinen Unterschied gibt, welcher der Mitarbeiter dies tut. Und wenn Sie mit Magazinen mehr hinzufügen, wird die Untersuchung von Vorfällen und die Analyse von Aktivitäten unvergleichlich einfacher.
Als Zugriffstoken wird derzeit die Verwendung von
JWT (JSON-Web-Token) als bewährte Methode angesehen. Verwenden Sie keine Token mit dem Wert {"alg": "none"} zur Integritätskontrolle. Token sollten immer eine Signatur oder einen MAC enthalten! Eine Signatur ist vorzuziehen, da die Generierungs- und Verifizierungsschlüssel des MAC übereinstimmen (oder leicht voneinander berechnet werden können). Wenn der Server also den MAC-Wert überprüfen kann, kann er auch seine Werte generieren. Die Signatur bestätigt nicht nur die Integrität der Nachricht, sondern auch die Identität des Absenders.
Regel 2
Verweigern Sie nicht verwendete HTTP-Methoden
Konfigurieren Sie den Server so, dass die Methoden, mit denen Sie arbeiten (GET, POST, PUT usw.), auf die Whitelist gesetzt werden, und lehnen Sie alles ab, was nicht in diese Liste passt. Es ist unwahrscheinlich, dass Ihr Server TRACE-Anforderungen bei der Produktion verarbeiten muss (diese Methode ist Teil des XST-Angriffs (Cross-Site Tracing), der aus einem XSS-Angriff und der TRACE- oder TRACK-Methode besteht. Mit diesem Angriff können beispielsweise die Cookies des Benutzers gestohlen werden, auch wenn Sie sind als HttpOnly gekennzeichnet. Je weniger Informationen über Ihre Infrastruktur von außen verfügbar sind, desto besser.
Regel 3
Differenzieren Sie den Zugang
Benötigen alle Ihre Benutzer alle Methoden, z. B. LÖSCHEN? Wenn Sie nicht möchten, dass einige Benutzer bestimmte Vorgänge ausführen können, konfigurieren Sie die Zugriffssteuerung in Ihrer Anwendung. Beispielsweise kann ein normaler Benutzer für einige Funktionen nur auf die GET-Methode zugreifen, der Manager kann GET und POST usw. verwenden. Hierzu lohnt es sich, Rollen in der Datenbank festzulegen, die Benutzern für eine bequeme Zugriffssteuerung zugewiesen werden können.
Infolgedessen verfügt jede Funktion über einen Prüfblock von ungefähr diesem Typ:
if request.POST and user.is_manager: do_stuff()
Regel 4
Denken Sie daran, die Anzahl der Abfragen zu begrenzen
Wenn Sie der Meinung sind, dass Ihre Benutzer Ihnen nicht hunderttausend Anfragen pro Sekunde senden sollten, sollten Sie diese Anzahl begrenzen. Verwenden Sie API-Schlüssel oder einen anderen für Sie geeigneten Mechanismus, um die Anzahl der Anforderungen zu verfolgen und zu begrenzen, die in einem bestimmten Zeitraum von einem Benutzer verarbeitet werden. Für Django bietet django-ratelimit beispielsweise diese Funktionalität, bei der Sie verschiedene Parameter als Kennung für die Einschränkung festlegen können, nicht unbedingt API-Schlüssel, sondern eine IP-Adresse.
Regel 5
Stellen Sie sicher, dass Sie die Eingabe validieren / bereinigen
Vertrauen Sie niemals den übertragenen Eingabeparametern, führen Sie immer eine Validierung / Hygiene durch:
- Wenn möglich (und wo möglich), legen Sie eine Grenze für die Länge / den Typ / das Format der Eingabe und der Anforderung selbst fest. Alle Anfragen / übertragenen Daten ablehnen, die die von Ihnen angegebene Länge überschreiten oder nicht dem Typ / Format entsprechen.
- Vermeiden Sie bei der Verarbeitung von Zeichenfolgen immer alle Sonderzeichen.
- Wenn Sie das Framework verwenden, enthalten die meisten von ihnen ihre eigenen integrierten Validierungs- und Hygienetools (neben den gängigen - Django (Python) und Yii2 (PHP)). Daher ist es wichtig, ihre Fähigkeiten zu untersuchen und zu prüfen, ob ein Aspekt, den Sie benötigen, nicht behandelt wird. Suchen Sie eine Bibliothek, die dies schließt, oder schreiben Sie diese Funktionen selbst.
- Verfolgen Sie Validierungsfehler. Wenn die Anforderungen einiger Benutzer die Validierung ständig nicht bestehen, sollten Sie diese Benutzer automatisch blockieren.
- Stellen Sie sicher, dass Ihr Eingabe-Parser (oder seine aktuelle Version) selbst keinen Angriffen ausgesetzt ist.
Regel 6
Geben Sie nicht mehr Informationen als nötig heraus
Wenn eine Anforderung einen Fehler in der Anwendung verursacht hat oder aus irgendeinem Grund einfach nicht verfügbar ist, geben Sie in der Antwort keine Details an und geben Sie die abstrakteste Fehlermeldung zurück. Einige Server geben nach einem Fehler standardmäßig Stacktrace zurück. Konfigurieren Sie diese Logik daher unbedingt neu.
Regel 7
Führen Sie immer Protokolle
Lassen Sie jedes Ereignis (Authentifizierung, Fehler, Anforderung usw.) so detailliert wie möglich protokollieren. Protokollieren Sie sie logisch, um sie bei Bedarf bequemer suchen zu können. Bereinigen Sie die aufgezeichneten Daten vor dem Aufzeichnen in den Protokollen.
Regel 8
Geben Sie den Inhaltstyp korrekt an - das ist wichtig!
Damit der Browser (oder Client) die bereitgestellten Daten korrekt lesen kann, ist der korrekt angegebene Inhaltstyp wichtig, der den bereitgestellten Daten entspricht. Bei Browsern lohnt es sich auch, den Header auf X-Content-Type-Options: nosniff zu setzen, um zu verhindern, dass der Browser versucht, einen anderen Content-Type als den tatsächlich gesendeten zu erkennen (eine Maßnahme gegen XSS-Angriffe).
Regel 9
Überprüfen Sie den Inhaltstyp
- Es lohnt sich, die Ablehnung von Anfragen einzurichten, wenn sich ihr Inhaltstyp von ihrem Inhalt unterscheidet. Dies verringert das Risiko einer fehlerhaften Datenverarbeitung, die zur Injektion oder Codeausführung auf dem Server / Client führen kann.
- Es lohnt sich auch, Anfragen abzulehnen, deren Inhaltstyp Sie nicht unterstützen oder für die dieser Header im Allgemeinen fehlt. Vermeiden Sie auch direkte Antworten darauf, welche Content-Type-Funktion akzeptiert / Probleme verursacht, wenn dies nicht erforderlich ist (dies hilft, XXE-Angriffe zu vermeiden).
- In REST-Diensten ist es üblich, verschiedene Arten von Antworten zu unterstützen (z. B. json und xml), und der Client gibt bei der Anforderung den bevorzugten Antworttyp im Accept-Header an. Vermeiden Sie es, den Inhalt des Accept-Headers in den Content-Type der Antwort zu kopieren, um diesen Header festzulegen. Lehnen Sie auch Anforderungen ab, für die der Accept-Header nicht mindestens einen der unterstützten Typen direkt enthält.
Regel 10
Vergessen Sie nicht, Cross-Origin Resource Sharing (CORS) einzurichten.
CORS ist ein Standard, der die Arbeit mit domänenübergreifenden Abfragen beschreibt. Wenn Ihre Anwendung CORS nicht unterstützt, deaktivieren Sie die Arbeit mit dieser Art von Headern. Wenn Sie es verwenden müssen, sollte die Zugriffsrichtlinie so spezifisch und streng wie möglich sein.
Regel 11
Erweitern Sie keine Parameter in der URL
Alle kritischen Daten (Passwörter, Schlüssel, Token und Anmeldungen, vorzugsweise auch) sollten sich im Anforderungshauptteil oder in den Kopfzeilen befinden, aber in keinem Fall in der URL erscheinen. Wenn Sie vertrauliche Daten über die GET-Methode übergeben müssen, fügen Sie sie in den Header ein.
Es ist unmöglich:Beispiel .com / controller / 123 / action? apiKey = a53f435643de32
Sie können:Beispiel .com / controller / 123 / action
Überschriften:Host: example.com
User-Agent: Mozilla ...
X-APIkey: a53f435643de32
Regel 12
Denken Sie an den Schutz vor CSRF-Angriffen
Weitere Informationen zu allen Arten von Schutz finden Sie
hier. Daher wird die Verwendung von CSRF-Token als die beliebteste Methode angesehen, um das Risiko von Angriffen dieser Art zu verringern.
Regel 13
Entdecken Sie Ihr Framework
Wenn Sie ein Framework verwenden, um REST in Ihrer Anwendung zu implementieren, sollten Sie es studieren und nicht blind verwenden, wie dies häufig der Fall ist. Lesen Sie die Dokumentation sorgfältig durch, insbesondere den Sicherheitsteil. Lassen Sie es nicht mit den Standardeinstellungen arbeiten! Jedes Framework hat seine eigenen Nuancen, insbesondere wenn es um Sicherheit geht. Daher ist es sehr wichtig, diese zu kennen.