Beveiliging van webapps. Target="_blank" kwetsbaarheid

Onlangs hebben we geschreven over beveiliging van webapplicaties als het gaat om XSS-kwetsbaarheid. Deze keer willen we jullie aandacht vestigen op een ander gevaar.

De kwetsbaarheid die in dit document wordt besproken, bestaat al heel lang en wordt door zijn eenvoud vaak onderschat of is zelfs onbekend bij sommigen. ontwikkelaars van webtoepassingen.

Bijna elke webapplicatie bevat links die, wanneer erop geklikt wordt, openen in een nieuw tabblad zodat het tabblad met de originele pagina niet gesloten wordt. Dit is een voorkeursgedrag omdat de makers willen dat de gebruiker zoveel mogelijk tijd doorbrengt in de applicatie.

Een aanval die misbruik maakt van deze kwetsbaarheid is het zogenaamde "reverse tabnabbing". Het is een aanval waarbij een pagina waarnaar wordt gelinkt vanaf de doelpagina in staat is om die pagina te vervangen door bijvoorbeeld een phishingsite.

Aanvalsscenario

1. Stel dat het slachtoffer Facebook gebruikt, wat bekend staat om het openen van links via target="_blank",
2. Maak een valse virale pagina,
3. Maak een phishing-website die eruitziet als een Facebook-inlogpagina,
4. Zet de onderstaande code op de virale pagina, bijvoorbeeld via een gevonden XSS-kwetsbaarheid
   window.opener.location = 'https://phishing-website/facebook.com';
5. Het slachtoffer klikt op de link op Facebook naar de virale pagina,
6. De virale pagina leidt het Facebook-tabblad om naar de phishingwebsite en vraagt de gebruiker om zich opnieuw aan te melden.

We kunnen dus het bovenliggende tabblad van de geïnfecteerde doelpagina wijzigen met behulp van een vensterobject van Web API. Bij een aanval worden meestal meerdere ontdekte kwetsbaarheden en phishing-zwendel tegelijk gebruikt.

Het probleem

Als we een nieuw tabblad in de browser openen via een koppeling met de doel="_blank attribuut hebben we toegang tot onze "verwijzer" van het nieuwe tabblad. Meer specifiek, tot de opener eigenschap van de Venster object, dat een verwijzing teruggeeft naar het venster dat het heeft geopend, onze bovenliggende pagina.

Dit komt door het gedrag van de Venster.open() functie. Met toegang tot dit attribuut kunnen we eenvoudig onze bovenliggende pagina vervangen. Merk op dat sommige moderne browsers window.opener functie in doel tab als nul om dit gedrag te voorkomen.

Voorbeeldcode

<code> <a href="https://github.com" target="_blank">Ga naar GitHub - geïnfecteerde link</a>
const
 als (link)
   link[0].onclick = () => {
     if (window) window.opener.location = 'https://stackoverflow.com'
   }

Hierboven kun je de geïnfecteerde link zien die oorspronkelijk een nieuw tabblad opent met een GitHub pagina, maar ondertussen verandert het onze "bovenliggende" pagina naar de Stackoverflow site.

Live voorbeeld

1. HTML-koppelingen

Voeg toe rel="noopener noreferrer" naar de <a> tag.

De rel attribuut definieert de relatie tussen een gelinkte bron en het huidige document.

noopener vertelt de browser om naar het doel te navigeren zonder toegang te verlenen aan de ouder die het heeft geopend. Tab Doel Venster.opener zullen nul.

nocheferrer voorkomt dat de browser, wanneer deze naar het doel navigeert, het adres of een andere waarde als referrer naar de ouder stuurt via de verwijzer HTTP-header. Merk op dat de naam van deze HTTP-header met opzet verkeerd gespeld is als "referrer".

2. JavaScript links

Voor de JavaScript Venster.open functie kun je de waarden noopener en nocheferrer in de windowFeatures parameter van de Venster.open functie, maar verschillende browsers kunnen verschillend reageren, dus het is aan te raden om Venster.opener als nul na gebruik van Venster.open() functie.

Meer lezen:

Rails API & CORS. Een vleugje bewustzijn

Strategieën voor het ophalen van gegevens in NextJS

7 redenen waarom uw webwinkel Magento nodig heeft

Als je dit artikel interessant vindt, volg Lukasz dan op Github: https://github.com/twistezo