HTTP response splitting

HTTP response splitting je v informatice druh zranitelnosti webové aplikace spočívající v nesprávné kontrole vstupů od uživatele. Cílem útočníka je předat webové aplikaci takové vstupy, aby došlo k rozdělení původní odpovědi serveru na více odpovědí, které může následně využít k vykonání dalších útoků (např. Cross-User Defacement, Cache poisoning, Cross-site scripting či Page Hijacking).

Popis zranitelnosti

Zranitelnost spočívá v tom, že útočník vkládá do webové aplikace společně se vstupem také neočekávaný řetězec. Předpokládejme, že cílová aplikace nefiltruje ze vstupů znaky CR a LF. Pomocí těchto znaků útočník manipulovat s odpovědí a dává mu tak fakticky nástroj k ovlivnění zbytku nejen hlavičky a těla zprávy, ale také k vytvoření dalších odpovědí zcela pod jeho kontrolou. Je však důležité dodržet strukturu http odpovědi. Tedy dodržet prázdné řádky (znaky CR a LF zakódované jako %0d%0a), kterými je oddělena hlavička od těla. A dále také mezery zakódované jako %20. Požadavky na aplikaci k úspěšnému provedení útoku jsou dva:

1. musí docházet k přesměrování zdrojů
2. aplikace nesmí filtrovat ze vstupu znaky CR a LF

Příklad zranitelné aplikace

V tomto příkladu programátor aplikace chce přesměrovat uživatele na stránku podle hodnoty vstupní proměnné strana. Ta může být nastavena například pomocí kliknutí na odkaz, čímž se zavolá redirect.php?strana=neco.php.

Při tomto volání dojde k vygenerování dvou odpovědí. První je odpověď se stavovým kódem 302 Moved Temporarily a druhá již má obsah stránky foobar.php a stavový kód 200 OK.

 <?php
   header ("Location: " . $_GET['strana']);
 ?>

Analýza webové aplikace

Předpokladem je, že aplikace přebírá jeden vstupní parametr a přesměrovává požadavek na jiný zdroj.

1. Nastavení proxy serveru, např. WebScarab od organizace OWASP, na zachytávání požadavků i odpovědí. Případně lze využít plugin pro úpravu dat přenášených protokolem HTTP (např. Tamper Data), avšak v tomto případě nelze zachytávat i odpovědi.
2. Odeslání nějaké hodnoty. V proxy lze zjistit, že je odeslán požadavek, aplikace zdroj přesměruje (http stavový kód 302) a nakonec přichází odpověď (http stavový kód 200).
3. Pokud je jako parametr odeslán foobar%0d%0a (cílová platforma je Microsoft Windows), tak server vrátí též dvě odpovědi. První se stavovým kódem 302 Moved Moved Temporarily (předpoklad) a druhou se stavovým kódem 200 OK, která obsahuje dokument.

Nedochází tedy k žádné změně oproti validnímu požadavku a s nejvyšší pravděpodobností nejsou v aplikaci mechanismy k filtrování vstupů. Pokud cílová aplikace běží na operačních systémech na bázi Unixu, tak je nutné nahradit znaky %0d%0a za znak %0a.

Obrana

Aby byla webová aplikace zabezpečena před útoky postavenými na HTTP Response Splitting je nutné ze všech uživatelských vstupů filtrovat znaky CR, LF a to v různých formách kódování před tím, než jsou použity při jakémkoliv generování hlaviček.

Související články

• Hypertext Transfer Protocol
• Cross-User Defacement
• Cache poisoning

Externí odkazy

• http://deadlytechnology.com/web-development/http-attack/ Archivováno 21. 11. 2010 na Wayback Machine. – HTTP Cache Poisoning on Deadly Technology (anglicky)
• http://www.owasp.org/index.php/HTTP_Response_Splitting] – HTTP Response Splitting na OWASP (anglicky)
• http://www.owasp.org/index.php/Cache_Poisoning – Cache Poisoning na OWASP (anglicky)
• http://yehg.net/lab/pr0js/training/webgoat.php – Řešení lekcí WebGoat (anglicky)