Zum Hauptinhalt springen

6. Sicherheitserwägungen

6. Sicherheitserwägungen​

Anwendungen, die HTTP verwenden, müssen Sicherheit sorgfältig berücksichtigen. Dieser Abschnitt hebt einige wichtige Sicherheitserwägungen hervor; siehe auch [HTTP] Abschnitt 17.

Anwendungen SOLLTEN TLS [RFC8446] für alle Kommunikation verwenden. Insbesondere MÜSSEN Anwendungen TLS verwenden, wenn sie sensible Informationen wie Authentifizierungsdaten oder personenbezogene Daten übertragen. Siehe [RFC7258] für weitere Informationen über die Notwendigkeit allgegenwärtiger Verschlüsselung.

Anwendungen SOLLTEN das "https" URI-Schema anstelle von "http" verwenden, um sicherzustellen, dass TLS verwendet wird. Wenn TLS verwendet wird, SOLLTEN Anwendungen die aktuellen Best Practices befolgen, einschließlich:

  • Verwendung von TLS 1.3 [RFC8446] oder höher.

  • Validierung von Server-Zertifikaten.

  • Verwendung geeigneter Cipher-Suites.

  • Erwägung der Verwendung von HTTP Strict Transport Security (HSTS) [RFC6797], um sicherzustellen, dass Browser immer HTTPS verwenden.

Anwendungen müssen sich verschiedener webbasierter Angriffe und deren Abwehr bewusst sein:

  • Cross-Site Scripting (XSS): Wenn eine Anwendung Inhalte zurückgibt, die von einem Browser als HTML oder JavaScript interpretiert werden können, muss sie diese Inhalte ordnungsgemäß maskieren oder bereinigen, um XSS-Angriffe zu verhindern. Die geeignete Verwendung von Content-Type und das Setzen von Content-Security-Policy [CSP] Headern können helfen.

  • Cross-Site Request Forgery (CSRF): Anwendungen, die einen Zustand aufrechterhalten (z. B. unter Verwendung von Cookies), müssen sich vor CSRF-Angriffen schützen, bei denen eine bösartige Website den Browser eines Benutzers dazu bringt, Anfragen an die Anwendung zu stellen. Gängige Gegenmaßnahmen umfassen die Verwendung von CSRF-Token und die Überprüfung der Header-Felder Origin oder Referer.

  • Injection-Angriffe: Anwendungen, die Benutzereingaben in Abfragen, Befehle oder andere strukturierte Daten einbinden, müssen diese Eingaben ordnungsgemäß validieren und bereinigen, um Injection-Angriffe (z. B. SQL-Injection) zu verhindern.

  • Informationsoffenlegung: Anwendungen müssen vorsichtig sein, welche Informationen sie in Fehlermeldungen, Header-Feldern und anderen Antworten enthalten. Detaillierte Fehlermeldungen können Angreifern helfen, die Interna der Anwendung zu verstehen.

Anwendungen SOLLTEN die Sicherheitsauswirkungen von Caching berücksichtigen. Insbesondere:

  • Sensible Informationen SOLLTEN NICHT gecacht werden, oder wenn sie gecacht werden müssen, sollten sie nur privat gecacht werden (unter Verwendung von Cache-Control: private).

  • Authentifizierungsdaten SOLLTEN NICHT in URLs enthalten sein, da sie möglicherweise protokolliert oder gecacht werden.

Anwendungen, die Authentifizierung verwenden, müssen Folgendes berücksichtigen:

  • Wie Authentifizierungsdaten übertragen werden (sie sollten durch TLS geschützt werden).

  • Wie lange Authentifizierungssitzungen dauern und wie sie widerrufen werden können.

  • Wie man sich vor Brute-Force-Angriffen auf die Authentifizierung schützt.

  • Ob Multi-Faktor-Authentifizierung angemessen ist.

Anwendungen SOLLTEN sich bewusst sein, dass Clients und Server möglicherweise nicht unter der Kontrolle der Anwendungsentwickler stehen. Insbesondere:

  • Vermittler (Proxies, CDNs usw.) können Anfragen und Antworten cachen, protokollieren oder ändern.

  • Clients können bösartig oder kompromittiert sein.

  • Server können kompromittiert sein.

Anwendungen SOLLTEN daher:

  • End-to-End-Verschlüsselung und -Authentifizierung verwenden, wo angemessen.

  • Sich nicht ausschließlich auf Transportschicht-Sicherheit für sensible Operationen verlassen.

  • Alle Eingaben von Clients validieren.

  • Sich des Prinzips der geringsten Berechtigung bewusst sein und Clients oder Servern nicht mehr Zugriff geben als notwendig.

Anwendungen, die es Benutzern ermöglichen, Inhalte hochzuladen oder Code auszuführen, müssen äußerst vorsichtig mit Sandboxing und Isolation sein. Sogar scheinbar harmlose Funktionen können missbraucht werden:

  • Datei-Uploads können bösartige Inhalte enthalten, die Schwachstellen in Parsern oder Viewern ausnutzen könnten.

  • Benutzergesteuerte URLs können für Server-Side Request Forgery (SSRF) Angriffe verwendet werden.

  • Funktionen, die benutzerbereitgestellten Code ausführen (z. B. JavaScript in einem Browser-Kontext), erfordern starke Isolation.

Anwendungen, die von Webbrowsern aus zugänglich sind, müssen besonders vorsichtig sein, da Browser ein komplexes Sicherheitsmodell mit vielen potenziellen Fallstricken haben. Anwendungen SOLLTEN:

  • Geeignete Content-Security-Policy Header [CSP] verwenden, um einzuschränken, was Browser tun können.

  • Geeignete CORS-Richtlinien [FETCH] verwenden, um Cross-Origin-Zugriff zu kontrollieren.

  • Cookies mit geeigneten Flags (Secure, HttpOnly, SameSite) setzen.

  • Erwägen, X-Frame-Options oder CSPs frame-ancestors Direktive zu verwenden, um Clickjacking zu verhindern.

  • Sich browserspezifischen Verhaltens wie Prefetching, DNS-Prefetching und Preconnecting bewusst sein.

  • Erwägen, Subresource Integrity (SRI) zu verwenden, um sicherzustellen, dass extern gehostete Ressourcen nicht manipuliert wurden.

Anwendungen SOLLTEN sich bewusst sein, dass HTTP-Funktionen manchmal missbraucht werden können:

  • Weiterleitungen können für Phishing oder zur Umgehung von Sicherheitskontrollen verwendet werden.

  • Große Anfragen oder Antworten können für Denial-of-Service-Angriffe verwendet werden.

  • Komplexes Parsen von Header-Feldern oder Inhalten kann zu Schwachstellen führen.

Schließlich SOLLTEN Anwendungen eine klare Sicherheitsrichtlinie haben und von Anfang an mit Blick auf Sicherheit entworfen werden. Sicherheit sollte keine nachträgliche Überlegung sein.

Letztes Update am