Web8: XSS-udnyttelse - Del 2: Lagret XSS

I den forrige artikel lærte vi om XSS- fejl (Cross Site Scripting) og den faktiske udnyttelse af XSS Reflected. Der er en anden type XSS, der anses for at være mere farlig: Stored XSS.

I modsætning til Reflected, som direkte angriber nogle få ofre, der er målrettet af hackere, er Stored XSS rettet mod flere ofre. Denne fejl opstår, når webapplikationen ikke tjekker inputdataene grundigt, før de gemmer dem i databasen (her bruger jeg dette koncept til at henvise til databasen, filen eller andre områder, der gemmer applikationsdata. web).

Med Stored XSS-teknikken udnytter hackere det ikke direkte, men skal gøre det i mindst 2 trin.

For det første bruger hackere ufiltrerede inputpunkter (formular, input, tekstområde...) til at indsætte farlig kode i databasen.

Dernæst, når brugeren tilgår webapplikationen og udfører handlinger relateret til disse gemte data, vil hackerens kode blive eksekveret på brugerens browser.

På dette tidspunkt ser hackeren ud til at have nået sit mål. Af denne grund kaldes Stored XSS-teknikken også andenordens XSS.

Udnyttelsesscenariet er beskrevet som følger:

Reflekted XSS og Stored XSS har to store forskelle i angrebsprocessen.

• For det første, for at udnytte Reflected XSS, skal hackeren narre offeret til at få adgang til hans URL. Hvad angår Stored XSS, er det ikke nødvendigt at gøre dette. Efter at have indsat den farlige kode i applikationens database, skal hackeren bare vente på, at offeret automatisk får adgang til den. For ofre er dette helt normalt, fordi de ikke ved, at de data, de får adgang til, er blevet inficeret.
• For det andet vil hackerens mål være lettere at opnå, hvis offeret stadig er i webapplikationens session på angrebstidspunktet. Med Reflected XSS kan en hacker overbevise eller narre offeret til at logge ind og få adgang til den URL, han giver for at udføre ondsindet kode. Men Stored XSS er anderledes, fordi den ondsindede kode er blevet gemt i webdatabasen, så hver gang brugeren får adgang til relaterede funktioner, vil den ondsindede kode blive eksekveret, og højst sandsynligt kræver disse funktioner godkendelse. log ind først, så selvfølgelig i løbet af denne tid brugeren er stadig i sessionen.

Ud fra disse ting kan det ses, at Stored XSS er meget farligere end Reflected XSS, de berørte emner kan være alle brugere af den pågældende webapplikation. Og har offeret en administrativ rolle, er der også risiko for webkapring.