Web9: Typer av XSS-exploatering - Del 3: Dom-baserad XSS

Vi har redan nämnt två typer av XSS- exploateringar : reflekterad och lagrad. De har alla den gemensamma egenskapen att farlig kod, efter att den har infogats, kommer att exekveras efter serverns svar, vilket innebär att felet ligger på serverns sida.server.server. Det finns en annan typ av XSS-exploatering som går emot denna funktion, skadlig kod exekveras omedelbart på klientsidan utan att gå via servern, känd som DOM-baserad XSS eller även känd som typ 0 XSS.

Först och främst behöver vi veta vad DOM är?

DOM, förkortning för Document Object Model, är en standardform av W3C (http://www.w3.org/DOM/) som föreslås för att hämta och manipulera data från strukturerade dokument som HTML och XML. Denna modell representerar dokument som en hierarkisk trädstruktur. Alla element i HTML och XML betraktas som en nod.

DOM-baserad XSS är en XSS-exploateringsteknik baserad på att ändra dokumentets DOM-struktur, särskilt HTML.

Låt oss titta på ett specifikt exempel nedan:

En webbplats har följande URL till registreringssidan:

example.com/register.php?message=Please fill in the form

När vi kommer åt det ser vi en mycket normal form:

Du kan enkelt härleda meddelandeparametern som skickas in i meddelandeinnehållet på formuläret, titta noga på källkoden för detta meddelande:

JavaScript-segmentet ansvarar för att hämta värdet från meddelandeparametern och skriva ut det. Från denna slappa indatakontroll är det fullt möjligt att lura användare att komma åt farliga webbadresser.

Istället för att gjuta:

message=Please fill in the form

sänd sedan:

message=GenderMaleFemale

function show(){alert();}

Då kommer registreringsformuläret att se ut så här:

Användare kommer inte att vara misstänksamma mot en "normal" form som denna, och när man väljer kön kommer skriptet att köras:

Jag ska förklara lite mer om värdet som skickas i meddelandeparametern:

GenderMaleFemale

function show(){alert();}

Dess huvudsakliga syfte är att köra show()-funktionen varje gång det finns en onchage-händelse på select-taggen. Show()-funktionen här dyker helt enkelt upp för att visa att skriptet har körts. Men i verkligheten använder hackare ofta den här show()-funktionen för att köra ett skript som överför användarens cookie-värde till en förutbestämd server Läsare kan läsa artikeln Reflected XSS som nämner hur hackare skapar Hur ser denna begäran ut?

Detta exempel ger oss två viktiga slutsatser. Först exekverades den skadliga koden omedelbart efter att man klickade på värdet i select-taggen, vilket betyder att den kördes direkt på klientsidan utan att gå igenom serverns svar. För det andra har HTML-strukturen ändrats med det godkända skriptet. Och vi kan också se det faktiska exploateringsscenariot, DOM Based är något mer lik Reflected än Stored XSS när det gäller att lura användare att komma åt en URL inbäddad med skadlig kod.

Följande figur beskriver varje steg i implementeringen av den DOM-baserade XSS-attacktekniken:

Nedan är en video av en medlem av WhiteHat.vn-forumet som utför ett utnyttjande genom DOM Based XSS:

Lycka till!