Er du sikret mod XSS – Cross Site Scripting?
Jeg har gennem det sidste års tid kigget lidt nærmere på [tag]Cross Site Scripting[/tag] – eller XSS, som det også kaldes. Det der har chokeret mig mest, er hvor mange websites der øjensynligt ikke er beskyttet ordentligt mod denne “hacker-teknik”. For at sige det lige ud står rigtig mange websites pivåbne for alle og enhver der ved lidt om XSS. Heldigvis er der ikke så mange der ved alverden om XSS, men alligevel – ville du lade døren til pengeskabet, eller varelagret stå ulåst hen og uden alarm? Har du sikret dine webapplikationer ordentligt mod XSS?
Cross Site Scripting har været kendt i mange år. Grundlæggende set handler [tag]XSS[/tag] blot om at afvikle fremmed kode på systemer, hvor denne kode ikke hører til. Det er således ikke en særlig Internet-teknik, men en mere generel måde at “angribe” et hvilket som helst elektronisk system på. Med Internet er det blot blevet endnu mere udbredt og langt lettere at gå til – og dermed endnu vigtigere at beskytte sig imod.
Sidste år kom der en sag frem, som viser hvor alvorligt et XSS hack kan gå ud over et website, da MySpace blev lagt ned med nogle få liniers kode. Sagen er et meget godt studie i, hvad der kan ske hvis man ikke beskytter sig ordenligt.
My Space XSS Hack
Du kan finde en nærmere gennemgang af den konkrete sag her – på hackerens eget website. Det er lidt nørded læsning, men kort fortalt går det ud på, at man på MySpace kan uploade forskelige ting til sin profil – herunder billeder og forskellig kode. Der er dog visse begrænsninger i hvilken kode man kan uploade. F.eks. sletter systemet automatisk alle forekomster af ordet “javascript” – dette omgås dog meget let – både her i denne case og på mange andre websites. I den konkrete sag blev det løs ved at skrive “java\nscript” der betyder “javascript” og tolkes som et almindeligt JavaScript i de fleste browsere. De andre forhindringer og hvordan de blev overkommet kan du læse mere om i den detaljerede gennemgang af koden her.
På MySpace kan man tilføje “venner” til sin profil. Hackeren ville i dette eksempel finde en måde automatisk at få en masse venner på. Han indsmuglede så denne kode, som du kan læse mere om i detaljer på hans site, som havde følgende effekt: Når en bruger så hans profil blen han (hackeren) automatisk tilføjet som “ven” til den der så profilen. Ydermere blev hans “virus” overført til den besøgendes profil, så når folk kom på besøg der, blev de også tilføjet. Et rent pyramide-setup!
Efter en time havde han 74 venner
Efter 7 timer næsten 300 – og nu gik det stærkt
3 timer senere nærmede det sig 10.000 venner
5 timer senere var det tæt på en million!
– og som hackeren skriver: “It’s official. I’m popular.” 🙂
En time efter lukker alle profiler og debatter ned på MySpace!
Hackeren var i dette tilfælde en “flink mand”. Han kunne have lavet meget mere ravage og skabt endnu mere kaos hvis han ville. Han kune have ødelagt meget mere end han gjorde og han kunne have gjort det uden at ret mange, om overhovedet nogen, havde lagt mærke til det.
I dette tilfælde var der tale om det man også kalder “JavaScript injection” – atså hvor man “snyder” JavaScript kode ind og eksekverer det. Men man kan også lave det der kaldes “SQL injections” hvor det er [tag]SQL[/tag] kode der sniges ind. Lykkedes det, og det kan man faktisk på mange websites(!), så kan alt lade sig gøre – fra at tømme hele databasen, snuppe all passwords, credit card informationer eller hvad man nu ellers har lyst til.
Hvor godt er Danske websites beskyttet mod XSS?
Jeg har kigget på en række Danske websites – både offentlige og private, og lad mig sige med det samme: Det er ser ikke godt ud! Jeg er på ingen måde en super XSS nørd, og jeg kan f.eks. slet ikke finde ud af SQL injections, men det er der andre som kan. Jeg kan blot konstatere, ved en række simple tests, at JavaScript injection i hvert fald er fuldt ud muligt på mange sites, hvor det ikke burde kunne lade sig gøre – store virksomheder og statslige eller kommunale websites. Ja, jeg kunne stort set vade lige ind de fleste steder!
Jeg vil ikke her give adresser eller eksepmpler på de sites jeg kunne komme ind på, da jeg ikke har advaret dem om problemerne. Der var simpelt hen så mange sites uden ordentlig beskyttelse, at jeg har opgivet at skrive rundt til dem alle.
Jeg vil dog ALVORLIGT opfordre dig til at kontakte din IT-afdeling eller webburau med det samme og bede dem om at forklare hvad de har gjort for at sikre jeres webapplikationer mod XSS – Cross Site Scripting. Flere og flere bliver, som jeg, opmærksom på de “kreative” muligheder XSS giver og det er for åndssvagt ikke at gøre noget ved det!
Til de danske webburauer kan jeg blot gentage det jeg har sagt flere gange: Tag jer sammen for helvede! Det kan sgu da ikke være rigtigt at i sælger løsninger til kunderne som man kan vade lige ind i, manipulere med, ødelægge eller lægge ned. Det må I sgu gøre bedre!
Udover ovenstående artikel om MySpace-sagen, kan jeg anbefale at læse denne artikel, der fortæller lidt mere om hvordan det hele virker og hvordan du kan beskytte dig imod det. Der findes også flere bøger om emnet, ligesom at flere af de store softwarehuse tilbyder integrerede løsninger til bl.a. .NET. Så der er ingen som helst undskylding for ikke at beskytte sig ordentligt – den nædvendige viden ER tilgængelig, for både dig, hackerne og os andre …
Mathias skriver
JA. det med injecton skal tages meget seriøst og indtænkes i hver enkelt linje kode. hvis man vil se lidt gyyys kan man hoppe forbi
http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf
Rune Jensen skriver
Mere aktuelt end nogesinde lige nu, og det er 2 år siden, det blev skrevet?
Jeg har haft injectionforsøg og sårbarhedsscannings-forsøg fra både botter, og – er jeg ret sikker på udfra behaviour – en enkelt human hacker.
Med SQL skal man så vidt jeg ved tage nogle enkle forholdsregler, og så er man sikker for SQL-injections, men da initiate forsøg som regel starter i querystring, og da der også kan (som du skriver) foretages andre injection/scanning end via SQL, så har jeg lavet en whitelist-pattern på hele QS, som skal opfyldes – ellers blockes brugeren. Virker ganske effektivt.
jesper skriver
Prøv kig på http://jesperkampmann.com/2008/10/23/blind-php-sql-injection.html