Cross -site scripting ( XSS ) er en cybersårbarhet som påvirker dynamiske nettsteder som bruker utilstrekkelig skjemainndatakontroll . En XSS lar en cracker sette inn eller utføre kode på klientsiden for å utføre et variert sett med angrep, som for eksempel innsamling, manipulering og omdirigering av konfidensiell informasjon, visning og modifikasjon av data på servere, endring av dynamisk oppførsel av nettsider osv.
I dagens forstand inkluderer teknikken bruk av et hvilket som helst skriptspråk på klientsiden, inkludert JavaScript , VBScript , Flash . Effekten deres kan variere fra en liten irritasjon til en betydelig sikkerhetsrisiko, avhengig av sensitiviteten til dataene som behandles på det sårbare nettstedet og arten av sikkerhetsstrategiene implementert av nettstedeierne.
I følge en Symantec- rapport fra 2007 skyldes 80 % av alle brudd XSS -angrep [1] .
Sikkerhet på nettet avhenger av en rekke mekanismer, inkludert tillitsbegrepet kjent som samme opprinnelsespolicy . Dette sier i hovedsak at hvis det første nettstedets innhold får tillatelse til å få tilgang til ressursene til ett system, vil alt innhold fra det nettstedet dele disse tillatelsene, mens innholdet fra et annet nettsted må ha separate tillatelser.
Skriptangrep på tvers av nettsteder bruker kjente sårbarheter i nettapplikasjoner, deres servere eller pluginene de er avhengige av. Ved å utnytte en av disse sårbarhetene, injiserer angripere ondsinnet innhold i meldingen fra det kompromitterte nettstedet, slik at når det kommer inn i nettleseren på klientsiden, sendes det fra den pålitelige kilden, for å operere i henhold til tillatelsene gitt til det. system. Ved å injisere ondsinnede skript kan angriperen få tilgangsrettigheter til sensitivt sideinnhold, øktinformasjonskapsler og en rekke annen informasjon som administreres av nettleseren på vegne av brukeren.
Microsofts sikkerhetsingeniører introduserte begrepet cross-site scripting i januar 2000.
Uttrykket cross-site scripting refererte opprinnelig utelukkende til angrep basert på bruk av JavaScript -kodefragmenter satt inn i forespørselskall til dynamiske nettsider plassert på en web-server (teknikk som er en del av kodeinjeksjonsmetodene ) slik at den eksterne serveren utførte andre operasjoner enn de som opprinnelig var forutsatt av nettapplikasjonen. Denne definisjonen har gradvis utvidet seg til å inkludere andre "kodeinjeksjons"-moduser basert ikke bare på JavaScript , men også på ActiveX , VBScript , Flash eller til og med ren HTML . Dette har skapt en viss forvirring i terminologien knyttet til IT-sikkerhet ; begrepet omfatter i dag et helt sett med angrepsteknikker og ikke utelukkende det som er basert på manipulering av JavaScript-kode. [2]
XSS-sårbarheter har blitt rapportert og utnyttet siden 1990. Kjente nettsteder har blitt kompromittert tidligere, inkludert sosiale nettverkssider som Twitter [3] , Facebook [4] , MySpace , YouTube og Orkut [5] . I de påfølgende årene overgikk skriptproblemer på tvers av nettsteder problemene med bufferoverløp og ble det mest rapporterte sikkerhetssårbarheten [6] , så mye at noen forskere i 2007 antok at 68 % av nettstedene sannsynligvis ville bli utsatt for angrep. XSS [7 ] .
De fleste eksperter skiller minst to hovedtyper XSS-sårbarheter: ikke-vedvarende og vedvarende. Noen kilder deler videre disse to gruppene inn i tradisjonell (forårsaket av problemer i serversidekode) og DOM - basert (i klientsidekode).
Reflekterte skriptsårbarheter på tvers av nettsteder er absolutt de vanligste. De kan utnyttes når dataene fra brukeren (vanligvis via HTML-skjemaer) brukes umiddelbart av skriptet på serversiden for å bygge de resulterende sidene uten å kontrollere riktigheten av forespørselen.
Siden HTML-dokumenter har en flat struktur der kontroll-, formaterings- og faktiske innholdsuttalelser blandes, kan dette føre til injeksjon av markup-kode [8] hvis noen ugyldige brukerlevert data er inkludert på den resulterende siden uten riktig HTML-koding . Et klassisk eksempel på en potensiell vektor er nettstedets søkemotor – hvis du søker etter en streng, vil den typisk dukke opp igjen på resultatsiden for å indikere hva du søkte etter. Hvis dette svaret ikke unngår eller avviser HTML-kontrolltegn, følger det at det er sårbart for skriptangrep på tvers av nettsteder. [9]
Et ikke-vedvarende angrep sendes vanligvis via e-post eller fra et nøytralt nettsted. Lokkemidlet er en uskyldig utseende URL, som peker til et pålitelig nettsted, men som inneholder en XSS-vektor. Hvis det pålitelige nettstedet er sårbart for den vektoren, kan klikk på lenken føre til at injiserte skript kjøres i offerets nettleser.
En vedvarende (eller lagret) XSS-sårbarhet er en mer ødeleggende variant av skripting på tvers av nettsteder: den oppstår når dataene fra angriperen lagres på serveren, og deretter permanent vises på sidene som vanligvis gis til brukere under normal surfing. fjerning av HTML-formatering fra meldinger som er sett av andre brukere.
Anta for eksempel at det er en datingside der medlemmer ser på profiler til andre medlemmer for å søke etter felles interesser. Av personvernhensyn skjuler denne siden brukernes virkelige navn og e-post for alle. Denne informasjonen holdes hemmelig av serveren. Den eneste gangen det virkelige navnet og e-posten vises er når medlemmet autentiserer, men kan ikke se noen andres data uansett.
Anta at en angriper logger inn på nettstedet og ønsker å finne ut de virkelige navnene på personene han ser på nettstedet. For å gjøre dette skriver han et skript designet for å kjøres av andres nettlesere når de besøker profilen hans. Skriptet sender en kort melding til serveren som samler inn denne informasjonen.
For å gjøre dette, for spørsmålet "Beskriv din ideelle første date", gir angriperen et kort (vanlig utseende) svar, men teksten på slutten av svaret er skriptet for å stjele navn og e-post. Hvis skriptet er omsluttet av et <script>-element, vil det ikke vises på skjermen. Så la oss anta at Bob, et medlem av datingsiden, når angriperens profil, der svaret på spørsmålet om den ideelle første daten vises. Skriptet kjøres automatisk av nettleseren og stjeler Bobs virkelige navn og e-post direkte fra maskinen hans.
Vedvarende XSS-sårbarheter kan være mye mer betydelige enn de andre fordi angriperens ondsinnede skript leveres automatisk uten behov for å målrette offeret eller lokke dem inn på tredjepartssiden. Spesielt når det gjelder nettsteder for sosiale nettverk, kan koden utformes for å spre seg autonomt mellom kontoer, og skape en type orm på klientsiden .
Injeksjonsmetodene kan variere mye, i noen tilfeller trenger angriperen ikke engang å samhandle med nettfunksjonene for å utnytte en feil. Alle data som mottas av en nettapplikasjon (via e-post, systemlogg, direktemeldinger osv.) som kan kontrolleres av en angriper, kan bli en injeksjonsvektor.
Historisk sett har XSS-sårbarheter blitt funnet i applikasjoner som utførte all databehandling på serversiden. Brukerinndata (inkludert en XSS-vektor) vil bli sendt til serveren og deretter sendt tilbake som en nettside. Behovet for å forbedre brukeropplevelsen ga popularitet til applikasjoner som hadde presentasjonslogikk (skrevet i JavaScript ) som sendte data, på forespørsel, til serveren ved hjelp av AJAX .
Mens JavaScript-koden også behandler brukerinndata og viser dem på nettsiden, har den nye underklassen av reflekterte XSS-angrep begynt å dukke opp og har blitt kalt DOM -basert cross-site scripting. I DOM-baserte XSS-angrep berøres ikke ondsinnede data av webserveren, men reflekteres av JavaScript-koden utelukkende på klientsiden. [10]
Et eksempel på en DOM-basert XSS-sårbarhet er en feil funnet i 2011 i en serie med JQuery -plugins [11] . Forebyggingsstrategier for DOM-baserte XSS-angrep inkluderer tiltak som ligner veldig på tradisjonelle XSS-forebyggingsstrategier, men implementert i JavaScript -kode og inkludert på sider [12] . Noen JavaScript-rammeverk har laget mottiltak mot disse og andre typer angrep - for eksempel Angular.js [13] .
Angripere som forsøker å utnytte skriptsårbarheter på tvers av nettsteder, møter hver sårbarhetsklasse annerledes. For hver klasse beskrives en spesifikk angrepsvektor. Navnene som brukes nedenfor er tekniske navn som vanligvis brukes i datasikkerhet.
For at dette angrepet ikke skal skje eller for å redusere effektene i tilfelle det skjer, kan forskjellige strategier tas i bruk:
Bobs nettstedsprogramvare kunne ha analysert kommentarene i nyhetsseksjonen og fjernet eller fikset eventuelle skript, men det gjorde den ikke, det er der sikkerhetsfeilen ligger.
Dette tiltaket bør brukes som en primær forsvarsmekanisme for å stoppe XSS-angrep. Det er flere escape-skjemaer som kan brukes, inkludert HTML-enhetskoding, JavaScript-escape, CSS-escape og URL-koding [16] . Mange nettapplikasjoner som ikke aksepterer rike data kan bruke escape for å eliminere de fleste risikoene for XSS-angrep ganske enkelt.
Mange operasjoner av bestemte nettapplikasjoner (fora, webmail, etc.) lar brukere bruke et begrenset delsett av HTML-oppmerking. Når du aksepterer HTML-inndata fra brukere, for eksempel "<b> veldig <b /> bred", vil den utgående kodingen, for eksempel "svært </b> bred", ikke være tilstrekkelig siden den må gjengis som HTML av nettleseren. Å stoppe et XSS-angrep når du aksepterer HTML-inndata fra brukeren er svært komplisert i denne omstendigheten. Uklarert HTML-inndata må gjøres gjennom en HTML-saneringsmotor for å sikre at den ikke inneholder XSS-kode.
I tillegg til innholdsfiltrering, brukes ofte andre metoder for å redusere skripting på tvers av nettsteder.
Et eksempel er bruken av ekstra sikkerhetskontroller under informasjonskapselbasert øktmanipulasjon. Mange nettapplikasjoner er avhengige av øktinformasjonskapsler for å håndtere autentisering mellom forskjellige HTTP-forespørsler, og siden skript på klientsiden generelt har tilgang til denne informasjonskapselen, kan enkel XSS stjele dem [17] . For å redusere denne spesielle trusselen, binder mange nettapplikasjoner sesjonsinformasjonskapselen til IP-adressen til brukeren som opprinnelig fikk tilgang, og tillater deretter bare denne IP-en å bruke informasjonskapselen [18] . Dette er effektivt i de fleste tilfeller, men fungerer åpenbart ikke i situasjoner der en angriper står bak den samme NAT - adressen eller nettproxyen som offeret, eller offeret endrer sin mobile IP [18] .
En annen løsning finnes i Internet Explorer (fra versjon 6), Firefox (fra versjon 2.0.0.5), Safari (fra versjon 4), Opera (fra versjon 9.5) og Google Chrome ; er HttpOnly- flagget som lar en webserver sette en informasjonskapsel som ikke er tilgjengelig fra skriptet på klientsiden. Hvis den brukes, kan funksjonen fullstendig forhindre tyveri av informasjonskapsler, men ikke angrep i nettleseren [19] .
Mens web 2.0- og Ajax -applikasjoner favoriserer bruken av JavaScript [20] , er noen webapplikasjoner skrevet for å tillate drift uten behov for skripting på klientsiden [21] . Dette lar brukere, hvis de ønsker det, deaktivere eventuelle skript i nettleserne før de bruker applikasjonen. På denne måten kan skript på klientsiden, til og med potensielt skadelige, plasseres uten escape på en side, og brukere vil ikke være utsatt for XSS-angrep.
Noen nettlesere eller nettleserplugins kan konfigureres til å deaktivere skript på klientsiden per domene. Denne tilnærmingen er av begrenset verdi hvis skript er aktivert som standard, da de vil bli blokkert når brukeren har gjenkjent dem som farlige, men det vil være for sent nå. En funksjon som blokkerer alle skript og eksterne inkluderinger som standard, og derfor lar brukere aktivere på en per domene basis, er mer effektiv. Dette var lenge mulig på Internet Explorer (fra versjon 4) ved å sette de såkalte «sikkerhetssonene» [22] og i Opera (fra versjon 9) ved å bruke «sidespesifikke preferanser». Løsningen for Firefox og andre Gecko - baserte nettlesere er åpen kildekode NoScript -tillegget som i tillegg til å aktivere skript per domene, gir noe XSS-beskyttelse selv når skript er aktivert [23] .
Det mest relevante problemet gitt av blokkering av alle skript på alle nettsteder som standard er den betydelige reduksjonen i funksjonalitet og respons (skripting på klientsiden kan være mye raskere enn skripting på serversiden fordi det ikke trenger å koble til en ekstern server og siden, eller rammen, trenger ikke å lastes inn på nytt) Et annet problem med skriptblokkering er at mange brukere ikke forstår det og ikke vet hvordan de skal sikre nettleseren på riktig måte. En annen ulempe er at mange nettsteder ikke fungerer uten skripting på klientsiden, noe som tvinger brukere til å deaktivere sikkerheten for nettstedet [24] . NoScript Firefox-utvidelsen lar brukere aktivere skript fra en bestemt side, men lar ikke andre kjøre den samme siden. For eksempel kan skript fra example.com kjøre, skript fra advertisingagency.com som prøver å kjøre på samme side kan deaktiveres [25] .
Det er tre klasser av XSS-forsvar som dukker opp. Disse inkluderer Content Security Policy [26] , JavaScript-sandbox-verktøy og auto-escape-maler. Disse mekanismene er fortsatt under utvikling, men de lover en fremtid der XSS-angrep vil bli kraftig begrenset.
Noen selskaper tilbyr en periodisk skannetjeneste, som i hovedsak simulerer et angrep fra deres server til kundens server for å se om angrepet er vellykket. Hvis dette skjer, mottar kunden detaljert informasjon om hvordan angrepet ble utført og har deretter en sjanse til å fikse problemet før noen andre gjør det samme angrepet. Skanneren kan ikke finne alle mulige sårbarheter, [27] derfor kan de skannede sidene fortsatt være sårbare for nye typer angrep, men skanningene kan oppdage noen kjente problemer. Etter at kunden har fikset sikkerhetsfeilene, vil siden garantert være sikrere enn før. For nettsteder som krever en komplett løsning av XSS-sårbarheter, kreves vurderingsteknikker som manuell kodegjennomgang.
I et Universal Cross-Site Scripting- angrep ( UXSS eller Universal XSS ) blir sårbarheter i selve nettleseren utnyttet, i stedet for sårbarheter på nettsteder, som med XSS-angrep.
Flere klasser av sårbarheter eller angrepsteknikker er relatert til XSS: skripting på tvers av soner tillater kjøring av kode med større privilegier i enkelte nettlesere [28] . HTTP-header-injeksjon kan brukes til å skape de nødvendige betingelsene for skripting på tvers av nettsteder ved å unngå problemer med HTTP-protokollnivå (i tillegg til å tillate angrep som HTTP-responsdeling) [29] .
Cross-site request forgery (CSRF / XSRF) er nesten det motsatte av XSS, i den forstand at i stedet for å utnytte brukernes tillit til et nettsted, utnytter angriperen og hans ondsinnede side nettstedets tillit til klientens programvare. nettstedet vurderer bevisste og tilsiktede handlinger fra en autentisert bruker [30] . XSS-sårbarheter (selv i andre applikasjoner som kjører i samme domene) lar angripere omgå CSRF-forebyggingstiltak [31] .
Covert Redirect utnytter tredjepartsklienter som er mottakelige for XSS- eller Open Redirect-angrep. Covert Redirect ble oppdaget av PhD-student Wang Jing ved Nanyang Technological University i Singapore. "Vanlige phishing-forsøk kan lett oppdages, fordi nettadressen til den skadelige siden vanligvis er et par bokstaver forskjellig fra den faktiske siden. Forskjellen med Covert Redirect er at en angriper kan bruke det faktiske nettstedet i stedet for å hacke nettstedet med en ondsinnet påloggingsvindu." [32]
Til slutt utnytter SQL-injeksjon en sårbarhet i applikasjonsdatabaselaget. Når brukerinndata ikke er riktig filtrert, kan alle SQL-setninger kjøres av applikasjonen. [33]