Web8: XSS-exploits - Deel 2: Opgeslagen XSS

In het vorige artikel leerden we over XSS- fouten (Cross Site Scripting) en de daadwerkelijke exploitatie van XSS Reflected. Er is een ander type XSS dat als gevaarlijker wordt beschouwd: Stored XSS.

In tegenstelling tot Reflected, dat rechtstreeks enkele slachtoffers aanvalt die het doelwit zijn van hackers, richt Stored XSS zich op meer slachtoffers. Deze fout treedt op wanneer de webapplicatie de invoergegevens niet grondig controleert voordat deze in de database wordt opgeslagen (hier gebruik ik dit concept om te verwijzen naar de database, het bestand of andere gebieden waarin applicatiegegevens worden opgeslagen. web).

Met de Stored XSS-techniek maken hackers er niet direct misbruik van, maar moeten ze dit in minimaal 2 stappen doen.

Ten eerste gebruiken hackers ongefilterde invoerpunten (formulier, invoer, tekstgebied...) om gevaarlijke code in de database in te voegen.

Wanneer de gebruiker vervolgens toegang krijgt tot de webapplicatie en bewerkingen uitvoert die verband houden met deze opgeslagen gegevens, wordt de code van de hacker uitgevoerd in de browser van de gebruiker.

Op dit punt lijkt de hacker zijn doel te hebben bereikt. Om deze reden wordt de Stored XSS-techniek ook wel tweede-orde XSS genoemd.

Het exploitatiescenario wordt als volgt beschreven:

Reflected XSS en Stored XSS hebben twee grote verschillen in het aanvalsproces.

• Om Reflected XSS te kunnen misbruiken, moet de hacker eerst het slachtoffer ertoe verleiden toegang te krijgen tot zijn URL. Wat Stored XSS betreft, hoeft u dit niet te doen: nadat de gevaarlijke code in de database van de applicatie is geplaatst, hoeft de hacker alleen maar te wachten tot het slachtoffer er automatisch toegang toe krijgt. Voor slachtoffers is dit volkomen normaal omdat ze niet weten dat de gegevens waartoe ze toegang hebben, zijn geïnfecteerd.
• Ten tweede zal het doel van de hacker gemakkelijker te bereiken zijn als het slachtoffer zich op het moment van de aanval nog in de sessie van de webapplicatie bevindt. Met Reflected XSS kan een hacker het slachtoffer overtuigen of misleiden om in te loggen en toegang te krijgen tot de door hem opgegeven URL om kwaadaardige code uit te voeren. Maar Stored XSS is anders, omdat de kwaadaardige code is opgeslagen in de webdatabase, dus telkens wanneer de gebruiker toegang krijgt tot gerelateerde functies, zal de kwaadaardige code worden uitgevoerd, en hoogstwaarschijnlijk vereisen deze functies authenticatie. Log eerst in, dus uiteraard gedurende deze tijd de gebruiker bevindt zich nog in de sessie.

Uit deze zaken blijkt dat Stored XSS veel gevaarlijker is dan Reflected XSS; de getroffen personen kunnen allemaal gebruikers van die webapplicatie zijn. En als het slachtoffer een administratieve rol heeft, bestaat er ook een risico op webkaping.