Aus der Hölle der Internetprotokolle: Mehrfachkompression

Aus der Hölle der Internetprotokolle: Mehrfachkompression

Das grundlegende Protokoll im Internet ist das HTTP (Hypertext Transfer Protocol), das auf den ersten Blick recht einfach erscheint. Sieht man jedoch genauer hin, so fallen viele unklare oder widersprüchliche Details auf. Dort verbergen sich die Teufelchen, welche die zuverlässige Analyse von Datenverbindungen zur Hölle machen können.

Um die Datenübertragung zu optimieren, erlaubt HTTP die Kompression von Daten für den Transport. Typische, von allen Browsern unterstützte Kompressionsverfahren, sind das bekannte gzip sowie das verwandte deflate. Wenn ein Webserver die Daten für den Transport komprimiert hat, dann fügt er einen Content-Encoding Header in die Antwort ein. Eine derartige Antwort sieht zum Beispiel so aus:

HTTP/1.1 200 ok
Content-Encoding: gzip
Content-length: 100

... Daten, mit gzip komprimiert

Liest man den Standard aber genauer, so findet man die Teufelchen in den Details. Es ist nämlich durchaus erlaubt, mehrere Content-Encodings gleichzeitig zu benutzen, wie in diesem Beispiel zu sehen:

HTTP/1.1 200 ok
Content-Encoding: gzip
Content-Encoding: deflate
Content-length: 100

... Daten, zuerst mit gzip und dann mit deflate komprimiert

Da eine derartige Mehrfachkompression zumeist unsinnig ist, haben viele Entwickler dieser Stelle des Standards zu wenig Aufmerksamkeit gewidmet. Infolgedessen werten verschiedene Webbrowser die obige Antwort auf unterschiedliche Weise aus:

  • Doppelt komprimiert: Firefox, Chrome und Opera machen es wie vom Standard vorgesehen.
  • Einmal komprimiert: Apples Browser Safari benutzt nur den ersten Eintrag, sieht also die Daten als ausschließlich mit gzip komprimiert an.
  • Gar nicht komprimiert: Internet Explorer und Edge sind offensichtlich verwirrt und ignorieren beide Informationen. Sie nehmen daher an, dass der Inhalt gar nicht komprimiert wurde.

Eine Firewall muss in solchen Situationen abwägen, ob die Daten einen unbeabsichtigten (ungefährlichen) oder aber einen gezielten Fehler (Umgehungsversuch) aufweisen. Werden die Daten von der Firewall blockiert, so funktionieren eventuell einige Websites nicht mehr korrekt. Und natürlich ist dann die Firewall Schuld. Werden die Daten hingegen durchgelassen, erkennt die Firewall eventuell keine Gefahr, während durch die abweichende Interpretation im Browser Malware ausgeführt werden kann.

Derartige, gefährliche Interpretationsunterschiede kann man in der Praxis auch bei einigen freien, aber durchaus professionell genutzten Intrusion Detection Systemen (IDS) feststellen. So sieht Suricata in obiger Antwort analog zu Safari nur den ersten Eintrag, also gzip. Die IDS Snort und Bro sowie der bekannte Online-Scanner virustotal.com hingegen benutzen den letzten Eintrag und damit deflate. Damit interpretieren sie alle die Daten anders als die am meisten verbreiteten Webbrowser.

Die High Resistance Firewall genugate blockiert mehrfach komprimierte Daten

In unserem Firewall-Produkt genugate haben wir uns dafür entschieden, die Mehrfachkompression als Umgehungsversuch zu werten und aus Sicherheitsgründen zu blockieren. In anderen Fällen hingegen normalisieren wir die Daten und sorgen so dafür, dass alle zu schützenden Clients die Daten auf die gleiche Weise wie die Firewall interpretieren.

 

Weitere Informationen:

Lesen Sie auch: E-Mail-Codierung: Ich sehe was, was du nicht siehst ...

 

Bildquelle: ©iagodina - Fotolia.com


Diskutieren Sie mit

Sie können diesen Artikel sofort ohne Registrierung als Gast-User kommentieren.

Registrieren Sie sich jetzt! Mit einem User Account genießen Sie Vorteile:
Ihr Kommentar wird sofort im genublog veröffentlicht und Sie werden über Reaktionen auf Ihre Kommentare informiert.

Bereits registrierte User gelangen hier zum Login.



Registrieren Sie sich jetzt! Mit einem User Account genießen Sie Vorteile:
Ihr Kommentar wird sofort im genublog veröffentlicht und Sie werden über Reaktionen auf Ihre Kommentare informiert.

Bereits registrierte User gelangen hier zum Login.