Suchen
Inside Wiki
Nützliche Links




 
phpforum.de bei Facebook
 
phpforum.de bei Twitter
 

Zurück   PHP Forum: phpforum.de > phpforum.de Wiki > phpforum.de Wiki

PHP Wiki Dieses Wiki sammelt Lösungen, zu Problemen, welche immer wieder im Forum auftauchen.

 
 
Artikel-Optionen Ansicht
  #1  

Standard HTTP Response Splitting

 
 

Sicherheit - Inhalte

Einführung


HTTP Response Splitting ist nicht unbedingt das bekannteste Sicherheitsproblem, dennoch ist die Gefahr, die davon ausgeht nicht zu vernachlässigen. Die Gefahr geht davon nicht von PHP selbst aus, seit der Version 4.4.2 bzw. 5.1.2 sind sämtliche Lücken geschlossen. Vielmehr muss man sich um die Sicherheit seiner Scripte kümmern.

Was ist das


Dabei handelt es sich um Einschleusen von HTTP Headern in die Antwort des Servers. Mitunter ist dann Cross-Site-Scripting (XSS) und Phishing möglich. Die Problematik soll anhand eines Beispiel-Scripts erläutert werden.

Ein Beispiel für ein anfälliges Script


Die HTTP Header der Antwort lassen sich in PHP mit der Funktion
DOKU-VORLESE-SERVICE(TM)
void header(string string[, bool replace = true][, int http_response_code])
Send a raw HTTP header
beeinflussen, folglich ist bei der Verwendung dieser Funktion Vorsicht geboten, zumindest dann wenn man Usereingaben verwertet. Zur Veranschaulichung wollen wir ein typisches "Redirect"-Script hernehmen. Hierbei leitet man über ein Script auf eine bestimmte Seite um. Die Seite wird vom Benutzer bestimmt. Denkbar ist eine Umleitung über das Anhängen des Ziel-URLs an den eigentlichen Script-Url. Ein solches Script sähe in etwa so aus:
PHP Quellcode:
header('Location: ' . $_GET['url']);

Ganz bewusst wird auf etwaige Überprüfungen verzichtet. In der Praxis sollte man natürlich durchaus überprüfen, ob überhaupt dieser Parameter gesetzt ist. Nun können wir über einen Aufruf auf einen Ziel-URL umleiten. Ein solche Aufruf könnte so aussehen: script.php?url=http%3A%2F%2Fwww.example.com3%2F. Die URL muss natürlich entsprechende kodiert sein, so wie es hier der Fall ist.

Nun mag man sich fragen, wo die Sicherheitslücke liegt. Und wie so oft, ist es die fehlende Überprüfung der Benutzereingaben. Dieser kann hier nämlich weitere HTTP Header setzen. Alles was er dazu tun muss, ist es, die gewollten HTTP Header URL-kodiert anzuhängen.

Nun kann der Benutzer das Script auch so aufrufen: script.php?url=http%3A%2F%2Fwww.example.com%2F%0AS et-Cookie%3A+example%3D. Sieht man sich das ganze URL-dekodiert an (es soll auch Leute geben, die das auf den ersten Blick können ), so verschickt der Server nun folgende Antwort an den Client:
Code:
Location: http://www.example.com/
Set-Cookie: example=

Jeder der ein wenig Ahnung vom HTTP Protokoll hat, der sieht, dass man ein Cookie beim Benutzer gesetzt hat. Weil man sämtliche HTTP Header setzen kann, beschränkt es sich nicht nur auf das Setzen von Cookies. Auf weitere Beispiele soll verzichtet werden, es sollte nur der Sinn für diese Art von Sicherheitsbedenken geschärft werden.

Schutzmaßnahmen


Da das HTTP Protokoll recht strikte Vorstellung hat, ist eine Lösung sehr einfach. Header müssen jeweils in einer eigenen Zeile stehen, ansonsten werden sie vom Browser nicht (richtig) interpretiert. Das einfachste ist es also die Newline-Kontrollzeichen unschädlich zu machen. Mit der
DOKU-VORLESE-SERVICE(TM)
mixed str_replace(mixed search, mixed replace, mixed subject[, int count])
Replace all occurrences of the search string with the replacement string
Funktion ist das kein Problem. Unser stark vereinfachtes Script sähe dann also so aus:
PHP Quellcode:
header('Location: ' . str_replace(array("\r","\n"),'',$_GET['url']));

Auch hier wurde keinerlei Rücksicht auf etwaige Überprüfungen gemacht.

Es mag nicht die schönste, aber eine durchaus wirkungsvolle Methode sein.

Achtung: Auch wenn die Funktion nl2br() ein ähnliches Ziel verfolgt, macht sie doch nicht dasselbe, da Zeilenumbrüche dort nur um HTML-BR-Tags ergänzt, nicht aber aus dem Inhalt entfernt werden.

Man kann sich natürlich auch Gedanken darüber machen, wie man diese Zeichen schöner unschädlich macht. Eine Alternative zur etwas genaueren Überprüfung des formalen Aussehens der Eingangs-URL könnte dann z.B. so aussehen:

PHP Quellcode:
// überprüft ob der Inhalt wie eine gültige URL aussieht:
$url = filter_input(INPUT_GET, 'url', FILTER_VALIDATE_URL);
// hier koennen die erlaubten Protokolle eingeschraenkt werden:
$protokolle = array('http', 'https', 'ftp');
if ($url && in_array(parse_url($url, PHP_URL_SCHEME), $protokolle)) {
    header("Location: $url");
    exit;
}
// hier kommen wir nur im Fall eines Fehlers hin
die('Ungültige URL erhalten. Weiterleitung verweigert');


Quellen


HTTP response splitting, Wikipedia
PHP 5 ChangeLog, offizielles PHP 5 ChangeLog

Sicherheit
  Nächstes Kapitel »

Erstellt von johnpatcher, 19.01.2008 am 22:42
Zuletzt bearbeitet von combie, 27.11.2010 am 10:39
11 Kommentare , 10243 Betrachtungen

Dieser Text steht unter der GNU-Lizenz für freie Dokumentation


 

Lesezeichen

Artikel-Optionen
Ansicht

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.

Gehe zu
Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
http request / response Lord Weirdo PHP 3 10.08.2007 15:46
HTTP Response in neuem Fenster öffnen Denim PHP 4 16.02.2007 21:33
im IIS auf HTTP request & response header zugreifen SirSydom PHP 2 12.12.2005 15:24
String splitting... compy PHP 2 04.06.2003 22:34
HTTP Response nerv PHP 0 01.01.1970 02:00


Alle Zeitangaben in WEZ +2. Es ist jetzt 18:59 Uhr.


Powered by vBulletin® Version 3.8.8 (Deutsch)
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Powered by NuWiki v1.3 RC1 Copyright ©2006-2007, NuHit, LLC