10:32
22/7/2010

XSS na Wykopie

Autorem poniższego tekstu jest Sławomir Błażek.
Chcesz umieścić na Niebezpieczniku swój tekst? Daj nam znać.

Z ciekawości chciałem sprawdzić czy nie możnaby wyróżnić swojego znaleziska np. poprzez wsadzenie do tytułu <h1>, zmiany koloru lub w jakiś inny sposób manipulacji przy tytule. Okazało się, że śmiało można było wstrzykiwać tagi html i nie są one w żaden sposób filtrowane…

Ten wpis jest zgodny z ideą responsible disclosure. Opisywana poniżej luka została zgłoszona do administracji serwisu i jest już załatana.

Zaraz po sprawdzeniu <h1> wykonałem test <script></script> — zadziałało, można więc osadzić dowolny tag, a tym samym dowolny JavaScript. Zgłosiłem błąd, w międzyczasie sprawdzając inne pola…

Pola podatne na atak

Pole “Opis” także okazało się podatne i jednocześnie stwarzało wieksze możliwości — wiecej znaków czyli możliwość wstrzykniecia bardziej rozbudowanego JS.

Możliwy scenariusz ataku

Dodajemy jakiś nośny temat, ale nie wstrzykujemy jeszcze nic by nikt się nie zorientował, że coś jest nie tak. Czekamy 2h (bo tyle czasu Wykop pozwala na edycję znaleziska) z nadzieją, że temat trafi na główną stronę. Edytujemy znalezisko wstrzykując tym razem złośliwy skrypt JS, który będzie odpowiedzialny za… (tutaj tylko wyobraźnia nas ogranicza).

XSS na Wykopie w akcji (fot. Sławomir Błażek)

Pierwsza poprawka Wykopu: nieskuteczna

Postanowiłem sprawdzić także inne elementy Wykopu. Okazało się, że równie prosto można osadzać swój JS w treści publikacji w wykopokazywarce. Po zgłoszeniu błąd został poprawiony, ale nie do końca…

Wstępnie wygladało, jaby poprawki zostały wprowadzone tylko po stronie klienta i nadal można było wstrzykiwać HTML lecz trzeba było ominąć walidację edytora (łatwo można to zrobić poprzez dodatki do przeglądarek takie jak FireBug, czy WebDeveloper, albo ręczne spreparowanie POSTa i wysłanie go za pomoca netcata czy chociażby napisanie prostego skryptu w perlu czy pythonie.

Wykop szybko zaaplikował drugą poprawkę — walidacja danych od klienta jest teraz prawidłowo wprowadzana i w edytorze jak i po stronie serwera… chociaż na początku nie działała tak jak powinna.

Film na Wykopie + XSS gratis

Kolejnym miejscem podatnym na XSS był mechanizm publikacji filmów. Jeśli jako url podaliśmy np:

http://youtube.com/watch?v=XXXXXXXXX"><script>alert(1)</script>

To cały ten string lądował w <object> na stronie, który był odpowiedzialny za wyświetlenie playera.

Kolejny XSS w Wykopie

Po poprawkach, w tym samym mechanizmie znalazłem jeszcze jeden błąd. Podając URL do filmu, AJAX wysyła go na serwer Wykopu, ten przeprowadza swoje testy mające sprawdzić czy pod URL-em faktycznie jest prawidłowy film, który później można osadzić na stronie. Jeśli tak jest, to zwraca gotowy <object>, który następnie zatwierdzamy klikając “Zapisz”.

Jeśli po teście filmu, a przed zapisaniem dokonamy zmian/edycji tego gotowego <object> (FireBug, WebDeveloper, skrypty, proxy) to można go podmienić na <script></script> i osiągnać efekt – kolejny XSS. Również tego buga Wykop poprawił poprzez dodanie hasha generowanego po stronie serwera — teraz jeśli dopuścimy sie jakiejkolwiek manipulacji, hash sie nie będzie zgadzał i <object> nie zostanie osadzony na stronie.

Szybka reakcja, szybkie poprawki

Reakcja Wykopu w każdym z przypadków była szybka, a kontakt i wspólpraca z programistą wzorowa. Wiedzą co robią, wiedzą jak to szybko naprawić, a błędy… błędy zdarzają się kazdemu :-)

P.S. Wiem, że przydałoby się wiecej szczególów ale nie spodziewałem się, że błędy będa na tyle istone, że będę potrzebował odpalić logujace proxy i/albo jednocześnie prowadzić dokładne notatki.

Od Redakcji: Przypominamy, że jeśli chcecie przetestować swoje serwisy pod kątem ataków XSS, to możecie skorzystać z darmowego XSSera.

Aktualizacja 16:04
W komentarzach do tego wpisu na Wykopie, użytkownik koziołek znalazł jeszcze jeden XSS.

XSS w obserwowanych na Wykopie (fot. koziolek)

Przeczytaj także:



27 komentarzy

Dodaj komentarz
  1. Nie spodziewałem się “tak prostych” luk na wykopie…

  2. “Reakcja Wykopu w każdym z przypadków była szybka” – lata wpadek uczą szybkości ;)

    Błędy na poziomie przedszkolnym, tym bardziej że Wykop już miewał podobne “problemy”.

  3. Błędy zdarzają się każdemu… ale w tak poważnym serwisie i w takiej ilości?

  4. @Sayene: w tak poważnym serwisie i w takiej ilości się nie zdarzają w takim razie…

  5. khem.. w dwóch wielkich polach taka dziura? i wisi już 2 miechy (gdzieś tyle ma nowy wykop)? WSTYD.. “błędy zdarzają się każdemu” – ja takich dziur nie zrobiłem 5 lat temu jak prostą stronkę w php (głównie formularze) napisałem w notepadzie.. co innego jakieś małe wstrzyknięcie kodu w mało znaczącym miejscu, gdzie trzeba się szczególnie postarać żeby coś wstrzyknąć (np. ostatnia dziura na YT – to było trudniejsze niż wrzucenie xss();

  6. oh, wycięło mi z komentarza tagi script naokoło xss(); …

  7. Bez przesady, @dżek, taką wielką dziurą bym tego nie nazwał. Duze ryzyko pojawia sie dopiero jak w ciągu 2h coś dociera na główną, a to się chyba rzadko zdarza.

  8. Przepraszam czy dziś jest 1 kwietnia? Poszukiwałem w tekscie ‘gulgul’ albo coś z drobiu :] Jednak niestety nie znalazłem… Nie korzystam z wykopu no ale jak można popełniać takie błędy w takiej ilości? Co robią programiści ? Liczą na głupote userów czy zapomnieli o takiej błachostce jak filtrowanie danych od użytkownika no bo w sumie po co ?…

    Raczej stronie od wykopu a teraz jescze bardziej ;)

  9. w życiu bym nie wpadł na to, że ta strona ma takie głupie błędy.. nawet bym nie próbował ;)

  10. Na takiej stronie… taki błąd… no kto by pomyślał ;D. Teeed -> +1.

  11. Sprawa jest bardziej skomplikowana niż może się wydawać, bo różne ataki działają w różnych przeglądarkach i chyba ciężko jest się zabezpieczyć na 100%

    http://ha.ckers.org/xss.html

  12. W starym wykopie tych luk raczej nie było. Nowa funkcjonalność niesie ze sobą nowe zagrożenia :} Taki pech ;]

  13. Kiedy luki zostały zgłoszone/załatane? Jakieś 3 tygodnie temu też sprawdzałem czy jest możliwość wyróżnienia tytułu.. wtedy już nie działało.

    Choć nawet nie liczyłem na to, że zadziała. Taka poważna strona.. ;)

  14. kolejny dowód na to jak żalowym serwisem jest wykop.pl -.-

  15. Jest też możliwość CSRF gdzieniegdzie

  16. Dodając ‘dodatkowy’ kod na Wykopie filtrowało poprawnie, co skutkowało pozostawianiem śladów w tworzonych adresach URL – przykład: http://xss.wykop.pl/link/397013/podstawowe-informacje-o-xb-title-xss/
    Jednak przy edycji można było robić już wszystko. Tamten link umieszczałem 3 tyg temu – od tego czasu chyba coś zmieniano, jeśli pole tytułu bezpośrednio przy dodawaniu (nie edycji) nie filtrowało już przykładowo “”.

    Wykop już wcześniej miał problemy z XSS, powinni się nauczyć na własnych błędach.

  17. AFAIK nie trzeba liczyć na to, że znalezisko trafi na główną już w ciągu pierwszych dwóch godzin. Jeśli można wstrzyknąć dowolny kod z dowolnego źródła to żadnym problemem jest zmodyfikowanie złośliwego kodu po upływie tego czasu. Poprawcie mnie jeśli się mylę – nie wiem jak to się ma do same origin policy w JS.

  18. @s!n: Na pewno można (było) wstrzyknąć coś, co się wykona tylko if(d.getTime() > ***), gdzie var d = new Date(). :-)

  19. czy (a raczej czemu) podatnosci typu iks-es-es doprowadzają was do erekcji, czy też naprawde nie macie już o czym pisac ? :)

  20. Zastanawiam się tylko ile wykopów zostało w ten sposób wciągniętych na główną – prostym skryptem, który od razu wykopuje znalezisko.

    • Chyba ktoś by to już dawno temu zauważył inspektorem.

  21. > Wstępnie wygladało, jaby poprawki zostały wprowadzone tylko po stronie klienta i nadal można było wstrzykiwać HTML lecz trzeba było ominąć walidację edytora (łatwo można to zrobić poprzez dodatki do przeglądarek takie jak FireBug, czy WebDeveloper, albo ręczne spreparowanie POSTa i wysłanie go za pomoca netcata czy chociażby napisanie prostego skryptu w perlu czy pythonie.

    Albo wyłączając JS w przeglądarce. Po co sobie życie komplikować? :>

  22. @keemor: sprawa BYWA skomplikowana, ale nie zawsze. Problematyczne jest OCZYSZCZANIE danych wprowadzonych przez użytkownika z rzeczy niedozwolonych. Nawet przyjmując prawidłowe podejście białej listy można popełnić błędy (patrz przykład: http://threats.pl/bezpieczenstwo-aplikacji-internetowych/oczyszczanie-html-jest-trudne). Ma to zastosowanie wówczas, gdy pewien podzbiór HTML ma być dopuszczony.

    Z drugiej strony masz sytuację, w której znaczniki HTML nie są dopuszczane. Wówczas istnieją dwie podstawowe linie obrony:
    – walidacja danych wejściowych (znów – biała lista, a nie “znaki zakazane”),
    – encoding danych na wyjściu,
    Prawidłowe podejście to stosowanie obu tych mechanizmów jednocześnie. W szczególnym przypadku może okazać się, że walidacja danych wejściowych mija się z celem, bo dopuszczalne są wszystkie znaki, pozostaje druga linia – encoding. I właśnie tego prawidłowego encodingu tutaj zabrakło. Uwierz mi, nie ma jeszcze takiej przeglądarki, która znak < pomyli z < :)

  23. Oczywiście chodziło mi o mylenie znaku < ze stosowną encją, czyli < (może teraz prawidłowo się wyświetli) :)

  24. @BTM: Wyłącznie JavaScript nie zawsze jest rozwiązaniem dobrym. Niektóre formularze są nieco zagmatwane, przy ich wysyłaniu skrypty JavaScript wykonują z danymi jakieś cuda, łączą, formatują, przenoszą do innych pól. Wówczas wyłączając JavaScript ryzykujesz tym, że formatka nie zadziała, a później jeszcze musisz się zastanawiać dlaczego.

    Lepszym rozwiązaniem, mniej utrudniającym życie, jest wpięcie się pomiędzy przeglądarkę, a serwer przy pomocy narzędzi typu local proxy, np. WebScarab, Burp czy mój ulubiony Fiddler.

  25. Albo NoScripta. ;)

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: