it-swarm.com.de

Können wir gzip für Nicht-Token-Antworten verwenden, um BREACH zu vermeiden?

Ich arbeite an einer Site, die eine Webschnittstelle und eine API hat. Ich versuche festzustellen, ob wir gzip sicher verwenden können oder ob dies uns zu VERLETZUNG öffnen wird.

Die Seite sagt:

Wenn Sie einen HTTP-Antworttext haben, der all Die folgenden Bedingungen erfüllt, sind Sie möglicherweise anfällig:

  • Komprimierung: Ihre Seite wird mit aktivierter HTTP-Komprimierung (GZIP/DEFLATE) bereitgestellt.
  • Benutzerdaten: Ihre Seite spiegelt Benutzerdaten über Abfragezeichenfolgenparameter, POST, wider.
  • Ein Geheimnis: Ihre Anwendungsseite enthält PII, ein CSRF-Token, vertrauliche Daten ...

Eine andere Seite sagt:

Der Angreifer muss in der Lage sein, die Größe des verschlüsselten Datenverkehrs zu lesen und CSRF-Anforderungen nach Belieben auszuführen

Wir verwenden ein Webframework, das jedem Formular, das POST verwendet, automatisch ein maskiertes (jedes Mal anderes) CSRF-Token hinzufügt.

Wir haben Seiten (z. B. Suchergebnisse), die Benutzereingaben widerspiegeln, aber keine vertraulichen Daten enthalten (das zu suchende Formular verwendet GET).

Wir haben einen API-Endpunkt, der ein API-Token bereitstellt, der jedoch jedes Mal einen anderen Wert aufweist, da er kryptografisch mit einem Zeitstempel signiert ist.

Die meisten unserer Antworten sind große JSON-Stellen, die von gzip stark profitieren würden.

Können wir gzip überall einschalten? Reicht es aus, es auszuschalten, wenn Sie mit einem API-Token antworten ? Oder können wir einfach keine schönen Dinge haben?

11
Nathan Long

Ich beantworte meine eigene Frage, weil ich denke Ich verstehe jetzt BREACH und wie ich es verhindern kann. Ich würde mich über Feedback freuen.

Wie BREACH funktioniert (so wie ich es verstehe)

(Eine Erklärung erweitern hier das hat mir geholfen.)

Angenommen, Sie sind ein Angreifer. Sie sind als Sie selbst bei einem Dienst angemeldet. Sie bemerken, dass es einen search Endpunkt gibt, und wenn Sie den Suchbegriff rabbits senden, erhalten Sie eine Antwort wie folgt zurück:

<SearchResponse>
  <AuthToken>d2a372efa35aab29028c49d71f56789</AuthToken>
  <SearchTerm>rabbits</SearchTerm>
  <Results>
    <Result>rabbits rock</Result>
    <Result>yay rabbits</Result>
  </Results>
</SearchResponse>

Sie bemerken auch, dass die Antwort komprimiert und verschlüsselt ist (HTTPS).

Sie versuchen, nach einer Zeichenfolge zu suchen, die wie der Wert <AuthToken Formatiert ist, z. B. aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa. Die Antwort lautet:

<SearchResponse>
  <AuthToken>d2a372efa35aab29028c49d71f56789</AuthToken>
  <SearchTerm>aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa</SearchTerm>
  <Results>
  </Results>
</SearchResponse>

Hierfür liegen keine Ergebnisse vor. Anschließend ändern Sie Ihren Suchbegriff geringfügig:

<SearchResponse>
  <AuthToken>d2a372efa35aab29028c49d71f56789</AuthToken>
  <SearchTerm>d2a37aaaaaaaaaaaaaaaaaaaaaaaaaa</SearchTerm>
  <Results>
  </Results>
</SearchResponse>

Wie Sie gehofft haben, passiert etwas Interessantes. Da der Suchbegriff Unsinn ist, sind die <Results> Immer gleich: leer. Das einzige, was chagt, ist der <SearchTerm>. Und aufgrund der Komprimierung ist die Antwort umso kleiner, je mehr der Wert <SearchTerm> Dem Wert <AuthToken> Ähnelt.

Dies liegt an der Funktionsweise der gzip-Komprimierung: Sie entfernt Wiederholungen beim Komprimieren und stellt sie beim Dekomprimieren wieder her. Je sich die Eingabe wiederholt, desto kleiner wird sie komprimiert.

Sie suchen erneut mit dem genauen Wert von <AuthToken>.

<SearchResponse>
  <AuthToken>d2a372efa35aab29028c49d71f56789</AuthToken>
  <SearchTerm>d2a372efa35aab29028c49d71f56789</SearchTerm>
  <Results>
  </Results>
</SearchResponse>

Dieses Mal notieren Sie, wie klein die Antwort ist. Jetzt wissen Sie, dass jedes Mal, wenn die Antwort diese Größe hat, der Suchbegriff genau mit dem Authentifizierungstoken übereinstimmt .

Da dies Ihre Anfragen sind, konnten Sie sie direkt lesen. Wenn Sie einen MITM-Angriff auf einen anderen Benutzer der Site ausführen könnten (z. B. durch Ausführen eines Rogue-Routers), könnten Sie die Größe der verschlüsselten Antwort sehen, aber nicht die tatsächliche Inhalt.

Sie denken sich: Wenn ich jemand anderen dazu verleiten kann, die gewünschten Suchbegriffe zu senden, und wenn ich sehe, wie groß die verschlüsselte Antwort ist, kann ich den Suchbegriff immer wieder optimieren. Je näher ich dem Erraten des Authentifizierungstokens komme, desto kleiner wird die Antwort, und wenn es die Größe der Antwort ist, die ich gerade gesehen habe, habe ich richtig geraten. Sobald ich ihren Authentifizierungstoken kenne, kann ich mich als sie anmelden.

Wenn Sie einen XSS-Angriff auf Ihr Opfer ausführen können, können Sie es dazu bringen, die erforderlichen Anforderungen zu stellen.

Minderung

Dieser Angriff würde nicht funktionieren, wenn:

  • Der Server hat keine HTTP-Komprimierung verwendet (wie in unserem Beispiel gzip).
  • Die Anfrage konnte ohne ein CSRF-Token, das der Angreifer nicht kennen konnte, nicht erfolgreich gestellt werden
  • Der Server hat niemals sowohl sensible Daten (wie ein API-Token) als auch gespeichert. Vom Benutzer bereitgestellte Daten (wie der Suchbegriff) in derselben Antwort
  • Der Server hat nie zweimal dasselbe API-Token zurückgegeben (z. B. wenn Roh-Token-Werte vor dem Senden mit einem Zeitstempel versehen und signiert wurden, würde der Zeitstempel sicherstellen, dass sich das Token in der Antwort ständig ändert).
  • Die Antwort enthielt immer eine Auffüllung mit zufälliger Länge, wie @AndrolGenhald in einem Kommentar hervorhob (obwohl ein Angreifer bei ausreichenden Anforderungen das Signal von diesem Rauschen trennen könnte).
  • Die Anforderung konnte ohne ein Sitzungscookie nicht erfolgreich gestellt werden, und das Sitzungscookie der Site hatte ein SameSite -Attribut, und das potenzielle Opfer verwendete ein Browser, der dieses Attribut versteht , damit es Es wird davon ausgegangen, dass das Cookie nicht in Anfragen von einer anderen Site enthalten ist.
14
Nathan Long