Cross Site Scripting bug i PHP!
Så er der endnu et Cross Site Scripting hul på banen – denne gang et der rammer de fleste PHP-sites!
Fejlen opstår via funktionen phpinfo() der viser en masse info om din PHP-installation. Problemet er, at der øjensynligt kan injectes kode til denne function som ikke “escapes” når den udskrives. Resultatet er, at du kan indsætte et link til dit website på et hvilket som helst website der benytter PHP (i den rigtige version – 4.4.3 – 4.4.6) og denne funktion.
Se f.eks. dette link – scroll ned til “PHP Variables”.
Og der er øjensyligt masser af sites at tage af. Her er en søgning der viser næsten 70.000 af denne type sites. Og her er en anden søgning, der viser en pæn portion .edu sites (som vi alle ved er ekstra værdifulde). Og her finder du en del af de danske.
Når du har fundet det site du gerne vil have et link fra skal du blot indsætte denne streng, så dukker det op 🙂 – Så mangler du “bare” at få det indekseret …
?f[]=%3Ca%20href%3Dhttp%3A//www.demib.dk/%3EdeMib+SEO%3C/a%3E
Og det er øjensynligt ikke kun HTML og links der kan injectes på denne måde. Også JavaScript går lige igennem, her. Så drenge, hjem og fiks jeres PHP installation … 🙂
Tak til David Naylor, og hans programmør Rob, for dette “tip”.
Morten skriver
Måske er det mig, men umiddelbart er det jo ikke en decideret sikkerhedsrisiko (når man ser bort fra, at det kan æde al ens trafik). Derudover synes jeg, det er lidt af en overdrivelse at skrive, at den “rammer de fleste PHP-sites”. I den google-søgning af danske sider, du henviser til, er der knap 4 sider. Det kan vist ikke betegnes som de fleste PHP-sites. Der er unægteligt flere derude.
Og for at det virker, kræver det jo også, at man linker til dem, for at kunne få et backlink. Så de får jo sådan set også nogle indgående links. Godtnok til deres phpinfo()-side, så det er nok ikke meget værd ;o)
Mht javascripten, så kan jeg ikke lige se det farlige i det. Kan du ikke uddybe det lidt?
Men derudover så må man ta’ hatten af for at de opdagede den lille “feature”.
Mikkel deMib Svendsen skriver
Du har ret i at det naturligvis kun er de PHP sites der har en PHP info side oppe – men det er også rigeligt.
For at få siderne med det injectede link indekseret kræver det rigtig nok et link, men det kommer naturligvis IKKE fra dit site. Det kunne komme fra et meget lavt rankende site – bare der er et link søgemaskinerne kan følge, så kan det i princippet blive indekseret. Og er det f.eks. et .edu site du får dit link indekseret på så tæller det ret godt.
Alle former for injections er i mine øjne alvorlige og potentielt farlige fejl. Når først du kan afvikle fremmed kode i et system, så er det næsten kun kreativiteten der sætter begrænsingen.
Udover links kan man i princippet skabe en helt ny side – en side der f.eks. kunne indeholde en formular som sende de informationer man kan lokke brugerne til at indtaste hen til mig. En farlig form for “phising” – for det foregår på DIT domæne!
Med JavaScript bliver mulighederne endnu større. F.eks. kan du jo aflæse brugernes cookies – eller sætte dine egne.
Udover at bruges til SEO (i det begrænsede omfang det dur til noget) eller IT-kriminaliteter, så kan det også bruges til blot at gøre grin med andre. Ville du synes det var fedt, hvis jeg kunne skrive lige det jeg vil på dit website – på en URL skabt af mig, og sendt til alle dem du kender? Nej vel 🙂 Det er vel nærmest den slags man kunne kalde for en XSS defacing.
Morten skriver
Nåeh nej – jeg argumenterer skam ikke for, at man ska’ lægge sin phpinfo-fil op på nettet… Men det har heller aldrig været hensigten med phpinfo().
Er enig i at alle sikkerhedshuller bør lukkes, men lige her er der næsten mere tale om at ha’ misforstået PHP. Svarer jo til at la’ nøglen sidde i døren – på ydersiden. Men de største/fleste sikkerhedsbrister er jo stort set også folk, der ikke har sikret sig mod det ene og det andet.
Tror nu, at cookie-læsning vha javascript injekteret i phpinfo() er mere teoretisk end praktisk mulig. Derudover er det også dårlig stil at placere personfølsomme oplysninger i en cookie. -Og så også gabende kedeligt at læse cookies…
Og nej – gider ikke ha’ dig til at deface min side, men har heller ikke min phpinfo-fil på nettet.
Simon Jensen skriver
Havde godt læst om denne fejl, men havde så helt glemt den igen, lige indtil jeg i sidste uge kom forbi wannafind. Her har man også PHPINFO() liggende “til fri afbenyttelse” – og jeps, den kan også (beklager wannafind – proof of concept).
Mener det var i marts månede man kørte en Month Of PHP Bugs hvor den blev beskrevet. Ligeledes var der en beskrivelse af hvordan man kunne injecte til en mail-header i PHPs inbyggede mail()-funktion – hvilket bliver brugt overalt!
Lad det være sagt – så elsker jeg PHP 🙂
Mikkel deMib Svendsen skriver
Simom forsøgte at poste et eksemel ovenfor – men det format der blev anvendt går ikke igennem WordPress. Men så er der også lidt for læserne at lede efter … 🙂
Simon Jensen skriver
Good old WordPress – de har da også tænkt på alt 😉
Men ang. hacket i phpinfo(), så er det jo et klassisk eksempel på at man aldrig skal tage bruger-input for gode varer!
Mikkel deMib Svendsen skriver
Ja, og det er også et meget godt eksempel på, hvor mange muligheder der for huller. De fleste af de sites jeg ser i dag med XSS huller har sådan set gjort en hel masse for at beskytte deres online applikationer – men så har de bare liiiige glemt et enkelt lille hul, og så er det hele ødelagt.
Det kræver kun et enkelt åbent vindue for at tyven kan slippe uopdaget ind, så at sige 🙂
Simon Jensen skriver
Nemlig, hehe … har du husket at opdaterer dit WordPress?
Selv her skulle det være muligt at udnytte XXS, som man kan læse her:
http://www.hardened-php.net/advisory_012007.140.html
Gælder dog kun versioner ældre end v. 2.0.6.
Thomas skriver
Ja jeg læste det på Dave’s side for et par dage siden. Det er da en rar ting at folk gider at offentliggøre disse ting
Morten skriver
Simon – er enig! Uanset hvad elsker jeg også PHP… Sikkerhedshuller dukker op overalt. Også i WordPress, Mikkel ;o)
Mikkel deMib Svendsen skriver
> Sikkerhedshuller dukker op overalt. Også i WordPress, Mikkel ;o)
WordPress ER i PHP – så de to ting er ikke en modsætning.
En ting er de mange huller der er i diverse open source applikationer skrevet i PHP. Det er udviklernes problem. Men at der opstår sikkerhedshuller som denne i centrale dele af funktionsbiblioteket er altså noget skidt.
Grosen Friis skriver
Det ender med at softwareudvikling kommer til at tage endnu længere tid fremover 😉
Jeg bruger fx i forvejen meget tid/krudt på fx validerng af parametre, når jeg koder (Det gælder også i PHP), da jeg mener det er med til at afsløre fejl i software på et meget tidligt tidspunkt, hvor de er nemme at spotte og få rettet. På sigt gør det kode meget mere fejlfri og “robust”. Derudover tvinger det med-programmører på større projekter til at tænke sig om, inden de fx benytter sig af de klasser (kode) som jeg har skrevet. Smid en streng variabel med et tal ind i en af “mine” metoder/funktioner, der fx kræver en float variabel, og Du får en fejl smidt tilbage i hovedet igen 😉 Ja det tager CPU tid at validere igen og igen, også når kode går i “drift”, men jeg mener helt klart det er det hele værd!
Men det ender med, at man af sikkerhedsmæssige årsager skal til også at kontrollerre alle URL overførste parametre.
– Kommmer de altid fra en side på ens eget domæne, der hvor applikationen kører i drift?
– Er der nye parametre med udover dem som man forventer?
– Sørger man for at få uskadeliggjort evt. injection kode, fx PHP, JavaScript eller SQL?
– Sørger man for at minimere brugen af URL overførste parametre, og i højere og højere grad bruge POST overførte parametre, også selvom det i mange situationer ikke er den letteste måde at overføre parametre på!
Jeg ved dette primært er et indlæg om sikkerhed i software, og ikke om en programmørs kode-vaner, men når jeg læser om denne problemstilling (Den har det jo med at dukke op indimellem 🙁 ) så kommer jeg altid til at tænke på det ansvar man har som programmør, for at gøre det software man koder så fejlfrit og sikkert som muligt. Forebyggelse af fejl og at sikre en høj sikkerhed i software er bare tit “kedeligt” at kode, og det kan måske nogen gange få programmører til at springe over hvor gærdet er lavest. Måske har det også lav prioritet hos ledelsen af et softwarehus/IT afdelinge, da det jo ikke er lig med at man hurtigt får færdige skærmbilleder og underliggende funktioner at se. Sikkerhed og fejlsikring gør jo at software projekter kommer til at tage mere tid, og de bliver dermed dyrere at udvikle.
/Grosen Friis
Mikkel deMib Svendsen skriver
Ja, der er ingen tvivl om at det kan være svært at få virksomheder til at bruge de ekstra programmeringstimer det koster at sikre sin kodes stabilitet og ugennembrydelighed ordenligt. Men jeg tror ikke der er tvivl om at flere vikl komme til at bruge mere tid og resurser på dette.
Web 2.0, med øget brugerinteraktion, Open Source programmer af tvivlsom kvalitet, og AJAX er lige nu de tre mest farlige områder, efter min mening. Alle tre er med til at øge risikoen væsentligt for alvorlige sikkerhedshuller. Og det er netop 3 områder som rigtig mange virksomheder tager i brug i disse måneder og år.
Web 2.0 og den øgede brugerinteraktion er helt fin. Starategisk har jeg intet problem med det – tværtimod! Men når mere data skal flyttes mellem brugerne, sitet og tilbage igen til andre så øger det naturligvis sikkerhedsrisikoen – der er mere der skal tjekkes for risici og flere steder det kan gå galt.
Open Source programmer behøver naturligvis ikke at være dårlige. Der er mange rigtig gode Open Source programmer på markedet. Men absolut ikke dem alle. Og det er langt fra elle, hvor koden er så gennemtænkt at der hurtigt kan dæmmes op for fejl. Særligt har mange Open Source forums (typisk i PHP) været ramt af problemer.
Og så er der AJAX … Well, AJAX kære AJAX. Det er bestemt ikke let med AJAX. Når man ligger alle interaktionerne med de bagvedliggende databaser og systemer ud i client laget, så er det klart at det åbner for et masse sikkerhedsproblemer. Om AJAX helt kan sikres ved jeg faktisk ikke – men man kan med garanti gøre mere end de fleste gør i dag.
Med alt dette, og meget mere, er det jo så bare ærgeligt at der også opstår sikkerhedsprobnlemer i noget så fundamentalt som functionsbiblioteket i et så udbredt kodesprog som PHP. Det er noget skidt.
Claus skriver
Kan se mht. denne bug at man også kan lave sig et array af links og knalde ind, og derved spare lidt tid hvis man er til denne form for udnyttelse 🙂
Hullet virker jo enormt på link industrien, og har da lysten til at drive nogle .edu links ind til et test site for at teste dette. Dog gør jeg det ikke pga. en moral jeg “desværre” besidder..
Tror du ikke søgemaskinerne hurtigt vil fange dette, hvis ikke allerede og devaluerer værdien af links som kommer på denne måde?
Jeg er sikker på mange af mine konkurrenter i min industri vil prøve at udnytte dette