Wpis z mikrobloga

#security

Opowiem o ciekawym przypadku #xss, który znalazłem ostatnio na #wykop i został już naprawiony. Ciekawy jest dlatego, że nie tak łatwo go wyexploitować... Ale po kolei.

Podatność występowała na niektórych podstronach bezpośrednio w adresach. Gdy w adresie został umieszczony znak cudzysłowia, a następnie nawiasy ostre, można było wyjść z tagu i wprowadzić dowolny kod HTML. Przykład na screenie: http://i.imgur.com/ulCWnvo.png

Może się wydawać: no to jesteśmy w domu, mamy XSS-a! Praktyczne wykorzystanie tego błędu nie jest jednak takie łatwe, a wiąże się z zachowaniem przeglądarek, które automatycznie dokonują URL-encodingu adresów, w których znajdują się nietypowe znaki. A więc nawet jeśli skonstruujemy URL wyglądający tak: http://www.wykop.pl/mikroblog/", to przeglądarka i tak wykona żądanie pod http://www.wykop.pl/mikroblog/%22%3cxss%3e. Każda z popularnych przeglądarek - Firefox, Chrome, IE, Opera - zachowuje się w taki sposób. A wtedy ten wykopowy XSS nie wykonuje się, ponieważ do źródła strony przepisywane było dokładnie to samo, co było w adresie. Więc jeśli w adresie był znak

"
, to on pojawił się w źródle. Jednak jeśli było

%22
, to w źródle pojawia się

%22
.

Jest jednak co najmniej jeden sposób (a dokładniej: jeden sposób, który znam) na zmuszenie przeglądarki do wysłania żądania bez URL-enkodowania. Działa tylko w Internet Explorerze i myślę, że spokojnie można go potraktować jako bug tej przeglądarki. Okazuje się, że IE wykonuje żądanie bez enkodowania adresu dla adresów, które pobiera z nagłówka

Location
przy przekierowaniach. Wystarczyło więc przygotować stronę, która odpowiada kodem 302 z nagłówkiem

Location: [http://www.wykop.pl/mikroblog/next/6391690"](http://www.wykop.pl/mikroblog/next/6391690")>![](1)/%2e%2e/
Przechodzimy na tę stronę z Internet Explorera i exploit (alert o treści "XSS") pięknie się wykonuje, bowiem IE nie zamienia

"
na

%22
,

<
na

%3c
etc. tylko wysyła jak leci. Dołączam do tego postu dowód filmowy, że to działało. Sam exploit wrzuciłem pod adresem: http://hakerium.cba.pl/secret/wykop_xss.php

Na koniec proponuję małą zagadkę: po co na końcu swojego exploita dałem tę część

/%2e%2e/
?

Reasumując, jeśli testujecie kiedyś strony pod kątem XSS-ów i XSS wykonuje się jedynie w przypadku, gdy w URL-u znajduje się znak, który domyślnie jest URL-enkodowany, to taki exploit wciąż jest wykonalny na Internet Explorerze. To dość przydatna wiedza, w kontekście różnych #bugbounty albowiem można udowodnić, że w praktyce da się taki błąd wykorzystać.

Jeśli ktoś chciałby zapytać, do czego praktycznie można wykorzystać XSS, to najczęściej próbuje się osiągnąć następujące cele:

- Wykradnięcie ciastka sesyjnego (na Wykopie nietrywialne ze względu na użycie flagi HttpOnly),

- Odczyt dowolnych danych stronie (np. XSS w Gmailu daje dostęp do całej poczty) lub wykonanie dowolnych akcji na stronie (na Wykopie można by wykopywać swoje znaleziska),

- Monitorowanie aktywności użytkownika,

- Przechwycenie danych logowania użytkownika - można pokazać fałszywą stronę logowania, w którą użytkownik ochoczo wpisze własne hasło :)

(dodaję też #zagadkihakerskie bo myślę, że może to zainteresować subskrybentów)
A.....t - #security



Opowiem o ciekawym przypadku #xss, który znalazłem ostatnio na...
  • 9
@namthar: Jeśli dobrze zrozumiałem pytanie (a nie jestem tego pewien) to tak. Błąd polega właśnie na tym, że w niektórych podstronach aktualny URL był przepisywany na stronę bez uwzględniania jakiegokolwiek enkodowania (czy to URL, czy to HTML).
@AleFermat: Tak, o to mi chodziło. A chyba nieczęsto się z tego korzysta. A przynajmniej ja albo generuję taki link do formularza (kontroler, akcja), albo ewentualnie daję action=""
@AleFermat:

[http://www.wykop.pl/mikroblog/next/6391690"](http://www.wykop.pl/mikroblog/next/6391690")>![](1)/%2e%2e/
"

/%2e%2e/
" = "

/../
"

czyli przejście jeden poziom wyżej - podejrzewam że aby zamaskować podejrzaną część kodu na pasku adresu użytkownika jak i/albo uniknąć wykopowego 404
@kulmegil: Właściwie tak. Internet Explorer ma wbudowany filtr anti-XSS, który nie przepuszczał tego żądania, bo widział, że w URL-u znajduje się to samo, co później wykonuje się na stronie. Zastosowanie dwóch kropek skutkujące wizualną zmianą URL-a spowodowało, że filtr się uciszył i skrypt się wykonywał.