clickjacking

Clickjacking to atak, w którym przestępca nakłada na siebie przezroczyste albo nieprzezroczyste warstwy strony, tak by użytkownik kliknął przycisk lub link na innej stronie niż ta, którą widzi ^[1]. OWASP podaje drugą nazwę tego ataku: UI redress attack ^[1]. MITRE opisuje go jako słabość CWE-1021, w której aplikacja webowa nie ogranicza albo błędnie ogranicza ramki i warstwy interfejsu należące do innej aplikacji lub domeny ^[2]. Ofiara wykonuje wtedy działanie ukryte przed jej wzrokiem, zwykle na koncie, na którym jest zalogowana.

Jak działa

Atakujący przygotowuje stronę-przynętę, na przykład z grą albo przyciskiem odbioru nagrody. Pod nią, w niewidocznej ramce iframe, ładuje witrynę docelową, na której ofiara ma aktywną sesję. Przycisk przynęty leży dokładnie nad przyciskiem w ukrytej ramce. Ofiara klika to, co widzi, a przeglądarka przekazuje kliknięcie do ramki. MITRE opisuje skutek wprost: atakujący może skłonić użytkownika do działań zamaskowanych i ukrytych przed jego wzrokiem ^[2].

Przebieg ataku na zalogowanego użytkownika pokazuje schemat poniżej.

RYS. 1Kliknięcie przechwycone przez ukrytą ramkę

Mechanizm przypomina CSRF (Cross-Site Request Forgery): w obu przypadkach przeglądarka ofiary wysyła żądanie z jej ciasteczkami. Różnica polega na tym, że w clickjackingu żądanie wywołuje sama ofiara prawdziwym kliknięciem na prawdziwej stronie. Dlatego zabezpieczenia oparte na tokenach nonce nie wystarczają, bo formularz w ramce ma poprawny token. Atak jest odmianą socjotechniki: wykorzystuje zaufanie do tego, co widać na ekranie.

Odmiany

Ta sama technika służy do przechwytywania nie tylko kliknięć. OWASP opisuje wariant, w którym odpowiednie połączenie arkuszy stylów, ramek i pól tekstowych skłania ofiarę do wpisania danych logowania do ramki kontrolowanej przez atakującego ^[1]. MITRE wymienia jako inne nazwy tej samej słabości UI redress attack i tapjacking, czyli wariant na urządzeniach mobilnych, gdzie użytkownik stuka w ekran zamiast klikać ^[2].

W WordPressie

Rdzeń WordPressa ma wbudowaną ochronę ekranów, które są najcenniejszym celem. Funkcja send_frame_options_header() wysyła nagłówek X-Frame-Options: SAMEORIGIN oraz nagłówek CSP z dyrektywą frame-ancestors 'self', co ogranicza wyświetlanie strony do ramek z tego samego pochodzenia ^[5]. Funkcja istnieje od wersji 3.1.3 ^[5]. W kodzie rdzenia jest podpięta do akcji login_init, czyli do ekranu logowania ^[6], oraz do akcji admin_init, czyli do panelu administracyjnego ^[7].

Ochrona rdzenia jest podpięta tylko do tych dwóch akcji ^{[6] [7]}, więc nie obejmuje stron publicznych ani ekranów, które wtyczka buduje poza panelem. Formularze konta klienta w sklepie, profile użytkowników czy własne strony logowania mogą być osadzane w obcych ramkach, jeśli serwer nie wysyła odpowiedniego nagłówka. Tu pomagają nagłówki bezpieczeństwa HTTP ustawione na serwerze, w pliku konfiguracji, przez zabezpieczenia w .htaccess albo przez wtyczkę bezpieczeństwa.

Skutki zależą od tego, czyje konto zostanie użyte. Kliknięcie administratora w ukrytej ramce może zmienić ustawienia albo nadać komuś wyższą rolę, dlatego znaczenie mają role i uprawnienia użytkowników. Kliknięcie klienta sklepu może zmienić adres dostawy lub dane konta, co otwiera drogę do przejęcia konta.

Zagrożenia i skutki

MITRE zaznacza, że skutek zależy od aplikacji; w serwisie społecznościowym atak może na przykład zmienić ustawienia prywatności bez wiedzy użytkownika ^[2]. OWASP opisuje kilka znanych przypadków ^[1]:

• strona ustawień wtyczki Adobe Flash załadowana w niewidocznej ramce, przez którą ofiary zmieniały ustawienia zabezpieczeń Flasha ^[1];
• robak w serwisie Twitter, który skłaniał użytkowników do kliknięcia przycisku udostępniającego adres złośliwej strony i rozprzestrzenił się masowo ^[1];
• likejacking w serwisie Facebook, czyli nakłanianie zalogowanych użytkowników do polubienia stron, linków i grup ^[1].

Sam clickjacking rzadko daje atakującemu pełną kontrolę nad serwisem. Bywa jednak ogniwem łańcucha: jedno kliknięcie może zatwierdzić zmianę, która dalej ułatwia XSS (Cross-Site Scripting) albo inny atak.

Jak się bronić

Podstawą jest zakazanie osadzania strony w obcych ramkach nagłówkiem odpowiedzi HTTP. OWASP uważa nagłówki za skuteczniejsze od obrony w JavaScripcie ^[3].

• CSP frame-ancestors. Dyrektywa CSP (Content Security Policy) pozwala wskazać wiele dozwolonych domen zwykłą składnią Content Security Policy ^[3]. Wartość 'none' blokuje każde osadzenie, a 'self' pozwala tylko na ramki z tej samej witryny ^[3].
• X-Frame-Options. MDN opisuje nagłówek jako sposób na uniknięcie clickjackingu przez zapewnienie, że treść nie jest osadzana w innych witrynach ^[4]. Wartość DENY blokuje każde osadzenie, a SAMEORIGIN pozwala na nie tylko wtedy, gdy wszystkie ramki nadrzędne mają to samo pochodzenie ^[4]. Dyrektywa ALLOW-FROM jest przestarzała, a nowoczesne przeglądarki, które ją napotkają, ignorują cały nagłówek ^[4].
• Ciasteczka SameSite. Ciasteczka z atrybutem SameSite ustawionym na Strict albo Lax nie są dołączane do żądań strony załadowanej w ramce, co utrudnia clickjacking na zalogowanego użytkownika ^[3]. Opis atrybutów zawiera hasło flagi ciasteczek.
• Skrypty frame-busting. Stare skrypty wyrywające stronę z ramki mają znane obejścia: podwójne osadzanie, obsługę zdarzenia onBeforeUnload i atrybut sandbox ^[3]. MITRE także wskazuje ich ograniczenia wobec zagnieżdżonych ramek ^[2].

Przykładowa konfiguracja serwera Apache:

Header always set X-Frame-Options "SAMEORIGIN"
Header always set Content-Security-Policy "frame-ancestors 'self'"

Jeśli witryna ma już politykę CSP, dyrektywę frame-ancestors dopisuje się do istniejącej polityki zamiast wysyłać drugi nagłówek.

Historia i przykłady

Brak ochrony przed clickjackingiem wciąż pojawia się w komunikatach o podatnościach. CERT Polska 2 marca 2026 roku opublikował informację o ośmiu podatnościach w oprogramowaniu CGM CLININET i CGM NETRAAD ^[8]. Według komunikatu aplikacja CGM CLININET nie implementowała żadnych mechanizmów zapobiegających clickjackingowi: nie wykryto nagłówków bezpieczeństwa HTTP ani zabezpieczeń przed osadzaniem w ramkach ^[8]. Ta sama publikacja opisuje między innymi SQL injection i brak uwierzytelnienia w tych systemach ^[8], każdy błąd z własnym numerem CVE.