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

Slik fikser du Clickjacking-beskyttelse (X-Frame-Options)

En en-linje instruksjon som forteller nettlesere å ikke la andre nettsteder hemmelig laste inn siden din inne i sin egen. Uten den kan en svindler skjule ekte, innloggede sider bak en falsk side og lure kundene dine til å klikke på ting de aldri hadde til hensikt — godkjenne en betaling, endre et passord, gi tilgang.

Bunnlinjen for virksomheten din: En svindler kan usynlig pakke inn nettstedet ditt inne i et falskt og stjele penger eller kontotilgang fra de innloggede kundene dine — og for kunden ser det ut som om siden din gjorde det. Fiksen er gratis og tar en utvikler omtrent 15 minutter; å la det stå av er et kjent gap som både kriminelle og forsiktige kjøpere kan oppdage på sekunder.

Hva dette kan koste deg

• En svindler skjuler den ekte innloggings- eller betalingsskjermen bak en uskyldig-utseende side og lurer en kunde til å 'bekrefte' en overføring eller en innstillingsendring uten å innse det — kunden skyldte deg, ikke angriperen.
• Den innloggede kontoareal lastes usynlig på toppen av en 'Du har vunnet — klikk for å hente'-side; klikket godkjenner faktisk en ekte endring på kundens konto med deg, og du mottar den sinte supportsamtalen.
• Et prospekts IT-team kjører en rask sikkerhetsskanning før de signerer, ser at siden din kan bygges inn av hvem som helst, og flagget det som en risiko som staller eller dreper avtalen.
• Merket ditt blir agnet i en svindelkampanje; kunder som ble lurt husker det som 'selskapet hvis side lot det skje'.
• En revisor- eller nettforsikringsskanning lister manglende clickjacking-beskyttelse som et grunnleggende hygienefeil — billig å fikse, flaut å ha flagget.

Hvorfor det er viktig. Dette er en gratis, en-linje innstilling som tar minutter å legge til, og den stenger ned en hel klasse av lureri rettet mot innloggede kunder. I scoringen vår er det verdt-reelle-poeng web-sikkerhetssjekk vurdert som høy alvorlighetsgrad, fordi en manglende topptekst etterlater et kjent, lett-sjekkbart hull som kriminelle automatiserer og kjøpere ser etter.

Hva dette er, i enkle ord

Når noen besøker nettstedet ditt, kan nettleseren deres også bli bedt om å laste siden din inne i et annet nettsted — som et lite vindu innebygd inne i en større side. Det høres uskyldig ut, og noen ganger er det det. Men det er mekanismen bak et angrep kalt clickjacking.

Her er tricket. En svindler bygger sin egen side og laster stille inn ditt ekte nettsted inne i den — usynlig, gjort helt gjennomsiktig. Deretter legger de sitt eget innhold oppå: en blinkende knapp, en «Spill video», en «Hent premien din». Kunden ser angripeliges side og klikker det som ser ut som en uskyldig knapp. Men fordi den ekte siden din sitter usynlig under markøren, lander klikket på siden din — bekrefter en betaling, endrer et passord, godkjenner tilgang, godtar en tillatelse. Kunden tror de klikket én ting; de klikket faktisk en annen, på en side de stoler på.

Clickjacking-beskyttelse er en kort, usynlig instruksjon nettstedet ditt sender til alle besøkeres nettlesere som sier, i praksis:

«Ikke la andre nettsteder laste meg inn i dem. Hvis noen prøver, avvis.»

Moderne nettlesere adlyder dette automatisk. Med det slått på fungerer tricket rett og slett ikke — den innebygde kopien av siden din nekter å laste. Uten det er siden din rettmessig mål til å brukes som det skjulte laget i en svindel, og kunden som blir fanget vil assosiere hele greia med merket ditt, ikke angripeliges.

Hva dette kan koste deg

Dette er realistiske, hverdagsscenarioer. Vi nevner aldri en ekte virksomhet; disse er illustrasjoner på hvordan gapet brukes.

1. Den usynlige «bekreft». En kunde er innlogget på kontoportalen din i en fane. De lander på en side (fra en annonse, en e-post, et søkeresultat) som lover noe fristende og viser en stor «Fortsett»-knapp. Skjult under den knappen er den ekte «Bekreft overføring» eller «Endre e-post»-kontrollen din, lastet inn fra sin egen innloggede økt. De klikker «Fortsett» — og godkjenner ubevisst en endring på den ekte kontoen sin med deg. For dem, og for supportteamet ditt, ser det ut som de gjorde det på siden din.

2. Innstillingskapet. En angriper innrammer kontostyrings-siden din og legger et uskyldig spill eller en undersøkelse over. Noen klikk på riktige steder flipper stille en innstilling — legger til angripeliges e-post som en gjenopprettingsadresse, gir en app tillatelse, eller deaktiverer et sikkerhetsvarsel. Kontoen er nå stille kompromittert, og ingenting så feil ut på tidspunktet.

3. Avtalen som staller. En større kunde sender standard sikkerhets-spørreskjema før de signerer. Én linje spør om nettstedet ditt setter anti-innramming-beskyttelse (X-Frame-Options / CSP frame-ancestors). IT-kontakten din må svare «nei», og innkjøp pauser mens du haster for å fikse en gratis, 15-minutters innstilling som nå ser ut som et rødt flagg foran en kjøper.

4. Merket-som-agn-kampanjen. Fordi de ekte, betrodde sidene dine kan bygges inn, bruker en angriper påloggingen din eller kassen som det overbevisende laget i en bredere phishing-kampanje. Kundene som blir fanget skylder ikke på den skumle angriperen — de husker det som gangen «siden din» lot dem bli svindlet.

5. Revisjonsflagget. En forsikrers skanning, eller en revisor som gjennomgår sikkerhetsposturet ditt, lister manglende clickjacking-beskyttelse blant funnene. Det er en standard grunnleggende hygienepunkt; å ha det flagget signaliserer at de enkle, gratis beskyttelsene ikke var på plass — noe som farger hvordan resten av sikkerheten din bedømmes.

Gjennomgangstemaet: skaden lander på en ekte, innlogget kunde som gjør noe de ikke hadde til hensikt — og det bærer ditt navn, ikke angripeliges.

Hva det faktisk er

Når en nettleser ber nettstedet ditt om en side, sender serveren tilbake siden pluss noen usynlige «topptekster» — ekstra instruksjoner nettleseren leser, men den besøkende aldri ser. Clickjacking-beskyttelse leveres gjennom disse topptekstene. Det er to, og sjekken vår bestås hvis enten er til stede:

1. Den eldre toppteksten — X-Frame-Options:

X-Frame-Options: SAMEORIGIN

Dette er den langstående, mye-støttede kontrollen. Den tar én av to praktiske verdier:

• SAMEORIGIN — nettstedet ditt kan bygge inn egne sider, men ingen utenforstående kan. Den trygge standarden for nesten alle.
• DENY — ingen kan bygge inn sidene dine, inkludert deg. Bruk dette bare hvis nettstedet aldri innrammer eget innhold.

2. Den moderne toppteksten — Content-Security-Policy frame-ancestors:

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

Dette er den nyere, mer fleksible kontrollen og den gjeldende standarder peker på. Den gjør det samme, men lar deg være presis om hvem som kan bygge deg inn:

• frame-ancestors 'self' — tilsvarende SAMEORIGIN.
• frame-ancestors 'none' — tilsvarende DENY.
• frame-ancestors 'self' https://partner.eksempel.com — din egen side pluss én navngitt, betrodd partner, og ingen andre.

Hva «bra» ser ut som

Det sterkeste oppsettet bruker begge: frame-ancestors for moderne nettlesere (og for presisjonen av å navngi tillatte innbyggere) og X-Frame-Options: SAMEORIGIN som reserveordning for eldre klienter. Sjekken vår er fornøyd med enten én alene — men siden begge er gratis og tar de samme noen minuttene, er det ingen grunn til å ikke sette begge.

Én viktig detalj utvikleren bør vite: en Content-Security-Policy-Report-Only-topptekst håndhever ingenting — den rapporterer bare. Hvis du vil at clickjacking-beskyttelse faktisk skal tre i kraft, må det komme fra en håndhevende topptekst (en normal Content-Security-Policy med frame-ancestors, eller X-Frame-Options), ikke en kun-rapport.

Slik fikser du det (gratis, ~15 minutter)

Send denne seksjonen til den som driver nettstedet — IT-personen, webutvikleren eller webhotellets support. Fiksen er gratis. Det er én eller to svarhodet, eller en regel i CDN-en. Det er ingenting å kjøpe.

Sjekken bestås når enten en X-Frame-Options-topptekst (satt til DENY eller SAMEORIGIN) eller en CSP frame-ancestors-direktiv er til stede. Det anbefalte belt-og-bukseseler-oppsettet legger til begge.

Steg 1 — Bestem hvor streng du vil være

• De fleste virksomheter: SAMEORIGIN / frame-ancestors 'self'. Din egen side fortsetter å fungere; utenforstående blokkeres.
• Hvis siden aldri bygger inn egne sider: DENY / frame-ancestors 'none' for maksimal låsing.
• Hvis en genuin partner må bygge inn en bestemt side: navngi dem eksplisitt med frame-ancestors 'self' https://partner.eksempel.com; og ingen andre slipper inn.

Steg 2 — Legg til topptekstene (velg plattform)

Nginx — inne i server-blokken:

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

Apache — sørg for at mod_headers er aktivert, og i den virtuelle verten:

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

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

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

Cloudflare (eller lignende CDN): gå til Regler → Transformasjonsregler → Modifiser svarhodet, og legg til to regler som setter X-Frame-Options til SAMEORIGIN og Content-Security-Policy til frame-ancestors 'self'; på alle svar. Dette er den enkleste ruten hvis du ikke har direkte serverilgang.

Allerede sender en Content-Security-Policy av andre grunner? Ikke opprett en andre CSP-topptekst — legg til frame-ancestors i den eksisterende policyen. To CSP-topptekster kan komme i konflikt.

Nettstedsbyggere (Squarespace, Wix, Shopify og lignende): disse plattformene setter ofte anti-innramming-beskyttelse for deg, så du er kanskje allerede godkjent uten å gjøre noe. Sjekken vår vil flagge det hvis ikke, og kontrollen er vanligvis i plattformens sikkerhetsinnstillinger.

Steg 3 — Last inn på nytt og verifiser

Last inn nettserveren på nytt eller distribuer CDN-regelen, og last deretter inn den live siden og sjekk svarhodene — nettleser-utviklerverktøy → Nettverk-fanen → klikk sideforespørselen → Svarhodet, eller et gratis topptekst-kontrollverktøy. Bekreft at toppteksten(e) vises på ekte siderespons, ikke bare hjemmesiden. Kjør deretter sjekken på nytt.

Vanlige feil

• Bruke en kun-rapport CSP og anta at det beskytter deg. Content-Security-Policy-Report-Only rapporterer bare brudd — det håndhever ingenting. Du trenger en håndhevende topptekst for at beskyttelsen skal tre i kraft.
• Sette to separate Content-Security-Policy-topptekster. Hvis du allerede har en CSP, legg til frame-ancestors i den i stedet for å sende en andre policy; motstridende CSP-topptekster kan produsere uventet atferd.
• Sette DENY når nettstedet ditt bygger inn egne sider. DENY blokkerer all innrammering, inkludert din egen. Hvis noen del av siden bruker iframes av seg selv, bruk SAMEORIGIN / frame-ancestors 'self' i stedet, ellers vil du bryte dine egne sider.
• Bare beskytte hjemmesiden. Sidene som betyr mest for clickjacking er de innloggede — kontoinnstillinger, betalingsbekreftelse, admin. Sørg for at topptekstene brukes nettsted-bredt, ikke bare på forsiden.
• Anta at HTTPS eller hengelåsen allerede dekker dette. Kryptering og anti-innrammering er urelaterte. Et perfekt sertifikat gjør ingenting for å stoppe sidene dine fra å bygges inn.
• Stole på gamle løsninger. «Frame-busting» JavaScript (skript som prøver å bryte ut av rammer) er upålitelig og kan omgås. Topptekstene er den korrekte, nettleserhåndhevede fiksen.

FAQ