Internet är beroende av förtroende. När en webbanvändare besöker en webbplats antar de att knapparna de klickar på utför de åtgärder som är märkta för dem. Cyberbrottslingar utvecklar dock ständigt metoder för att utnyttja detta förtroende. En sådan bedräglig metod är clickjacking-attacker .
Clickjacking inträffar när en angripare lurar en användare att klicka på något annat än vad användaren avsåg att klicka på.
Genom att lägga ett transparent lager eller en osynlig iframe ovanpå en legitim sida kan hackare kapa klick som är avsedda för en dummy-knapp eller ofarlig länk. Detta kan leda till allvarliga konsekvenser, såsom nedladdning av skadlig kod , överföring av pengar eller omedvetet gilla-markeringar på en sida på sociala medier.
Om du är en webbplatsägare är det avgörande att förstå detta hot. Den här guiden behandlar mekanismerna bakom denna gränssnittsåtgärdsteknik, hur man upptäcker sårbarheter och de specifika stegen för att säkra din WordPress-webbplats med hjälp av X-Frame-Options-headern och Content Security Policy (CSP).
Förstå Clickjacking-attacker: Riskerna med UI-korrigering
Termen ”clickjacking” är en sammansättning av ”click” och ”hijacking”. I säkerhetskretsar är det formellt känt som en UI-repareringsattack.
Det här namnet beskriver mekanismen perfekt: angriparen ändrar användargränssnittet för att dölja den faktiska målwebbplatsen.
I en vanlig clickjacking-attack skapar angriparen en skadlig sida. Denna sida laddar en riktad sida, vanligtvis en känslig sida som en bankinloggning eller en inställningspanel, i en iframe.
Angriparen ställer in iframen så att den är helt transparent. De placerar sedan sitt eget synliga innehåll, till exempel en videospelare eller ett anspråk på ett gratispris, direkt under eller över den osynliga ramen.
Användaren klickar på vad de tror är en "Spela"-knapp eller en länk för att "Hämta pris". I verkligheten klickar de på den osynliga sidan som laddats från ett annat ursprung.
Eftersom användarens dator och webbläsare fortfarande lagrar sessionscookies för den riktade webbplatsen, autentiseras och behandlas åtgärden omedelbart. Användaren har ingen aning om att de just utfört en högriskåtgärd.
Denna attack utnyttjar webbens förmåga att rama in innehåll. Även om ramar är lämpliga för att bädda in kartor eller videor, blir det farligt när en webbsida inte uttryckligen begränsar vem som kan rama in den.
Utan tillräcklig kontroll kan vilken webbplats som helst bli offer för UI-korrigering.
Läs mer: Verkliga kostnader för WordPress säkerhetsmisstag
Säkra din WordPress-webbplats innan angripare slår till
Skydda din webbplats mot clickjacking och andra hot med Seahawks experttjänster för webbplatsvård.
Hur fungerar Clickjacking-attacker med osynliga iframes och overlays?
För att fullt ut förstå faran måste vi titta på det tekniska utförandet. Kärnan i en clickjacking-attack är beroende av CSS-opacitetsegenskapen.
En angripare bygger en lockbetesajt. Denna webbplats fungerar som lockbete. På den här sidan använder angriparen HTML för att ladda offrets webbsida i en iframe.
Koden kanske ser oskyldig ut, men CSS- koden berättar en annan historia. Angriparen ställer in opaciteten för iframen till 0,0. Detta skapar en osynlig iframe.
Även om det inramade innehållet tekniskt sett finns där, kan användaren inte se det. Angriparen placerar sedan detta osynliga lager exakt över en synlig knapp på sin lockbetesajt.
Tänk dig till exempel att en angripare vill tvinga dig att radera din blogg. De laddar din bloggs sida "Radera konto" i en osynlig iframe. De placerar den osynliga knappen "Radera" direkt över en synlig knapp "Vinn en present" på sin skadliga webbplats.
När användaren klickar på knappen "Vinn en present" passerar klickhändelsen genom de synliga elementen och träffar det övre fönstret i den osynliga ramen. Webbläsaren tolkar detta som ett legitimt klick på "Radera"-knappen. Eftersom användaren troligen är inloggad i samma webbläsare körs kommandot direkt utan användarens vetskap.
Den här metoden gör det möjligt för angripare att kringgå CSRF-tokens (Cross-Site Request Forgery) i vissa fall, eftersom webbläsaren skickar begäran som om användaren fysiskt hade klickat på knappen på den legitima sidan.
Vidare läsning: Hur man använder skydd mot skadlig kod för att skydda din webbplats effektivt
Viktiga typer av klickjackningsattacker och vanliga variationer
Även om den grundläggande overlay-metoden är den vanligaste metoden, finns det flera varianter av clickjacking utformade för att utnyttja specifika beteenden eller webbläsarsårbarheter.
Likejacking: Utnyttjande av interaktioner på sociala medier
Likejacking är en specifik form av clickjacking som riktar sig mot sociala medienätverk. Angriparen strävar efter att manipulera användaren till att "gilla" eller "dela" en sida utan deras samtycke.
I det här scenariot innehåller den osynliga iframen en "Gilla"-knapp på Facebook på Twitter . Angriparen placerar detta transparenta lager över en video eller en bild på en skadlig sida.
När användaren försöker klicka på uppspelning i videon "gilla" de oavsiktligt angriparens sida. Detta ökar den sociala trovärdigheten för skadliga webbplatser och underlättar spridningen av spam eller bedrägerier till användarens vänner.
Kapslade Clickjacking- och X-Frame-Options-sårbarheter
Kapslad clickjacking riktar sig mot webbsidor som försöker använda frame-busting-skript men misslyckas med att implementera dem korrekt. Vissa äldre webbläsare eller specifika konfigurationer gör det möjligt för angripare att förhindra dessa skript.
I den här varianten kapslar angriparen mål-iframen i två olika ramar. Genom att manipulera hur webbläsaren hanterar fönsterplats och navigering förhindrar angriparen att den legitima webbplatsen "bryter sig ut" ur ramen.
Detta belyser varför det inte är bästa praxis att enbart förlita sig på klientsideskript; robusta serversidesrubriker krävs.
Vidare läsning: Förhindra brute force-attacker mot WordPress-webbplatser
CursorJacking, MouseJack och andra vilseledande tekniker
CursorJacking är en mycket vilseledande variant. Här ersätter angriparen den faktiska muspekaren med en falsk anpassad markör. Med hjälp av CSS och JavaScript kompenserar angriparen den riktiga markören från den falska.
Användaren uppfattar att muspekaren svävar över en säker länk. Den faktiska markören (som kan vara osynlig eller förskjuten) svävar dock över ett skadligt element. När användaren klickar sker åtgärden på den riktiga markörens plats, inte på den synliga falska.
På liknande sätt involverar andra tekniker att snabbt flytta den osynliga ramen för att spåra musen (MouseJack), vilket säkerställer att den skadliga knappen alltid är under markören, oavsett vart användaren flyttar den.
Läs mer: Virtuell patchning i WordPress: Hur det fungerar och varför det är viktigt
Hur upptäcker man sårbarheter för klickjackning på sina webbsidor?
Innan du kan förhindra clickjacking måste du kontrollera om din webbplats är sårbar. Lyckligtvis är det enkelt att kontrollera om det finns någon sårbarhet.
Den primära kontrollen innebär att verifiera om din webbsida kan laddas i en iframe från ett annat ursprung. Du kan göra detta genom att skapa en enkel HTML-fil på din lokala dator:
<html> <body> <iframe src="https://yourwebsite.com" width="500" height="500"></iframe> </body> </html>
Öppna den här filen i moderna webbläsare, som Chrome eller Firefox. Om din webbplats laddas korrekt i rutan är du sårbar för clickjacking.
En säker webbplats bör vägra att ansluta eller visa ett tomt utrymme, vilket indikerar att webbläsaren blockerade det inramade innehållet.
Du kan också använda säkerhetsskannrar online eller webbläsartillägg som är utformade för penetrationstester. Dessa verktyg analyserar HTTP-svarshuvudet på din webbplats.
De letar specifikt efter avsaknaden av X-Frame-Options-headern eller Content Security Policy-headern. Om dessa rubriker saknas kommer verktyget att flagga din webbplats som högrisk.
Server-Side Prevention: Använda X-Frame-alternativ för att begränsa inramning
Det mest traditionella och allmänt stödda försvaret mot clickjacking är X-Frame-Options (XFO)-headern. Detta är en svarsrubrik som skickas av webbservern och som talar om för webbläsaren om en sida får renderas i en<frame> ,<iframe> ,<embed> , eller<object> .
När en webbläsare laddar en sida kontrollerar den denna rubrik. Om policyn bryts säkerställer webbläsaren användarens säkerhet genom att inte rendera innehållet.
Det finns tre värden som vanligtvis används med X-Frame-Options-rubriken:
- AVBEVÄRA: Detta är den striktaste inställningen. Den förhindrar att någon domän ramar in den begärda sidan. Även om sidan försöker rama in sig själv kommer det att misslyckas. Detta är idealiskt för en känslig sida som aldrig behöver bäddas in.
- SAMEORIGIN: Detta gör att sidan endast kan ramas in av sidor med exakt samma ursprung (samma domän, protokoll och port). Detta är den vanligaste metoden för att säkra WordPress-webbplatser, eftersom den låter dig bädda in ditt eget innehåll samtidigt som du blockerar externa angripare.
- ALLOW-FROM uri: Detta direktiv är föråldrat och var avsett att tillåta framing från en specifik URI. Det stöds dock inte av många moderna webbläsare och bör generellt undvikas till förmån för nyare standarder.
Att ställa in X-Frame-Options till SAMEORIGIN är ofta tillräckligt för att stoppa de allra flesta clickjacking-attacker. Det säkerställer att en angripare inte kan ladda din inloggningssida på sin lockbetesajt.
XFO har dock begränsningar. Det tillåter i praktiken bara en domän (samma domän) eller ingen alls. Det saknar granularitet om du behöver tillåta flera specifika partners att rama in ditt innehåll. För det behöver vi en mer modern lösning.
Utforska mer: Hur man skapar en lösenordsskyddad sida på WordPress
Avancerat skydd: Innehållssäkerhetspolicy (CSP) och ramförfäder
Även om X-Frame-Options är effektivt, är Content Security Policy (CSP) framtiden för försvar mot clickjacking. CSP är ett säkerhetslager som hjälper till att upptäcka och mildra olika typer av attacker, inklusive Cross-Site Scripting (XSS) och datainjektion.
För att förhindra clickjacking använder vi frame-ancestors-direktivet. Detta direktiv anger vilka föräldrar som får bädda in en sida.
Implementering av direktivet om ramförfader för granulär kontroll
Direktivet frame-ancestors erbjuder mycket mer flexibilitet än X-Frame-Options. Det låter dig definiera en lista över domäner som har tillåtelse att rama in ditt innehåll.
Till exempel kan en rubrik för en Content Security Policy CSP se ut så här:
Innehållssäkerhetspolicy: frame-ancestors 'self' https://trusted-partner.com;
I det här exemplet:
- 'self' fungerar som SAMEORIGIN XFO-direktivet, vilket tillåter samma domän att rama in innehållet.
- https://trusted-partner.com tillåter en specifik extern webbplats att rama in innehållet.
Du kan också använda jokertecken eller tillåta alla HTTPS- scheman med hjälp av "allow from https", även om strikt listning är säkrare. Denna detaljerade kontroll är avgörande för företagswebbplatser som är beroende av integrationer mellan webbplatser.
Varför är CSP-frame-ancestors överlägsna frame-busting-skript?
Tidigare använde utvecklare JavaScript -kod för att bryta frames. Dessa skript kördes på klientsidan och kontrollerade om den översta fönstrets plats matchade den aktuella fönstrets plats. Om inte, försökte de bryta sig ut ur ramen.
Angripare hittade snabbt sätt att neutralisera dessa skript. Webbläsare som Internet Explorer (i äldre versioner) eller funktioner som HTML5-sandboxattributet på iframes kunde blockera körningen av det frame-busting-skriptet, vilket gjorde försvaret oanvändbart.
Frame ancestors och X-Frame-Options är kontroller på serversidan. Angriparen kan inte inaktivera dem eftersom webbläsaren tillämpar regeln innan innehållet renderas. Webbläsaren läser svarsrubriken och vägrar helt enkelt att visa det skadliga sidelementet.
Att använda CSP-frame-ancestors är den nuvarande bästa metoden eftersom den är standardiserad i moderna webbläsare. Även om X-Frame-Options fortfarande är användbart för äldre webbläsare, har frame-ancestors företräde i webbläsare som stöder båda.
Steg för steg: Säkra din WordPress-webbplats mot klickjacking
Att säkra en WordPress-webbplats kräver att du lägger till korrekta rubriker. Du behöver inte vara utvecklare för att implementera dessa ändringar, men det rekommenderas att du alltid säkerhetskopierar din webbplats innan du redigerar serverfiler.
Steg 1: Konfigurera rubriker i .htaccess eller functions.php
Om din WordPress-webbplats körs på en Apache-webbserver kan du redigera .htaccess-filen som finns i din rotkatalog.
För att implementera X-Frame-Options-headern, lägg till den här raden:
<IfModule mod_headers.c>Rubriken lägger alltid till X-Frame-alternativ SAMEORIGIN</IfModule>
Så här implementerar du innehållssäkerhetspolicyn med frame-ancestors:
<IfModule mod_headers.c>Rubriken lägger alltid till Content-Security-Policy "frame-ancestors 'self';"</IfModule>
Den här konfigurationen säkerställer att endast din egen webbplats kan rama in dina sidor. För att tillåta en partner, lägg helt enkelt till deras URL efter "själv".
Alternativt kan du lägga till headers via WordPress functions.php-fil i ditt aktiva tema. Den här metoden fungerar oavsett servertyp ( Apache eller Nginx ) så länge PHP hanterar headers:
function add_security_headers() { header('X-Frame-Options: SAMEORIGIN'); header("Innehållssäkerhetspolicy: frame-ancestors 'self';"); } add_action('send_headers', 'add_security_headers'); } ..
Denna kod kopplas till WordPress headergenereringsprocessen och injicerar skyddsdirektiven för varje webbsida som visas.
Steg 2: Använda WordPress säkerhetsplugins för klientsidesskydd
Om det känns för riskabelt att redigera kod kan du använda WordPress säkerhetsplugins. Många omfattande säkerhetsprogram lägger automatiskt till dessa rubriker.
- Allt-i-ett-säkerhet (AIOS): Detta plugin har specifika inställningar för iframe-skydd. Du kan aktivera "Neka felaktiga frågor" och specifika brandväggsregler som ofta inkluderar hantering av frame-alternativ.
- Headers Security Advanced och HSTS WP: Detta dedikerade plugin låter dig konfigurera specifika HTTP-headers utan att behöva ändra kod. Du kan välja X-Frame-Options från en rullgardinsmeny och ställa in den på SAMEORIGIN.
Även om insticksprogram är praktiska, se till att de konfigurerar svarsrubriken korrekt.
Vissa plugins kanske bara lägger till metataggar , vilka är mindre effektiva för frame-ancestors (CSP via metataggar stöder inte frame-ancestors). Verifiera alltid resultatet med en online header checker.
Slutsats
Hotet om clickjacking är ihållande eftersom det utnyttjar användarens visuella uppfattning snarare än ett programvarufel. Så länge webbläsare stöder iframes kommer angripare att försöka korrigera användargränssnittet.
För en webbplatsägare innebär det att ignorera denna sårbarhet att riskera användarnas säkerhet och webbplatsens rykte. En användare som laddar ner skadlig kod eller förlorar pengar på grund av en knapp på din webbplats kommer att förlora förtroendet för ditt varumärke.
Lösningen är ett försvar i flera skikt.
- Granskning: Skanna regelbundet dina webbsidor för att se om de kan ramas in.
- Implementera XFO: Använd X-Frame-Options-headern inställd på SAMEORIGIN för att skydda användare i äldre webbläsare och andra webbläsare som kanske inte har fullt stöd för CSP.
- Implementera CSP: Anta direktivet för frame-ancestors i Content Security Policy för robust och detaljerad kontroll i moderna webbläsare.
- Övervaka: Använd säkerhetsplugins för att säkerställa att rubrikerna förblir aktiva efter tema- eller serveruppdateringar.
Genom att ta kontroll över hur ditt innehåll utformas, avvecklar du effektivt de osynliga lager som hackare förlitar sig på. Du säkerställer att när en användare klickar, utför de handlingar de avser, vilket skyddar dem från att bli offer för en av webbens mest vilseledande attacker.
Vanliga frågor om en klickjackingattack
Vilken är den vanligaste metoden som används vid en clickjacking-attack?
Den vanligaste metoden innebär att placera dolda lager över en legitim webbsida. En angripare skapar osynliga iframes som lurar användare att klicka på element de inte kan se. Dessa dolda lager gör det möjligt för angripare att utlösa åtgärder utan användarens medvetenhet, vilket potentiellt underlättar deras åtkomst till känsliga funktioner.
Hur hjälper X Frame-alternativ med samma ursprung till att förhindra klickkapning?
Same-origin X-Frame-Options är en svarsrubrik som gör att en sida endast kan ramas in av sidor från exakt samma ursprung. Detta förhindrar att externa domäner bäddar in din webbplats i skadliga ramar och hjälper till att blockera obehöriga interaktioner.
Vad är policyn för frame-ancestors i Content Security Policy?
Policyn för frames ancestors definierar vilka domäner som får bädda in dina webbsidor. Den är en del av policyn för innehållssäkerhet och ger mer kontroll än äldre rubriker. Denna policy är mycket effektiv för att förhindra clickjacking-attacker.
Kan clickjacking-attacker ge angripare tillgång till användarkonton?
Ja, clickjacking kan hjälpa angripare att få indirekt åtkomst till konton. Genom att dölja knappar och åtgärder kan angripare lura användare att ändra inställningar, godkänna behörigheter eller skicka in formulär utan deras vetskap.
Vilket är det bästa sättet att förhindra clickjacking på en WordPress-webbplats?
Det mest effektiva sättet att undvika clickjacking är att använda flera försvar. Ställ in svarshuvudet X-Frame-Options, tillämpa en frame-ancestors-policy och håll WordPress säkerhetsplugins aktiva. Genom att kombinera dessa åtgärder blockeras attacker vid källan.
