EN

Wie man einen BREACH-Angriff verhindert

In diesem Artikel:

Ein Server, der für einen BREACH-Angriff (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) anfällig ist, ermöglicht es einem Angreifer, Cookie-Inhalte wie Sitzungsinformationen zu entschlüsseln. 

Erfahren Sie hier, wie Sie BREACH-Angriffe verhindern können.

BREACH-Angriff Sicherheitsbewertungsstufe

SSL BREACH Security Assessment Level

CVSS-Vector: AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

Informationen zur BREACH-Schwachstelle

er BREACH-Angriff kann als Instanz des CRIME-Angriffs (Compression Ratio Info-Leak Made Easy) betrachtet werden, da er auf dessen Logik basiert und ihr weitgehend folgt. Er zielt auf Schwachstellen bei der Datenkompression im HTTP-Protokoll ab.

Damit ein BREACH-Angriff erfolgreich ist, müssen mehrere Bedingungen erfüllt sein. Anfällige Websites müssen:

  • Komprimierung auf HTTP-Ebene verwenden
  • Benutzereingaben (z. B. einen Benutzernamen, der über ein Anmeldeformular eingegeben wird) in der HTTP-Antwort wiedergeben
  • ein Geheimnis (z. B. ein CSRF-Token) im Antwortkörper enthalten, das für den Angreifer von Interesse ist

Ein Server, der für BREACH-Angriffe anfällig ist, ermöglicht es einem Angreifer, Cookie-Inhalte wie Sitzungsinformationen, einschließlich Anmeldetoken, E-Mail-Adressen und andere Arten von sensiblen Daten zu entschlüsseln. 

Dieser Angriff kann in weniger als einer Minute erfolgreich durchgeführt werden.

Präventionsleitfaden für SSL/TLS-Schwachstellen

Leitfaden

Erfahren Sie, wie Sie verschiedene Arten von SSL/TLS-Schwachstellen erkennen und verhindern können.

Mehr erfahren

Wie man einen BREACH-Angriff verhindern kann

Im Gegensatz zu früheren Angriffen wie BEAST oder LUCKY13 erfordert dieser Angriff keine Komprimierung auf der SSL/TLS-Schicht und kann mit jeder Cipher-Suite durchgeführt werden. Aus diesem Grund hat das Ausschalten der TLS-Kompression keinen Einfluss auf die Möglichkeit eines BREACH-Angriffs.

Der Angriff lässt sich leichter gegen Streamchiffren durchführen, da die Größe der Antworten leichter zu ermitteln ist. Bei Blockchiffren müssen Angreifer jedoch daran arbeiten, die Ausgabe genauer auf die Chiffretextblöcke abzustimmen.

Technisch gesehen besteht die einfachste Form der Abwehr darin, die HTTP-Komprimierung zu deaktivieren, was zu größeren Seiten führt, die übertragen werden müssen, und keine praktikable Lösung darstellt. 

Es gibt mehrere Möglichkeiten, diesen Angriff zu entschärfen. Dazu gehören:

  • Deaktivierung der Komprimierung nur, wenn der Verweiser nicht die eigene Anwendung ist
  • Trennung aller sensiblen Daten (d. h. Geheimnisse) von den Benutzereingaben
  • Verwendung eines CSRF-Tokens zum Schutz von Seiten, die dank des SameSite Cookie-Attributs sensible Informationen enthalten
  • Verbergen der Länge des Datenverkehrs durch Einfügen einer zufälligen Anzahl von Bytes in die Antworten (auch bekannt als HTTP Chunked Encoding)
  • Zufallsgenerierung des Token-Wertes in jeder Antwort
  • Begrenzung der Anfragerate 
  • Überwachung des Datenverkehrs, um Angriffe zu erkennen, sobald sie auftreten

Apache

Um die HTTP-Komprimierung von Anfragen mit unterschiedlichen Referrern zu deaktivieren, verwenden Sie die folgenden Einstellungen:

SetOutputFilter DEFLATE
       BrowserMatch ^Mozilla/4 gzip-only-text/html
       BrowserMatch ^Mozilla/4\.0[678] no-gzip
       BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
       SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|zip|gz|tgz|htc)$ no-gzip dont-vary
       # BREACH migitation
       SetEnvIfNoCase Referer .* self_referer=no
       SetEnvIfNoCase Referer ^https://www\.example\.org/ self_referer=yes
       SetEnvIf self_referer ^no$ no-gzip
       Header append Vary User-Agent env=!dont-vary

Mögliche BREACH-Angriffslösungen

HSTS –  Sichere Kanäle: Strikte Transportsicherheit

Der Server deklariert „Ich spreche nur TLS“.

Beispiel: HTTP(S) Antwort-Header: Strict-Transport-Security: max-age=15768000; includeSubDomains

Der Header kann im Cache gespeichert werden und verhindert auch das Durchsickern von Subdomain-Inhalten durch Nicht-TLS-Links im Inhalt.

Schwachstelle: „Vertrauen bei der ersten Verwendung“

Zertifikatsanheftung

Server-Identitäten sind in der Regel langlebig, aber die Clients müssen die Identität des Servers bei jeder TLS-Sitzung neu aufbauen.

Wie könnte Google/Chrome dem DigiNotar-Angriff standhalten?

Google hat Fingerabdrücke für die bekannten öffentlichen Schlüssel in die Zertifikatsketten der Google-Eigenschaften eingebaut, die vorgeladen sind. Dadurch wird das falsche *.google.com-Zertifikat aufgedeckt, das DigiNotar signiert hat.

Aber das Vorladen ist nicht skalierbar, also brauchen wir etwas Dynamisches:

Man könnte einen HTTP-Header verwenden, d.h. den SHA1- oder SHA256-Hash der Subject Public Key Info-Struktur des X.509-Zertifikats übertragen. (Sie könnten den Endteilnehmer, den Vermittler oder die Wurzel festlegen. Wählen Sie Ihren Präzisionsgrad.)

Sichere Kanäle: DNSSEC für TLS

DNSSEC kann verwendet werden, um unterstützte Protokolle für Domains zu deklarieren.

DNSSEC kann verwendet werden, um ein Serverzertifikat für die Domäne zu deklarieren.

Vorteil: Vorteil der vertrauenswürdigen signierten Quelle.

Erhalten Sie jetzt kostenlos einen schnellen Sicherheitsbericht für Ihre Website

Wir analysieren derzeit https://example.com
Wir scannen derzeit https://example.com
Status des Scans: In Bearbeitung
Scan target: http://example.com/laskdlaksd/12lklkasldkasada.a
Datum: 06/12/2022
Crashtest Security Suite prüft auf:
Information disclosure Known vulnerabilities SSL misconfiguration Open ports
Scanauftrag ausfüllen
Bitte geben Sie Ihre Daten ein, um die schnelle Sicherheitsüberprüfung zu erhalten.
Ein Sicherheitsspezialist analysiert gerade Ihren Scan-Bericht.
Bitte geben Sie Ihre Telefon-/Handynummer an, damit wir Ihre Identität überprüfen können:
Vielen Dank.
Wir haben Ihren Antrag erhalten.
Sobald Ihr Sicherheitsaudit fertig ist, werden wir Sie benachrichtigen.