Clickjacking (także UI redress attack) – atak na użytkownika serwisu internetowego, w którym napastnik za pomocą przezroczystych lub nieprzezroczystych warstw nakłania go do kliknięcia przycisku lub odnośnika na innej stronie niż ta, którą użytkownik widzi i zamierza obsłużyć. Kliknięcie, pozornie przeznaczone dla strony napastnika, trafia w rzeczywistości do innej aplikacji lub domeny, a nazwa ataku pochodzi od przechwycenia (ang. hijacking) kliknięcia.
Mechanizm działania
Napastnik tworzy stronę zachęcającą do kliknięcia, np. przyciskiem obiecującym darmową nagrodę, i umieszcza nad nią niewidoczną ramkę (iframe) z inną stroną, np. skrzynką pocztową ofiary. Ramkę ustawia tak, aby przycisk usuwający wszystkie wiadomości znalazł się dokładnie nad przyciskiem widocznym dla ofiary. Klikając pozorny przycisk, ofiara w rzeczywistości klika przycisk w ukrytej ramce. W podobny sposób można przechwytywać naciśnięcia klawiszy – odpowiednie połączenie arkuszy stylów, ramek i pól tekstowych może sprawić, że użytkownik wpisuje hasło do niewidocznej ramki kontrolowanej przez napastnika, sądząc, że loguje się do poczty lub banku.
Atak wykorzystuje to, że ofiara jest zalogowana w atakowanym serwisie. Według Jeremiaha Grossmana nie da się zmusić użytkownika do działania w serwisie, w którym nie jest zalogowany. Clickjacking może posłużyć m.in. do włączenia kamery internetowej lub mikrofonu ofiary, skierowania jej na stronę ze złośliwą zawartością albo do kliknięcia „kup” zamiast „anuluj” w sklepie internetowym.
Historia
Sam typ ataku był znany od lat, ale nie uważano go za szczególnie groźny – eksperci sądzili, że może posłużyć np. do oszustw na kliknięciach w reklamy. Termin clickjacking wprowadzili Robert Hansen i Jeremiah Grossman w opracowaniu opublikowanym we wrześniu 2008 roku. Badacze planowali przedstawić na konferencji OWASP AppSec 2008 w Nowym Jorku podatności tego typu dotyczące wszystkich głównych przeglądarek internetowych. Przygotowany przez nich kod ujawniał jednak błąd w jednym z produktów firmy Adobe i na jej prośbę badacze odwołali wystąpienie.
Jednym z najbardziej znanych przykładów był atak na stronę ustawień wtyczki Adobe Flash. Wczytana w niewidocznej ramce, pozwalała nakłonić użytkownika do zmiany ustawień bezpieczeństwa i udzielenia dowolnej animacji Flash dostępu do mikrofonu i kamery komputera. W lutym 2009 roku technikę wykorzystano w serii żartobliwych ataków na Twitterze – użytkownicy klikający przycisk „Don't Click” nieświadomie rozsyłali wpis wszystkim obserwującym, dzięki czemu szybko się on rozprzestrzeniał. Znane są też ataki nakłaniające zalogowanych użytkowników Facebooka do nieświadomego oznaczania stron, odnośników i grup przyciskiem „Lubię to”.
Ochrona
Podstawową ochroną jest zablokowanie osadzania strony w ramkach na innych stronach. Służy do tego dyrektywa frame-ancestors nagłówka Content Security Policy – wartość 'none' uniemożliwia osadzenie strony w ramce na jakiejkolwiek stronie, a 'self' dopuszcza tylko strony tej samej witryny. Starszy nagłówek X-Frame-Options z wartościami DENY i SAMEORIGIN został zastąpiony przez frame-ancestors, ale nadal stosuje się go dla zgodności ze starszymi przeglądarkami. Oba mechanizmy działają wyłącznie jako nagłówki odpowiedzi HTTP, a nie jako znaczniki meta.
Dodatkową ochronę daje atrybut SameSite plików cookie sesji. Pliki z wartością Strict lub Lax nie są dołączane do żądań wysyłanych ze strony w ramce, więc atak wymagający zalogowania ofiary się nie powiedzie. Atrybut nie chroni jednak przed atakami, które nie wymagają uwierzytelnienia. Proste skrypty JavaScript blokujące wyświetlanie strony w ramce można obejść, np. przez osadzenie strony w dwóch zagnieżdżonych ramkach albo w ramce z wyłączoną obsługą skryptów, dlatego OWASP zaleca łączenie kilku niezależnych metod ochrony.
