Miałem dziś przyjemność przejrzeć jedną z zeszłorocznych pozycji książkowych wydawnictwa Helion na temat bezpiecznych stron WWW. Dla początkującego programisty PHP jest to dość dobre źródło informacji o potencjalnych zagrożeniach, ale rozwiązania są tylko pobieżnie zarysowane. Niestety, mam wrażenie, że pod względem znajomości problemów cross-site/zone oraz internacjonalizacji aplikacji jesteśmy sto lat za Murzynami.
Dla przykładu - kod z okładki, zgodny z zaleceniami autorów odnośnie XSS (wyraźnie sugerują stosowanie funkcji strip_tags, która nie sprawdza się w przypadku wartości atrybutów):
<p align =”center”>
<a href=”index.php?<?php echo strip_tags (SID)?>”>
Click to continue</a></p>
Chciałbym zgłosić podatność książki na XSS ;)
Trochę pocieszający jest fakt, że nawet tym największym serwisom zdarzają się spore wpadki - na przykład MySpace wciąż ma problemy z filtrami XSS (rekord to cztery kolejne nieskuteczne poprawki w tym samym miejscu). A propos MySpace - polecam lekturę artykułu How Not to Distribute Security Patches.
Aktualizacja (10 stycznia): Piąta poprawka na MySpace
Odnośnik: patching Adobe’s hole
Chyba po raz pierwszy w historii producent przeglądarki wprowadza zabezpieczenie przeciwko luce XSS w innym produkcie. Opera najwyraźniej pracuje na opinię bezpiecznej przeglądarki - bo przecież na bezpieczeństwo wpływają nie tylko same luki, ale także sposób reakcji na zagrożenia - w tym przypadku wzorowy.
W kodzie dodanym do browser.js widać, że nie jest to uniwersalne zabezpieczenie:
if( pathname.indexOf(’.pdf’)>-1 && hash && hash.indexOf(’javascript:’)>-1 ) …
ale tak naprawdę bardziej skuteczne rozwiązanie nie jest potrzebne - Adobe udostępnił poprawioną wersję, a łatka Opery ma na celu jedynie zmniejszenie zagrożenia w czasie migracji użytkowników w kierunku Acrobat Reader 8.
(Na co dzień używam Firefoksa, a czasami Internet Explorera, więc powyższa notka nie jest elementem “świętej wojny” ;) ).
Przy okazji istotna informacja, którą wcześniej przegapiłem (używam angielskojęzycznego oprogramowania): niestety Acrobat Reader 8 nie jest jeszcze dostępny w polskiej wersji językowej.
Ukazała się dziś nowa wersja Wordpress: 2.0.6. Znajdująca się w poprzedniej wersji luka, której szczegółów nie ujawniono, została na secunia.com oznaczona jako “Highly critical”. Najprawdopodobniej chodzi o niepełne filtrowanie w mechanizmie Trackback (changeset 4677).
Aktualizacja (5 stycznia): Stefan Esser opublikował więcej informacji na hardened-php.net. Poza wspomnianym wyżej błędem w wp-trackback.php, Esser odkrył również poważną lukę XSS w zabezpieczeniach Wordpress przed CSRF.
Aktualizacja (8 stycznia): exploit wykorzystujący pierwszą lukę ukazał się na milw0rm.com. W skrócie: apostrofy w postaci UTF-7 (+ACc-) były zamieniane na domyślne kodowanie przez mb_convert_encoding (wp-trackback.php), co umożliwiało SQL-injection.
Gorączka towarzysząca ujawnieniu luki w Adobe Acrobat przysłoniła znacznie większe zagrożenie: przepełnienie bufora w Apple Quicktime (nie używam Quicktime, dlatego ja również przegapiłem tę informację). Złośliwy kod może znajdować się w pliku QTL, zamaskowanym na przykład jako MP3, i ukrytym na stronie internetowej.
Nie jest jeszcze dostępna łatka (za to exploity - wręcz przeciwnie: 1 i 2). Poza odinstalowaniem Quicktime, częściowym rozwiązaniem może być (podobnie, jak w przypadku luk we wtyczkach Media Player i Acrobat Reader) zmiana w przeglądarce domyślnej akcji dla plików powiązanych z wtyczką. W Firefoksie 2.0: Tools->Options->Content->Manage->zmiana wszystkich akcji na “Save to Disk” (użytkownicy polskojęzycznej wersji nie powinni mieć problemu z przetłumaczeniem).
Przy okazji pozwolę sobie na pewną uwagę. Kilka lat walki o uznanie XSS za rzeczywiste zagrożenie przyniosło chyba większe rezultaty, niż ktokolwiek się spodziewał. Historie o robakach atakujących serwisy społecznościowe, albo atakach XSS kradnących dane z lokalnego dysku, przebijają się na pierwsze strony serwisów informacyjnych, podczas gdy większe zagrożenia bywają niemal ignorowane. Ciekawe, kiedy hakerzy (w złym znaczeniu tego słowa) zaczną wypuszczać złośliwe skrypty tylko po to, by odwrócić uwagę świata od prawdziwego ataku…
W październiku 2006 roku Stefano Di Paola odkrył lukę we wtyczce Acrobat Reader - po ponad dwóch miesiącach została ona ujawniona: www.wisec.it. Umożliwia ona dokonanie ataku XSS w dowolnej domenie, w której serwowany jest plik PDF, a także ataku DOS na przeglądarkę użytkownika. Nie potwierdzono możliwości zdalnego wykonania kodu.
Inny wariant zastosowania tej luki opublikowano na ha.ckers.org oraz gnucitizen.org - za pomocą spreparowanego odnośnika do pliku PDF można również odczytać zawartość dowolnego pliku na komputerze ofiary. W połączeniu z luką w QuickTime można utworzyć kod, który zrealizuje taki atak, gdy ofiara odwiedzi złośliwą stronę www.
Luka została usunięta w Adobe Acrobat Reader 8.0. Można też bronić się przed nią, wyłączając w przeglądarce obsługę plików PDF przez wtyczkę.
Podatne na atak są zarówno Internet Explorer, Firefox, jak i Opera (Windows/Linux).
Test dla Acrobat Reader 6.0 CE na Windows (wymaga wtyczki QuickTime)
Sugerowane rozwiązanie po stronie serwera (Martin O’Neil):
<ifmodule mod_headers.c>
<filesmatch ".pdf$">
Header append Content-disposition "attachment;"
</filesmatch>
</ifmodule>