Simpelt Javascript forvandler 'åbn i nyt faneblad'-HTML til phishing-monster

Populær måde at åbne nye browsersider på kan blive til farlig phishing med få linjers Javascript.

Du kender det måske: Et klik på et link på eksempelvis Facebook, og et nyt browser-faneblad popper op med link-indholdet, mens du stadig beholder din Facebook-side i det oprindelige faneblad. Men pas på med den slags pop-up-faneblade.

En Javascript-fidus betyder nemlig, at indholdet i det oprindelige faneblad ikke nødvendigvis længere er det samme, som da du klikkede på linket. Med få linjers kode er det nemlig muligt at indlæse en ny side i det oprindelige faneblad, mens brugeren surfer rundt i det nyåbnede faneblad.

Og det kan være skidt i phishing-sammenhæng, da brugeren ikke nødvendigvis er forberedt på, hvis en ny og ondsindet side, der ligner den oprindelige, på den måde bliver indlæst i baggrunden.

Eksempelvis kan www.facebook.com således blive til www.i-cant-believe-its-not-facebook.com - en tænkt, ondsindet side, der eksempelvis forsøger at inficere brugeren eller franarre personlige oplysninger fra vedkommende i en kontekst, der ligner Facebook.

Mest oplagt set fra en angribers perspektiv vil det selvfølgelig være at anvende en url, der ligger tæt op ad den oprindelige, så brugeren har sværest muligt ved at gennemskue, at der er lusk på færde.

Et indlæg af Ben Halpern på udvikler-sitet The Practical Developer belyser problemstillingen.

Den udspringer af brugen af target="_blank" i forbindelse med et link i HTML-koden. Som det vil være nogle bekendt, kan target="_blank" bruges, så et nyt vindue eller faneblad automatisk bliver åbnet, når brugeren klikker på et link.

Men ved at indsætte få linjers Javascript på siden, som linket fører til, er det muligt at få browseren til at indlæse nyt indhold på den oprindelige side med linket.

Javascript-eksemplet, som Ben Halpern bringer, indlæser https://dev.to/phishing på den oprindelige side.

if (window.opener) {
  window.opener.location = "https://dev.to/phishing?referrer="+document.referrer;
}

window.opener returnerer i udgangspunktet en reference til det vindue, der foranledigede åbningen af det nye vindue/faneblad.

document.referrer bruger Ben Halpern til at registrere, hvilke sites der sender brugerne til hans phishing-informationsside.

Facebook-test

Facebook.com er en af de - formodentlig mange - sites, hvor ovenstående teknik i skrivende stund fungerer.

Der ligger en test på Facebook-siden for The Practical Developer, hvor den potentielle sårbarhed kan afprøves. Det foregår ved at klikke på det lille link til https://dev.to/ i højrespalten på Facebook-siden. Og som en læser gør opmærksom på, er det også muligt at teste uhensigtsmæssigheden via første link i denne artikel.

Version2 har testet det i både Firefox, Chrome og Edge. I alle tre browsere indlæses en ny side i det oprindelige faneblad, når brugeren klikker på linket.

I Firefox og Edge bliver der dog ikke indlæst et nyt faneblad, hvis brugeren anvender midterste museknap til at åbne det nye faneblad. I Chrome resulterer et klik på midterste museknap også, at det oprindelige faneblad bliver indlæst med nyt indhold.

Det er forholdsvis enkelt at forhindre, at der bliver læst nyt indhold i det oprindelige faneblad mod brugerens og site-indehaverens vilje. Det gøres ved at indsætte rel="noopener noreferrer" i forbindelse med "_blank"-linket.

“noreferrer” er nødvendigt for, at forebyggelsen også fungerer på Firefox, der ikke understøtter 'noopener', fortæller Halpern.

Med de forebyggende foranstaltninger kunne HTML-koden se sådan ud:

<a href="www.version2.dk" target="_blank" rel="noopener noreferrer">Version2</a>

Da Halpern først skrev blog-indlægget, var det muligt for en ondsindet hjemmeside at udnytte fidusen både i forhold til Instagram og Facebook. Det er ikke længere muligt på Instagram, men stadig en mulighed på Facebook, oplyser Ben Halpern. Og det må formodes, at et hav af andre sites vil være sårbare over for link-fidusen også.

»This is insane«

På Reddit sub-sitet /r/programming udtrykker flere brugere overraskelse over, at det på den måde er muligt for tredjepart at indlæse nyt indhold i et eksisterende faneblad.

En bruger, der kalder sig Rustywolf, skriver eksempelvis:

»How the fuck is the default behaviour of "_blank" links not "noopener" by default? At least if they're not the same domain. This is insane.«

En anden bruger, dom96, skriver:
»Why is this the default behaviour? it seems crazy.«

Og det svarer brugeren Retsam19 med et link til udvikler-sitet StackOverflow. Her er forklaringen, at et nyt vindue kan være en dialogboks til brugerinput.

Det oprindelige vindue kunne så opdateres med indhold, der afspejler bruger-inputtet.

Om den funktionalitet skriver Retsam19:

»I can only assume that the window.opener API dates from a time before phishing attacks were mainstream.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Andy Fischer

Det bør ikke komme som den store overraskelse det lyder som for mange, og vel specielt ikke for Reddit-brugere, som nok jævnligere end andre færdes i internettets udkantsområder. Metoden har været anvendt intenst på mange pirat-sites gennem flere år.

  • 2
  • 1
#5 Lars Smidt

Jeg har oplevet det ved login på ing.dk Hvis siden oprindeligt er indlæst fra et link på en anden side (feks fra min http://feedly.com/ rss side) så er bliver det oprindelige vindue (feedly) redirected til ing når jeg logger ind på den nye side med ing.dk og den nye side lukker...

Er det en feature på ing eller en utilsigtet handling?

  • 0
  • 0
#6 Henrik Pedersen

Pornosider er rigtigt gode til at bruge det her trick også. Det er næsten umuligt at blokere totalt for alle deres popups på kryds og tværs, hvis man også ønsker at bevare sidens funktionalitet. En del sider bruger dog popups som kun åbner én gang pr. visit. Nice!

Det er næsten blevet en vane når man er på besøg at den første tab som åbner, den blive CMD+W'ed eller ramt med musen næsten pr. refleks.

Rigtig mange sider bruger teknikken at de åbner det link du forsøger at besøge på den nye tab (i popup vinduet), og så redirecter den originale tab du sidder på, til reklamen. Det "straffer" folk som har indlært den rytme med at auto-lukke popup, og tvinger dem til at blive på indholdet.

Jeg har også bemærket en ny trend hvor jeg mistænker dem for at blokere indlæsningen af links på siden, indtil det nye vindue er åbnet op, og så laver får den den originale side til at indlæse det den skal.

Jeg er sikker på de bruger denne teknik flittigt i de her scenarier, hvis ikke flere andre kreative.

  • 2
  • 0
#7 Lasse Mølgaard

Når vi nu snakker bugs vs feature...

Jeg kan tilføje, at når man bruger mobiltelefonen til at logger ind på v2.dk via Facebook, så bliver man først sendt videre til en v2 "siden findes ikke". Hvis man derefter trykker på tilbageknappen, så er man nu logget ind.

...Mon det er referer-delen der driller? :-)

  • 1
  • 0
#8 Jesper Kristensen

HTML blev lavet en gang man ikke kendte til alle disse sikkerheds-issues, og da det skal være bagudkompatibelt, har man lukket de fleste af sikkerhedshullerne med opt-ins.

Husker du at sætte rel="noopener" på alle dine eksterne links, at sætte Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy og Strict-Transport-Security headersne på alle responses (også fejlsiderne), at navngive alle dine cookies så de starter med __Host- eller __Secure-, at sørge for at alle dine JSON API'er har et objekt som top-level (modsat fx en array), at kræve xsrf-token på alle relevante handlinger og billeder, at levere bruger-uploadede filer fra et separat domæne, osv?

Listen over små obskure ting man skal huske er lang, endda inden man når til de klassiske nødvendige sikkerhedsdyder som fx input validering, encoding og adgangskontrol.

  • 0
  • 0
#9 Rune Jensen

Hvis man bruger

content-security-policy: self

...virker det så stadig?

Denne policy betyder, at man skal sende en nonce af alt javascript indhold i HTTP headeren, og at kun eksternt JS-indhold, som kommer fra denne samme side/domæne bliver udført (dvs. IKKE inline JS heller) - og kun HVIS der er denne nonce og hvis den passer til indholdet.

Det betyder også, at man ikke kan ændre i den javascript, som siden selv præsenterer, for så vil noncen ikke længere være korrekt. Så ikke bare skal javascripten være fra selv samme domæne, det skal også være uændret, ellers udføres det ikke.

Jeg kører med en random nonce på inline scripts, hvilket ikke er tilrådeligt uanset. Alt javascript skal lægges eksternt. Men det er en måde at lære.

http://www.html5rocks.com/en/tutorials/security/content-security-policy/

Og jeg er først lige begyndt at bruge den policy for nyligt, så jeg er overhovedet ikke ekspert i det. Men de tests, jeg har lavet, lader til at virke. Loggen (i browserens web developer del) fortæller, hvis man ikke gør det korrekt. Og man får også advarsel, via W3C validatoren, hvis der er problemer.

Men anyways... Det interessante er, om man kan slippe om det nævnte problem ved at sætte en over all header. Jeg mener under alle omstændigheder man bør sætte denne header, da den gør, hvad alle browsere brude gøre fra starten.

  • 0
  • 0
Log ind eller Opret konto for at kommentere