Web9: Typer af XSS-udnyttelse - Del 3: Dom-baseret XSS

Vi har allerede nævnt to typer XSS- udnyttelser : reflekteret og lagret.De har alle det fælles træk, at farlig kode, efter at være blevet indsat, vil blive eksekveret efter serverens svar, hvilket betyder, at fejlen ligger på serverens side.server.server. Der er en anden type XSS-udnyttelse, der går imod denne funktion, ondsindet kode udføres straks på klientsiden uden at gå gennem serveren, kendt som DOM Based XSS eller også kendt som type 0 XSS.

Først og fremmest skal vi vide, hvad DOM er?

DOM, forkortelse for Document Object Model, er en standardform for W3C (http://www.w3.org/DOM/), der foreslås til at hente og manipulere data fra strukturerede dokumenter som HTML og XML. Denne model repræsenterer dokumenter som en hierarkisk træstruktur. Alle elementer i HTML og XML betragtes som en node.

DOM-baseret XSS er en XSS-udnyttelsesteknik baseret på ændring af dokumentets DOM-struktur, specifikt HTML.

Lad os se på et specifikt eksempel nedenfor:

Et websted har følgende URL til registreringssiden:

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

Når vi får adgang til det, ser vi en meget normal formular:

Du kan nemt udlede meddelelsesparameteren, der er overført til meddelelsesindholdet på formularen, se nøje på kildekoden til denne meddelelse:

JavaScript-segmentet er ansvarligt for at hente værdien fra meddelelsesparameteren og udskrive den. Ud fra denne slappe inputkontrol er det fuldt ud muligt at narre brugere til at få adgang til farlige URL'er.

I stedet for at caste:

message=Please fill in the form

send derefter:

message=GenderMaleFemale

function show(){alert();}

Så ser tilmeldingsformularen således ud:

Brugere vil ikke være mistænksomme over for en "normal" form som denne, og når de vælger køn, vil scriptet blive udført:

Jeg vil forklare lidt mere om den værdi, der sendes i meddelelsesparameteren:

GenderMaleFemale

function show(){alert();}

Dens hovedformål er at udføre show()-funktionen hver gang der er en onchage-begivenhed på select-tagget. Show()-funktionen her dukker simpelthen op for at vise, at scriptet er blevet udført. Men i virkeligheden vil hackere ofte bruge denne show() funktion til at udføre et script, der overfører brugerens cookieværdi til en forudbestemt server Læsere kan gennemgå artiklen Reflected XSS , som nævner, hvordan hackere opretter Hvordan ser denne anmodning ud?

Dette eksempel giver os to vigtige konklusioner. For det første blev den ondsindede kode eksekveret umiddelbart efter at have klikket på værdien i select-tagget, hvilket betyder, at den blev eksekveret direkte på klientsiden uden at gå igennem serverens svar. For det andet er HTML-strukturen blevet ændret med det beståede script. Og vi kan også se det faktiske udnyttelsesscenarie, DOM Based ligner noget mere Reflected end Stored XSS, når det kommer til at narre brugere til at få adgang til en URL, der er indlejret med ondsindet kode.

Følgende figur beskriver hvert trin i implementeringen af ​​den DOM-baserede XSS-angrebsteknik:

Nedenfor er en video af et medlem af WhiteHat.vn-forummet, der udfører en udnyttelse gennem DOM Based XSS:

Held og lykke!