HTTP Response Splitting w google.com

Wstęp

Nim przejdę do tytułowej podatności, przypomnijmy sobie jak wygląda typowa odpowiedź HTTP. Weźmy na warsztat Sekuraka: po wpisaniu w przeglądarce adresu http://sekurak.pl/ przeglądarka wyśle zapytanie, na które serwer odpowie w sposób następujący:

• kod odpowiedzi w pierwszej linii (zaznaczony kolorem czerwonym),
• nagłówki odpowiedzi (kolor zielony),
• pusta linia,
• treść odpowiedzi (body).

Zgodnie ze specyfikacją protokołu, kod odpowiedzi oraz nagłówki powinny kończyć się bajtami <CR><LF> (inaczej „\r\n”, zakończenie linii w stylu windowsowym). Pusta linia składa się wyłącznie zna znaków <CR><LF>.

Czym jest response splitting?

Wyobraźmy sobie, że mamy do czynienia z aplikacją, w której mamy bezpośrednią kontrolę nad jednym z nagłówków odpowiedzi. Przykładowo wykonujemy zapytanie pod adres http://example.com/?language=pl, w odpowiedzi zaś dostajemy:

Pamiętamy z opisu ze wstępu, że znaki <CR><LF> stanowią separator kolejnych nagłówków. Co więc stanie się, jeśli wstawimy te dwa znaki do parametru language i zamienimy nasz przykładowy request na http://example.com/?language=pl%0d%0aSet-Cookie:%20PHPSESSID=abcd?

Odpowiedź serwera mogłaby wyglądać następująco:

Jak widać, udało się wstrzyknąć nowy nagłówek http w odpowiedzi – nagłówek Set-Cookie, który tym samym pozwala na przeprowadzenie ataku session fixation.

Alternatywnie, zamiast wstrzykiwać nowe nagłówki, możemy po prostu zbudować jedną pustą linię i tym samym wstrzyknięcie przeniesie się do treści odpowiedzi. A tam można już przeprowadzać inny atak ;-).

http://example.com/?language=pl%0d%0a%0d%0aJestem%20w%20body:

Jak często spotyka się response splitting?

Właściwie… prawie nigdy. Praktycznie wszystkie powszechnie używane dziś frameworki są zabezpieczone przed tym atakiem. PHP nie pozwoli wykonać funkcji header („Test:\r\nTest”), odpowiadając ostrzeżeniem:

Warning: Header may not contain more than a single header, new line detected in /var/www/html/redirect.php on line 6

Podobne ostrzeżenia wyświetlą również takie środowiska jak .NET czy Java EE.

Czy zatem jest to podatność, o której można zapomnieć?

Niezupełnie… Poniżej zrzut ekranu jak udało mi się ostatnio wykorzystać response splitting do zrobienia XSS-a na stronie Google Doodle:

W tym przypadku możliwości ataku były jednak ograniczone – co prawda na zrzucie tego nie widać, ale aplikacja automatycznie zamieniała znak „–” (myślnik) na „_” (podkreślnik). Nie można więc było dodać większości ciekawych nagłówków, jak Set-Cookie (który zostałby zamieniony na Set_Cookie).

Nie stanowi to jednak dużego problemu, w XSS-ie w żaden sposób brak myślnika nie przeszkadza, a nawet – co za chwilę wyjaśnię – jest sprzymierzeńcem atakujących, gdyż umożliwia obejście filtra anti-XSS z przeglądarki Chrome.

Bez wchodzenia w szczegóły, ów filtr sprawdza, czy wykonywany kod javascriptowy znajduje się w zapytaniu http; jeśli tak, to jego wykonanie jest blokowane. Niemniej jednak, jeśli znajdziemy sposób na to, aby skrypt de facto różnił się od zapytania, wówczas Chrome nie rozpozna tego i nie zablokuje.

Wspominałem, że myślnik zamieniany jest na podkreślnik. Weźmy więc kod: <script>-=alert;-(1)</script>. Ten kod nie jest poprawny syntaktycznie, zostanie jednak zamieniony na <script>_=alert;_(1)</script> i wykonany na Chromie:

Michał Bentkowski