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[1].
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[1]. 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[1].
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[2].
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[3]. Termin clickjacking wprowadzili Robert Hansen i Jeremiah Grossman w opracowaniu opublikowanym we wrześniu 2008 roku[2]. Badacze planowali przedstawić na konferencji OWASP AppSec 2008 w Nowym Jorku podatności tego typu dotyczące wszystkich głównych przeglądarek internetowych[4]. 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[4][3].
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[1]. 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ł[2][1]. 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”[1].
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[5][1].
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[5].
