18:08
3/6/2010

Ataki typu clickjacking przeżywają obecnie swoje odrodzenie. Ich wysyp widać głównie na Facebooku. Użytkowników skłania się do wejścia na ciekawą i z pozoru niegroźną stronę, obiecując, że zobaczą coś niesamowicie interesującego — muszą tylko kliknąć w jakimś miejscu. Poniżej pokazujemy na czym polegają ataki clickjacking i jak się przed nimi uchronić.

Clickjacking: scenariusz ataku “likejacking”

Trafiasz z Facebooka na jakąś stronę. Polecił ci ją na Twojej “ścianie” znajomy. Żeby jednak zobaczyć to najśmieszniejsze, tą najpiękniejszą lub tego największego musisz kliknąć w jakiś obrazek albo link.

Uważaj! “Nad” miejscem wskazanym użytkownikowi do kliknięcia zazwyczaj znajduje się niewidzialna pływająca ramka (<iframe>). Przechwytuje ona kliknięcie i kieruje zupełnie inny przycisk/link, co dla użytkownika kończy się nieświadomym dodaniem do swojego Facebookowego profilu jakiejś strony (konsekwencja naciśnięcia przycisku “lubię to”) lub co gorsza rozesłaniem wiadomości do wszystkich swoich znajomych.

Jeden z ostatnich ataków clickjackingowych na Facebooku. Żeby poznać treść wyroku, trzeba kliknąć na obrazek.

Poniżej prezentujemy jeszcze jeden przykład clickjackingu. Zalogowany do Twittera internauta wchodzi na stronę z grą. Aby ją rozpocząć musi kliknąć na przycisk start.

Clicjacking na Twitterze

Na stronę z grą nałożona jest przezroczysta, niewidoczna dla użytkownika ramka, ładująca stronę z ustawieniami Twittera. Została ona ustawiona tak, aby przycisk [usuń moje konto z Twittera] znajdował się dokładnie w tym samym miejscu, co przycisk [start gry]. Użytkownik widzi tylko [start gry], ale klikając na niego, tak naprawdę klika w [usuń moje konto z Twittera] …i kasuje sobie konto.

Framebusting chroni przez clickjackingiem

Framebusting to technika pozwalająca danej stronie wyskoczyć z ramki, jeśli któryś z serwisów internetowych postanowi wyświetlić (podkraść) jej treść, np. za pomocą tagu <iframe>. Jako przykład serwisu “podkradającego” strony przez ramki iframe może posłużyć Wykop:

Wykop osadza Niebezpiecznika w ramce

Jeśli strona, która jest podkradana zawiera np. taki kod:

if (top.location != location)
top.location=self.location;

…to w wielu przypadkach z podkradania nici. Skrypty spowodują usunięcie ramki (tutaj: paska wykopu) ponieważ internauta od razu zostanie automatycznie przekierowany na stronę docelową (tę, która była wyświetlana w ramce). Co więcej, tego typu instrukcje mogą zadziałać również w przypadku, gdy zawartość ramki nie jest widzialna dla użytkownika (przezroczystość), tak jak ma to miejsce w obecnych atakach na Facebooka.

Problemy framebustingu

Technik framebustingu trochę jest. Jedne są lepsze, drugie gorsze. Niestety, wiele z nich atakujący może łatwo ominąć. Poniżej lista ataków, które pozwalają ominąc najpopularniejsze zabezpieczenia przed clickjackingiem:

Doubleframing – podwójne ramkowanie

Jeśli kod framebustingu zawiera odwołanie do “parent.location“, atakujący może podwójnie osadzić strone w ramce. Skrypt framebustingowy wyskoczy z pierwszej ramki (do parenta), ale z drugiej już nie…

Zmiana wartości zmiennej location

Większość przeglądarek nie pozwala modyfikować wartości location, ale nie wszystkie. W IE7 i Safari 4 można przedefiniować top.location, co sprawi, że każde odwołanie skryptu framebustingowego do tej zmiennej skończy się niepowodzeniem (skrypt się nie wykona i strona nie wyskoczy z ramki).

Zdarzenie onBeforeUnload

Atakujący może spróbować się podpiąć pod onBeforeUnload i wykrywać próby przekierowania, oczywiście blokując je robiąc redirect na serwer odpowiadający kodem HTTP “204 – No Content“.

var prevent_bust=0
window.onbeforeunload=function() {kill_bust++}
set Interval(function()
{ if (kill_bust>0) {
kill_bust −= 2 ;
window.top.location=’http://no-content−204.com’}
},1);
<iframe src=”http://www.victim.com”>

Sprawdzanie Referrera

Często strony korzystające z framebustingu chcą pozwolić na osadzanie ich w ramkach w obrębie własnego serwisu. Stosują w tym celu sprawdzenie document.referrer — często jednak błędnie (ach te problemy z regexpami…). I tak, przykładowy atak na stronę foobar.com może się udać z domeny foobar.com.zlastrona.pl (bo referrer check przejdzie).

Restricted Zone i Sandboxing

Jeśli do tagu iframe doda się parametr security=restricted, IE zinterpretuje to jako: “osadzana w ramce strona pochodzi z niezaufanej strefy, wyłącz dla niej obsługę skryptów JS i ciasteczek”. Dzięki temu atakujący wyłączy na osadzanej stronie skrypty framebustingowe, ale także obsługę cookies — co akurat powinno utrudnić atak (zerwanie sesji).

Sandboxing jest podobnym rozwiązaniem. Zdefiniowany w HTML5 i zaimplementowany już w Chrome paramter sandbox blokuje skrypty JS, ale nie ciasteczka — to trochę ułatwia sprawę atakującemu.

Tryb document.designMode

Odwołując się do document.designMode można włączyć na stronie tzw. tryb designu (IE8 i Firefox), który objawia się brakiem możliwości wykonywania JavaScriptu, ale nie dotyka ciastek. Framebusting szlag trafi, ale sesji nic nie ruszy.

Hackowanie framebustingu za pomocą filtrów XSS-owych

To chyba najciekawsze rozwiązanie. Korzysta ono z modułów zaimplementowanych w IE i Chrome, a zabezpieczających użytkowników przeglądarek przed atakami XSS. Wystarczy wywołać fałszywy alarm (false positive) pasujący do treści skryptu framebustingowego w atakowanej stronie — resztę zrobi za nas przeglądarka, blokując wykonanie tego skryptu na osadzanej w iframe stronie.

<iframe src=”http://www.victim.com/?v=<script>if">

Mobilna strona

Często serwisy posiadające ochronę przed clickjackingiem zapominają o umieszczeniu swoich skryptów framebustingowych na wersji serwisu przewidzianej dla urządzeń mobilnych. Sporo serwisów nie rozróżnia również sesji mobilnych od normalnych, dzięki czemu atakujący może do ataku clickjackingowego wykorzystać mobilną wersję strony — jeśli ofiara jest zalogowana w atakowanym serwisie to jest również zalogowane w jego mobilnej wersji.

Oprócz separacji mobilnych sesji pomóc może również sprawdzanie zmiennej User-Agent i zezwolenie na dostęp do mobilnej strony tylko urządzeniom, które faktycznie są telefonami komórkowymi, itp.

X-FRAME-OPTIONS

Warto również wspomnieć o nagłówku X-FRAME-OPTIONS jako metodzie ochrony przed clickjackingiem. Nagłówek ten przyjmuje wartości SAMEORIGIN albo DENY. W przypadku pierwszej, przeglądarki które rozumieją ten nagłówek pozwolą na osadzenie strony tylko w obrębie macierzystej domeny. Jeśli ustawione zostanie DENY, strona w ramce nie zostanie w ogóle zinterpretowana.

Nagłówek ten ma jednak kilka wad:

  • ciężka implementacja, jeśli chcemy dostosować jego wartość do każdej z podstron na serwerze z osobna.
  • brak możliwości zezwolenia na osadzanie w ramce dla innych stron niż macierzysta.
  • serwery proxy często usuwają nagłówki HTTP

Najlepsza ochrona przed clickjackingiem

Według badaczy, którzy przeanalizowali 500 najpopularniejszych stron pod kątem wykorzystywanych technik framebustingowych, najlepszy skrypt chroniący naszą stronę przed “zramkowaniem” to:

<style> html {visibility:hidden;} </style>
<script>
if(self == top)
{ document.documentElement.style.visibility="visible"; }
else { top.location = self.location; }
</script>

Minus tego skryptu jest jednak taki, że osoby z wyłączonym JavaScriptem niczego nie zobaczą… no i zapewne też da się je w jakiś sposób obejść.

Zabezpieczenia po stronie klienta

Powyższe skrypty framebustingowe to zabezpieczeniem server-side. Znaczy to tyle, że ofiara ataku jest zdana na administratora danej strony internetowej i to, czy załączy ten lub podobny skrypt framebustingowy. A czy można ochronić się od strony klienta?

Częściowo tak. Użytkownicy Firefoksa mogą skorzystać z dodatku NoScript, który posiada funkcję ClearClick, zaprojektowaną dokładnie po to, aby uniemożliwić ataki typu clickjacking.

Co wybrać?

X-FRAME-OPTIONS a może skrypty? Jeśli skrypty, to jakie? Te z top.location czy może te z visibility:hidden? Decyzja z której z metod ochrony przed clickjackingiem skorzystać należy do was. Którąś z nich na pewno warto zaimplementować na swoich stronach internetowych… Aha i nie zapominajcie o mobilnej wersji swojego serwisu ;-)

Przeczytaj także:


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

22 komentarzy

Dodaj komentarz
  1. Witajcie,
    Wykradanie danych / dostęp aplikacji do danych (np poprzez facebook) to temat stary jak swiat. Zejde troche z tematu (ale sorry ;) ).
    Ostatnio pobawilem sie troche telefonem z Androidem i zauwazylem, ze wiele aplikacji z Android Market wymaga dostepu do ostatnio wykonywanych polaczen/mojej lokalizacji/ksiazki adresowej + dostepu do internetu. Czy zwykla gra np. pasjans do czegos tego potrzebuje ?
    Nie mialem czasu wgryzac sie w temat bezpieczenstwa Androida, ale moze to być kolejna malo popularna dziura. Jesli faktycznie tak jest jak myślę, to super sprawa na ataki a’la clickjacking albo “installjacking” – o ile coś takiego zostało już nazwane :D
    Bo fajnie byloby napisac prosta aplikacje dla usera, wrzucic na Android Market, niech sobie coś tam robi, ale jednoczesnie przeskanuje telefon, kontakty, lokalizacje, maile i wysle na wskazany adres ;)
    pozostawiam do przemyślenia :)
    pozdro

  2. A dla końcowego użyszkodnika wystarczy NoScript. Bardzo ładnie wykrywa clickjacking na wielu stronkach.

  3. I wystartowali!…

    Teraz nagle webmasterzy ładują WSZYSTKIE powyższe zabezpieczenia do swoich stron :D

    • @Tomko: zabezpieczenia przed clickjackingiem maja sens, jesli dany serwis udostepnia np. konta uzytkownikom (banki, fejsbuki, etc.). Zwykle “strony domowe” raczej nie powinny sie obawiac clikcjackingu ;)

  4. @pawelreal
    dostep do tych danych jest pewnie potrzebny nie aplikacjom, ale reklamom w darmowych aplikacjach.
    Swoja droga to moj poprzedni SEk800i pozwalal wybrac na co zezwalamy aplikacji a na co nie

  5. Fajnie, że po tym jak napisałem o NoScript dodałeś tą informację do artykułu.

    • @would: No problemo. Post miał skupiać się na rozwiązania server-side, ale o NoScript zdecydowanie warto wspomnieć.
      @Jurgi: spróbuję przetestować, ale na jakimś normalnym buildzie. Ten, z którego teraz korzystam pozostawia wiele do życzenia, w zdecydowanie poważniejszych kwestiach niż obsługa ramek ;)

  6. Ramki to zuo.

  7. Parę pytań.
    • Opera ma w opcjach „pokazuj obramowanie aktywnej ramki”, czy to nie może pomóc wykryć taką nałożoną ramkę?
    • Dawniej w Operze był opcjonalny UserCSS (o ile pamiętam) „wyłam stronę z ramek” lub coś podobnego, nie byłoby też skuteczne?

  8. A czy javascript nie może obsługiwać klawiatury i myszki? Czy nie wystarczy wejść na stronę z iframe i już skrypt sam będzie klikał w odpowiednie miejsca?

  9. […] kilka sposobów na ochronę serwisów internetowych przed atakimi typu calickjacking (por. clickjacking i framebusting). Dziś dowiedzieliśmy się, że najnowszy Firefox będzie wspierał rozwiązanie X-Frame-Options […]

  10. Proponuję poprawkę na brak skryptów:

    html {visibility:hidden;}
    html {visibility:visible;}

    if(self == top)
    { document.documentElement.style.visibility=”visible”; }
    else { top.location = self.location; }

  11. […] tak naprawdę ochrona przed click-jackingiem często wykorzystywanym w atakach przez złośliwe Facebookowe aplikacje. Facebook nie precyzuje co […]

  12. […] domen, które na różne sposoby przekonują do: instalacji złośliwych aplikacji, przeprowadzają ataki clickjacking (a dokładnie “likejacking” — czyli przekierowywania kliknięcia w przycisk […]

  13. Lubię ten temat. Budzi wiele kontrowersji. Przy okazji chciałem zwrócić uwagę na ciekawą alternatywę NoScript, jaką jest równie dobry i służący dokładnie temu celowi (tj. zabezpieczenie client-side) inny plug-in FireFox-a o nazwie Request Policy – dla zainteresowanych URL: https://addons.mozilla.org/en-us/firefox/addon/requestpolicy/ .

    Jednocześnie ciekawi mnie opinia innych użytkowników sieci: Czy strony web powinny oczekiwać od przeglądarki request-ów do zasobów znajdujących się w innych domenach? Popularne dzisiaj cdn-y i static-hostingi, chociaż zbawienne dla wydajności i kosztów utrzymania serwisów, utrudniają zarządzanie polityką bezpieczeństwa w zakresie deklarowania (white- i black-) list reguł dotyczących kontaktu pomiędzy domenami. Oczywiście hashtagging request-ów jest odpowiedzialnością developera, ale czy to znaczy, że świadoma zagrożenia jednostka powinna natychmiast zrezygnować z popularnych i jednocześnie podatnych usług, lub za każdym razem otwierać dedykowaną sesję przeglądarki, aby z nich korzystać? Nie mam tutaj wyraźnej opinii, ale czasem popadam w krótkotrwałą melancholię myśląc o tym, jak wielki potencjał miała globalna wioska i jak bardzo psują ją nieodpowiedzialni projektanci wirtualnych metropolii.

    Cheers!

  14. […] skrócie, ten atak to de facto clickjacking. Aplet Flasha dający uprawnienia stronie internetowej do korzystania z kamery w komputerze […]

  15. […] Na swojej stronie atakujący, w ramce (iframe), osadzić może dowolną zawartość pochodzącą z innej domeny (o ile domena ta pozwala na “ramkowanie”, czyli nie ma ustawionego nagłówka X-Frame-Options zabezpieczającego przed clickjackingiem). […]

  16. […] i kilkająca gdziekolwiek na stronie osoba tak naprawdę lajkowała nasz Fanpage (por. atak likejacking). W ciągu 2 dni, do nasz profil zalajkowało ok. 3 tys. “lewych” […]

  17. […] na naszej ścia­nie wia­do­mość, w którą kli­kają kolejne osoby. Nazy­wamy to click lub like­jac­kin­giem. Jak opi­suje Nie­bez­piecz­nik sce­na­riusz takiego wyda­rze­nia może […]

  18. Hej, w apce w której pracuję miałem problem taki, że zawsze self != top , czy byłem czy nie w . Rozwiązaniem okazał się warunek :
    if(top!=self.parent)
    Piszę dla ludzi którzy znaleźli(wykopali) ten artykuł gdyż walczą z problemem podobnym do mojego :)

  19. […] to teraz się zacznie — oto Jack — tworzenie ataków clickjackingowych nigdy nie było prostsze […]

Twój komentarz

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

RSS dla komentarzy: