Afvikling af ondsindet kode (cross-site scripting)

Gæsteindlæg skrevet af Casper Schneidereit for 1 decade siden | Se alle indlæg



Dette indlæg handler om cross-site scripting. Er et website sårbart, kan angriberen indsætte sin egen kode, som efterfølgende kan vises til andre brugere. Det kan bruges (ondsindet) på mange forskellige måder. Til dette indlæg har jeg fundet et par eksempler:

En kilde til links
Først og fremmest kan det bruges i SEO øjesmed. Det er muligt at stjæle links fra et website. Lad os tage et eksempel. På elektronikcenteret.dk har de en formular hvor man kan indtaste henholdvis sagsnummer og kodeord, for at få vist satus på ens reparationssag. Ved at indtaste HTML koden for et link som reparationsnummer, og et vilkårligt tegn som kodeord, vil man skabe en URL, hvor ens ønskede link optræder:

Eksemplet ser måske lidt sjovt ud, men det er på grund af en række tegn er URL encoded. Eksempelvis bliver mellemrum til %20

Bliver den fremprovokerede URL indexeret af Google, vil det tælle med som et backlink. Dette kan også vendes om, så det sårbare website linker til skadelige sider. Formålet med dette er at få websitet kategoriset som bad neighborhood.

Code Injection, eksempel 1
Eksempel på et link.

Troværdige phising forsøg
Et mere alvorligt eksempel, er muligheden for at lave troværdige phising forsøg. På Guldborgsund Kommunes website er det også muligt at indsætte kode via URL'en. Ved at indtaste denne URL:

Bliver der indsat en boks der ser nogenlunde sådan her ud:

Code Injection, Guldborgsund Kommune
Boks indsat på Guldborsund Kommunes website.

Dette er et hurtigt eksempel jeg har lavet, men mulighederne er mere vidtrækkende. Det vil ikke være noget problem at lave et falsk nemID loginformular, der efterfølgende mailes ud. Dette er med henblik på at lave et "man in the middle" angreb, der gør det muligt at opnå adgang til offerets netbank.

Løsning (i PHP)
Overstående problemstilling kan løses, ved at fjerne HTML fra alle inputkilder. Hvis du arbejder med PHP kan du blandt andet bruge funktionen strip_tags(). Omkring strip_tags() skal du være opmærksom på faren ved at tillade bestemte tags. Jeg har opsat et lille eksempel herunder.

Desværre, dette eksempel virker ikke mere. Beklager.

Selvom man kun tillader et enkelt tag, er det altså stadigvæk muligt at indlejre javascript og CSS på det sårebare website.


Har du lyst til at hjælpe os?
Kunne du lide indlægget, så ville vi blive oprigtig glad, hvis du delte dette indlæg med dit netværk.



» Se andre indlæg her.

Kommentarer til indlæg

Morten   for 1 decade siden.

Fuck du er en nørd (ment på den gode måde ;D ), men du har bare de sjoveste emner af og til, som de færreste tænker over!
Men okay det der er faktisk en smule spooky! Lidt aller sygesikringskort billeder...


Mikael Rieck   for 1 decade siden.

Imponerende. Men hvordan sikrer man sig så bedst mod det?


Casper Schneidereit   for 1 decade siden.

I PHP kan du benytte funktionen strip_tags: http://dk2.php.net/strip_tags . Det er værd at bide mærke i, at selvom du tillader blot et enkelt tag, så vil du i princippet stadigvæk være sårbar, da der kan manipuleres med siden via style og event attributterne. Det vil eksempelvis være muligt, at afvikle javascript via onmouseover og onclick.


Lea Thomsen   for 1 decade siden.

Super spændende indlæg, men jeg savner godt nok svaret på, om mit site så ER sårbart. Sidder jo satme her og hyperventilerer ned i en brun pose nu! :D Hvordan finder man ud af det? Måske et indlæg mere værdigt?


Morten Vadskær   for 1 decade siden.

Ja, det vælter med den slags sites derude - og jeg selv har også gjort mig skyldig i at producere min andel. Jeg kan varmt anbefale bogen Essential PHP security. Den er lidt tør (heldigvis ikke stor), men den åbner virkelig ens øjne for sikkerhed med PHP.


Søren Sprogø   for 1 decade siden.

Endnu værre bliver det, når man kan injecte SQL istedet for HTML. NØJ, hvor har jeg "hacket" mig vej ind i mange bruger-"beskyttede" sites på den måde. Og det værste er jo, at jeg lige så godt kunne have SQL injected noget ala "DROP TABLE master"...

Hvis input felter eller URL parametre er åbne for den slags, så er det fordi sitet er lavet af en krejler af en programmør. Har man bare en SMULE uddannelse inden for feltet, så har man fra dag 1 fået hamret ind i hovedet at man skal validere sit input. Og som MINIMUM strippe eller encode alt hvad der ligner HTML eller SQL.

Du har ingen muligheder for at checke den her slags selv, hvis du bare er en normal hjemmeside-ejer. Det kræver forholdsvist nørdet viden at finde alle hullerne. Men HVIS du opdager den her slags, så sørg for at afstraffe den skod-programmør, du har haft til at lave din hjemmeside.

PS.: Dette skal ikke være en krig på programmeringssprog. Men til orientering, så checker .NET per default for, om input indeholder HTML eller SQL. Og hvis det gør, kommer siden ud med en advarsel. Dejligt, når det framework man arbejder med, automatisk lukker 80% af alle hullerne. Eller også er det en falsk sovepude.... Hmmm :-)


Martin Hjort   for 1 decade siden.

Hehe Søren, måske en sovepude mest ja :P

Strip_tags() er god, men endnu vigtigere er mysql_real_escape_string() måske, ihf. hvis ikke man bruger et framework eller lib af en art.

Muligvis det kedeligste som programmør, men også det vigtigste formentligt :)

@Morten
Den bog er rigtig god, om ikke andet så man kan bruge den som slagvåben overfor evt. alt for dovne programmører :)


Casper Schneidereit   for 1 decade siden.

Jeg har lidt opdateret den med et eksempel på strip_tags() funktionen.

Jeg er helt enig omkring SQL injection. ALLE inputkilder til mine SQL strenge bliver strippet, også selvom det er en konstant jeg selv har defineret. Så er jeg helt sikker på ikke at glemme nogen :-).


Teo   for 1 decade siden.

Hej Casper.

Hvor lovligt er dette? Jeg mener, det er jo frit tilgængeligt - og en "uskyldig" søgning.

Men kan man anklages/dømmes/sigtes for at afvikle "ondsindet" kode - her tænker jeg UDELUKKENDE på at skabe et link med disse metoder.

Eller hvordan forholder det sig?

mvh
Te0


Martin Hjort   for 1 decade siden.

@Casper
God ide, det er altid rarest at være på den sikre side :)

Fedt med eksemplerne i øvrigt :D


Michael Lindahl   for 1 decade siden.

Gode eksempler!

Lignende kan der også laves injections i kontakt formler hvor der er mulighed for at manipulere med e-mailens header og dermed bruge en fremmeds form til at spamme fra.

Det er meget godt beskrevet her:
http://www.dreamincode.net/forums/topic/228389-preventing-php-mail-header-injections/

Man skal også være opmærksom på at det er bedre at strippe output i stedet for input så man ikke får skrevet html kode ud hvis nogle skulle være i stand til at putte ting i din database uden om din html-stripper.


Hvad synes du?

Dit navn *
Din e-mail
Evt website
Hvad drikker møller?