Sikkerhed i webapps. Target="_blank" sårbarhed

For nylig har vi skrevet om webapplikationssikkerhed, når det gælder XSS-sårbarhed. Denne gang vil vi henlede opmærksomheden på en anden fare.

Sårbarheden, der diskuteres i denne artikel, har været med os i lang tid, og på grund af dens enkelhed er den ofte undervurderet eller endda ukendt af nogle. udviklere af webapplikationer.

Næsten alle webapplikationer indeholder links, som åbner i en ny fane, når der klikkes på dem, så fanen med den oprindelige side ikke lukkes. Dette er en foretrukken adfærd, fordi skaberne ønsker, at brugeren skal bruge så meget tid i applikationen som muligt.

Et angreb, der udnytter denne sårbarhed, er den såkaldte "reverse tabnabbing". Det er et angreb, hvor en side, der er linket til fra målsiden, kan erstatte denne side med f.eks. et phishing-site.

Angrebsscenarie

1. Antag, at offeret bruger Facebook, som er kendt for at åbne links via target="_blank",
2. Opret en falsk viral side,
3. Opret en phishing-hjemmeside, der ligner en Facebook-login-side,
4. Sæt nedenstående Kode på den virale side, f.eks. via en fundet XSS-sårbarhed
   window.opener.location = 'https://phishing-website/facebook.com';
5. Offeret klikker på linket på Facebook til den virale side,
6. Den virale side omdirigerer Facebook-fanen til phishing-webstedet og beder brugeren om at logge ind igen.

Så vi kan ændre den overordnede fane fra den inficerede målside ved hjælp af et vinduesobjekt fra Web API. Et angreb involverer typisk brug af flere opdagede sårbarheder og phishing-svindel parallelt.

Problemet

Når vi åbner en ny fane i browseren ved hjælp af et link med target="_blank" attribut, har vi adgang til vores "referrer" fra den nye fane. Mere specifikt til Åbner egenskab af Vindue objekt, som returnerer en reference til det vindue, der åbnede det, vores overordnede side.

Dette skyldes opførslen af Window.open() funktion. Med adgang til denne attribut kan vi nemt udskifte vores overordnede side. Bemærk, at nogle moderne browsere kan gøre window.opener funktion i målfanen som nul for at forhindre denne adfærd.

Eksempel på kode

<code> <a href="https://github.com" target="_blank">Gå til GitHub - inficeret link</a>
const
 if (link)
   link[0].onclick = () => {
     if (window) window.opener.location = 'https://stackoverflow.com'
   }

Ovenfor kan du se det inficerede link, som oprindeligt åbner en ny fane med en GitHub-side, men i mellemtiden ændrer den vores "overordnede" side til Stackoverflow-siden.

Et levende eksempel

1. HTML-links

Tilføj rel="noopener noreferrer" til <a> tag.

Den rel attributten definerer forholdet mellem en sammenkædet ressource og det aktuelle dokument.

noopener fortæller browseren, at den skal navigere til målet uden at give adgang til den overordnede, der åbnede det. Fanen Mål Vindue.åbner vil være nul.

noreferrer forhindrer, at browseren, når den navigerer til målet, sender adressen eller en anden værdi som referrer til forældrene via Referent HTTP-overskrift. Bemærk, at navnet på denne HTTP-header med vilje er stavet forkert som "referrer".

2. JavaScript Links

Til JavaScript Vindue.åben funktion, kan du tilføje værdierne noopener og noreferrer i windowFeatures parameter i Vindue.åben funktion, men forskellige browsere kan reagere forskelligt, så det anbefales at lave Vindue.åbner som nul efter at have brugt Window.open() funktion.

Læs mere om det:

Rails API og CORS. Et strejf af bevidsthed

Strategier for at hente data i NextJS

7 grunde til, at din webshop har brug for Magento

Hvis du synes, at denne artikel er interessant, så følg Lukasz på Github: https://github.com/twistezo