Säkerhet i webbapplikationer. Sårbarhet med mål="_blank"
Lukasz Kolko
Att använda webbapplikationer har blivit en självklarhet i alla samhällen. Vi hanterar dem varje dag. Man kan säga att de omger oss. Vi använder dem i arbetet, för underhållning och som verktyg för att kommunicera med andra. Ofta inser vi som användare och utvecklare inte hur många säkerhetsproblem som upptäcks varje dag i sådana applikationer.
Den sårbarhet som diskuteras i detta dokument har funnits länge och på grund av sin enkelhet underskattas den ofta eller är till och med okänd av vissa utvecklare av webbapplikationer.
Nästan alla webbapplikationer innehåller länkar som, när man klickar på dem, öppnas i en ny flik för att inte stänga fliken med den ursprungliga sidan. Detta är ett önskat beteende eftersom skaparna vill att användaren ska tillbringa så mycket tid som möjligt i applikationen.
En attack som utnyttjar denna sårbarhet är så kallad "reverse tabnabbing". Det är en attack där en sida som är länkad från målsidan kan ersätta den sidan med till exempel en phishing-sida.
Scenario för attack
Anta att offret använder Facebook, som är känt för att öppna länkar via target="_blank",
Skapa en falsk viral sida,
Skapa en nätfiskewebbplats som ser ut som en inloggningssida på Facebook,
Sätt in nedanstående kod på virussidan, t.ex. via en funnen XSS-sårbarhet window.opener.location = "https://phishing-website/facebook.com";
Offret klickar på länken på Facebook till den virala sidan,
Den virala sidan omdirigerar Facebook-fliken till phishing-webbplatsen och ber användaren att logga in igen.
Så vi kan ändra den överordnade fliken från den infekterade målsidan med hjälp av ett fönsterobjekt från Web API. Vanligtvis innebär en attack att man använder flera upptäckta sårbarheter och phishing-bedrägerier parallellt.
Problemet
När vi öppnar en ny flik i webbläsaren med hjälp av en länk med mål="_blank" attribut har vi tillgång till vår "referrer" från den nya fliken. Mer specifikt, till öppnare egenskapen hos Fönster objekt, som returnerar en referens till fönstret som öppnade det, vår överordnade sida.
Detta beror på beteendet hos Fönster.öppna() funktion. Med tillgång till detta attribut kan vi enkelt ersätta vår föräldrasida. Observera att vissa moderna webbläsare kan göra fönster.öppnare funktion i målfliken som noll för att förhindra detta beteende.
Exempel på kod
<code> <a href="https://github.com" target="_blank">Gå till GitHub - infekterad länk</a>konst
if (länk)
link[0].onclick = () => {
if (window) window.opener.location = 'https://stackoverflow.com'
}
Ovan kan du se den infekterade länken som ursprungligen öppnar en ny flik med en GitHub-sida men under tiden ändrar den vår "överordnade" sida till Stackoverflow-webbplatsen.
Live exempel
1. HTML-länkar
Lägg till rel="noopener noreferrer" till <a> tagg.
Den rel attributet definierar förhållandet mellan en länkad resurs och det aktuella dokumentet.
noopener säger till webbläsaren att navigera till målet utan att ge åtkomst till den förälder som öppnade det. Fliken Mål Fönsteröppnare kommer att vara noll.
noreferrer förhindrar att webbläsaren, när den navigerar till målet, skickar adressen eller något annat värde som referrer till föräldern via referent HTTP-rubrik. Observera att namnet på detta HTTP-huvud avsiktligt är felstavat som "referrer".
För JavaScript Fönster.öppna funktionen kan du lägga till värdena noopener och noreferrer i fönsterFunktioner parametern för Fönster.öppna funktion men olika webbläsare kan reagera olika så det rekommenderas att göra Fönsteröppnare som noll efter användning Fönster.öppna() funktion.