Defaults.Exposed › Rettelser › Clickjacking-beskyttelse (X-Frame-Options)

Sådan retter du Clickjacking-beskyttelse (X-Frame-Options)

En ét-linjes instruktion der siger til browsere, at andre hjemmesider ikke hemmeligt må indlæse din side inde i deres egne. Uden den kan en svindler skjule dine rigtige, indloggede sider bag en falsk side og narre dine kunder til at klikke på ting, de aldrig mente at klikke på — godkende en betaling, ændre en adgangskode, give adgang.

Det korte svar for din virksomhed: En svindler kan usynligt pakke din live-hjemmeside ind i en falsk og stjæle penge eller kontoadgang fra dine indloggede kunder — og for kunden ser det ud som om din side gjorde det. Fikset er gratis og tager en udvikler cirka 15 minutter; at lade det stå ude er et kendt hul, som både kriminelle og påpasselige købere kan spotte på sekunder.

Hvad dette kan koste dig

• En svindler skjuler din rigtige login- eller betalingsskærm bag en harmløs-udseende side og narrer en kunde til 'at bekræfte' en overførsel eller en indstillingsændring uden at indse det — kunden bebrejder dig, ikke angriberen.
• Dit indloggede kontooverblik indlæses usynligt oven på en 'Du har vundet — klik for at gøre krav'-side; klikket godkender faktisk en reel ændring på kundens konto, og du håndterer det vrede supportopkald.
• En prospects IT-team kører en hurtig sikkerhedsscanning inden underskrift, ser at din side kan integreres af hvem som helst, og flagger det som en risiko der staller eller dræber aftalen.
• Dit brand bliver agnet i en svindel-kampagne; kunder der er fanget husker det som 'virksomheden, hvis side lod det ske'.
• En revisors eller cyber-forsikringsscanning lister manglende clickjacking-beskyttelse som en grundlæggende hygiejnefejl — billig at fikse, pinlig at have flagget.

Hvorfor det betyder noget. Dette er en gratis, ét-linjes indstilling der tager minutter at tilføje, og den lukker en hel klasse af snyd rettet mod dine indloggede kunder. På vores scoring er det et reelle-point-websikkerhedscheck rated høj alvorlighed, fordi et manglende header efterlader et kendt, nemt-tjekket hul, som kriminelle automatiserer og købere kigger efter.

Hvad dette er på klart dansk

Når nogen besøger din hjemmeside, kan deres browser også beordres til at indlæse din side inde i en anden hjemmeside — som et lille vindue integreret inde i en større side. Det lyder harmløst, og nogle gange er det det. Men det er mekanismen bag et angreb kaldet clickjacking.

Her er tricket. En svindler bygger sin egen side og indlæser stille din rigtige hjemmeside inde i den — usynlig, gjort fuldstændig gennemsigtig. Derefter lægger de sit eget indhold ovenpå: en flashy knap, en “Se video”, et “Kræv din præmie.” Din kunde ser angriberens side og klikker på, hvad der ligner en harmløs knap. Men fordi din rigtige side sidder usynligt under sin markør, lander klikket faktisk på din side — bekræfter en betaling, ændrer en adgangskode, godkender adgang, accepterer en tilladelse. Kunden tror, de klikkede én ting; de klikkede faktisk en anden, på en side de stoler på.

Clickjacking-beskyttelse er en kort, usynlig instruktion din hjemmeside sender til enhver besøgendes browser der i bund og grund siger:

“Lad ikke andre hjemmesider indlæse mig inde i dem. Forsøger nogen, nægt.”

Hvad dette kan koste dig

1. Den usynlige “bekræft.” En kunde er indlogget på dit kontoportal i én fane. De lander på en side (fra en annonce, en e-mail, et søgeresultat) der lover noget fristende og viser en stor “Fortsæt”-knap. Skjult under den knap er din rigtige “Bekræft overførsel” eller “Skift e-mail”-kontrol, indlæst fra deres eget indloggede session. De klikker “Fortsæt” — og godkender uvidende en ændring på deres faktiske konto hos dig.

2. Indstillingskapringstoget. En angriber integrerer din kontosindstillingsside og lægger et uskyldigt spil eller en undersøgelse ovenpå. Et par klik på de rigtige steder sætter stille en indstilling — tilføjer angriberens e-mail som en gendannelsesadresse, giver en app tilladelse eller deaktiverer en sikkerhedsadvarsel.

3. Aftalen der staller. En større kunde sender sit standard-sikkerhedsspørgeskema inden underskrift. En linje spørger, om din side sætter anti-framing-beskyttelse (X-Frame-Options / CSP frame-ancestors). Din IT-kontakt er nødt til at svare “nej.”

4. Brand-som-lokkemad-kampagnen. Fordi dine rigtige, betroede sider kan integreres, bruger en angriber dit login eller din checkout som det overbevisende lag i en bredere phishing-kampagne.

5. Revisionsflaget. En forsikrers scanning, eller en revisor, lister manglende clickjacking-beskyttelse blandt fundene.

Hvad det faktisk er

Clickjacking-beskyttelse leveres via svar-headers. Der er to, og vores tjek består, hvis nogen er til stede:

1. Det ældre header — X-Frame-Options:

X-Frame-Options: SAMEORIGIN

Det tager en af to praktiske værdier:

• SAMEORIGIN — din egen side må integrere sine egne sider, men ingen udenfor-side kan. Den sikre standard for næsten alle.
• DENY — ingen må integrere dine sider, inklusive dig selv.

2. Det moderne header — Content-Security-Policy frame-ancestors:

Content-Security-Policy: frame-ancestors 'self';

Dette er den nyere, mere fleksible kontrol:

• frame-ancestors 'self' — ækvivalent med SAMEORIGIN.
• frame-ancestors 'none' — ækvivalent med DENY.
• frame-ancestors 'self' https://partner.eksempel.com — din egen side plus én navngiven, betroet partner.

Hvad “godt” ser ud som

Den stærkeste opsætning bruger begge: frame-ancestors for moderne browsere og X-Frame-Options: SAMEORIGIN som fallback for ældre klienter. Vores tjek er tilfreds med en af dem alene.

Én vigtig detalje: et Content-Security-Policy-Report-Only-header håndhæver ikke noget — det rapporterer kun.

Sådan fikser du det (gratis, ~15 minutter)

Overrækk dette afsnit til den der kører din hjemmeside — din IT-person, webudvikler eller hostingsupport. Fikset er gratis.

Trin 1 — Beslut, hvor strengt du vil være

• De fleste virksomheder: SAMEORIGIN / frame-ancestors 'self'.
• Hvis din side aldrig integrerer sine egne sider: DENY / frame-ancestors 'none'.
• Hvis en ægte partner skal integrere en specifik side: navngiv dem eksplicit.

Trin 2 — Tilføj headers (vælg din platform)

Nginx — inde i din server-blok:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "frame-ancestors 'self';" always;

Apache — sørg for at mod_headers er aktiveret:

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

Microsoft IIS — i web.config inde i <customHeaders>:

<add name="X-Frame-Options" value="SAMEORIGIN" />
<add name="Content-Security-Policy" value="frame-ancestors 'self';" />

Cloudflare (eller lignende CDN): gå til Rules → Transform Rules → Modify Response Header, og tilføj to regler.

Sender du allerede en Content-Security-Policy af andre årsager? Opret ikke et andet CSP-header — tilføj frame-ancestors til din eksisterende politik.

Trin 3 — Genindlæs og verificér

Genindlæs webserveren eller deployér CDN-reglen, indlæs derefter din live side og tjek svar-headers — browser-devtools → Network-fanen → klik på sideforespørgslen → Svar-headers.

Almindelige fejl

• At bruge en report-only CSP og antage, at det beskytter dig. Content-Security-Policy-Report-Only rapporterer kun overtrædelser — det håndhæver ingenting.
• At sætte to separate Content-Security-Policy-headers. Har du allerede en CSP, tilføj frame-ancestors til den.
• At sætte DENY når din egen side integrerer sine egne sider. DENY blokerer al framing, inklusive din egen.
• At kun beskytte forsiden. De sider der er vigtigst for clickjacking, er de indloggede — kontosindstillinger, betalingsbekræftelse, admin. Sørg for at headers anvendes på hele sitet.
• At antage at HTTPS eller låsen allerede dækker dette. Kryptering og anti-framing er usammenhængende. Et perfekt certifikat gør intet for at stoppe dine sider i at blive integreret.

FAQ