Aus der Hölle der Internetprotokolle: Chunked Encoding

Aus der Hölle der Internetprotokolle: Chunked Encoding

Das grundlegende Protokoll im Internet ist das HTTP (Hypertext Transfer Protokol), welches 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 ...

In der 1996 standardisierten Version 1.0 des HTTP Protokolls wurde das Ende der Daten entweder durch das Ende der unterliegenden TCP-Verbindung bestimmt oder durch eine explizite Längenangabe im HTTP-Header (Content-Length). Bei vielen dynamisch generierten Inhalten ist jedoch die Länge vorab nicht bekannt und so wurde in der 1999 erschienenen Version 1.1 des HTTP Protokolls eine weitere Übertragungsart eingeführt: das „Transfer-Encoding chunked“.

Bei chunked Encoding wird der Inhalt in mehreren Datenblöcken übertragen und vor jedem dieser Blöcke (Chunks) die Länge als Hexadezimalzahl angegeben. Abgeschlossen wird das ganze mit einem Chunk von 0 Byte:

HTTP/1.1 200 ok
Transfer-Encoding: chunked

1B
Das sind 27 (Hex 1B) Bytes.
15
Gefolgt von 21 Bytes.
0

Was aber passiert, wenn wir chunked in Verbindung mit HTTP Version 1.0 benutzen? Da für diese Version noch kein chunked Encoding definiert war, sollte es eigentlich ignoriert werden:

HTTP/1.0 200 ok
Transfer-Encoding: chunked

5
HELLO
5
WORLD
0

Fast alle aktuellen Browser halten sich auch an den Standard, d. h. sie interpretieren den Inhalt nicht als chunked. Anders hingegen der Browser Safari sowie viele Firewalls, IDS oder Proxies. Diese schauen oftmals nicht auf die HTTP-Version, sondern sehen bloß Transfer-Encoding:chunked und behandeln den Inhalt entsprechend als chunked. Interessant wird es dann, wenn der Inhalt gar nicht chunked ist:

HTTP/1.0 200 ok
Transfer-Encoding: chunked
Content-length: 5

VIRUS

In diesem Falle lassen 30 Prozent der untersuchten Firewalls die Daten einfach durch. Das heißt, sie versuchen die Daten als chunked zu interpretieren und scheitern dabei. Statt aber nun aufgrund dieses Scheiterns die Daten zu blockieren, werden sie lieber durchgelassen. Das ist eine Vorgehensweise, die wir leider immer wieder beobachten: Bei Analyseproblemen werden die Daten typischerweise nicht blockiert, sondern durchgelassen.

In der High Resistance Firewall genugate behandeln wir diese Situation nicht nur entsprechend dem Standard, sondern sorgen darüber hinaus dafür, dass die zu schützenden Clients die Daten auf die gleiche korrekte Weise interpretieren. Dazu erlauben wir den Transfer-Encoding Header nur im Zusammenhang mit HTTP/1.1 Antworten, d. h. wir entfernen ihn aus einer HTTP/1.0 Antwort, bevor wir die Daten an den Client weiterleiten.

Weitere Informationen:

HTTP Evasions Explained - Part 3 - Chunked Transfer
Analysen des Autors von 2015, wie mit Variationen des chunked Encoding die Analyse in existierenden Firewalls umgangen werden kann.

 

Bildquelle: the_lightwriter - Fotolia.com


Lesen Sie auch

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.