Slo-Tech - Za vse programerje v programskem jeziku PHP bo gotovo zanimiva naslednja informacija. Stefan Esser je namreč na svojem blogu objavil predavanje z naslovom Lesser Known Security Problems in PHP Applications, ki ga je imel na Zend konferenci septembra letos.
V predavanju je prikazal nekaj manj znanih možnosti napadov na PHP programsko kodo, na primer možnosti zlorabe zaradi napačne uporabe vhodnega filtriranja, nekatere zlorabe s pomočjo piškotkov, zlorabe spletnih sej, manj znane možnosti izvedbe XSS napadov, manj znane zlorabe SQL, zlorabe šibkih generatorjev naključnih števil, itd.
Sicer djanga ne poznam, sem pa delal s turbogears-om in si večje nočne more človek res ne more želeti.
Poleg tega je PHP kul, ker ima ogromno kul frameworkov in si pač izbereš tistega, ki ti ustreza ali pa celo izdelaš svojega. Jaz prisegam na Zend Framework in zadeva je res zakon.
[to sporočilo bo spremenil upirna, kadar bo to njemu pasalo]
Nic novga v slide-ih v bistvu. Vecino stvari bi ze lahk vsak samospostujoc programer vedu, drgac pa @preem: marsikater teh "vulnerability"-jev se lahk zlorab tudi v pythonu. Ni tle kake absolutno razsvetljive resitve. Use what thou wilt.
Zanimivo. Zanimata me dve stvari: ali se da ponarediti $_SESSION piškotke? Recimo, da predvidevaš, da stran preverja username preko isset($_SESSION['username']). Ali se da server prepričati, da je ta session piškotek nastavljen na nek username, ki obstaja? Druga stvar, ki me zanima pa je, kdaj mysql_real_escape_string() odpove, če so uporabljeni SET NAMES.
Moja domača stran: http://andrej.mernik.eu
Na spletu že od junija 2002 ;)
:(){ :|:& };:
heh.najvecji problem je GLIH v tem, da vecina ljudi uporablja frameworke. Vecina problemov je glih v frameworkih in vec ljudi k jih uporablja vecja je verjetnost, da si bo nekdo vzel cajt in najdu bug v kodi(halo...zadevo se da downloadat). Ampak tle je bl kriv programer kot pa jezik.... ce lahko jst v password field napisem ' or 1=1 -- ....potem vemo kdo je tle kriv.
FUD. Velika večina lukenj je na aplikacijskem nivoju, ne v PHP-ju. Ne prenesem, da nekdo govori o nevarnem PHP-ju, potem pa za primere navaja aplikacije, spisane v PHP. Če spišem en evil program v C++, bo potem implicitno C++ nevaren jezik?
Druga zadeva je, da je dobršen del teh lukenj neodvisnih od serverske tehnologije. Gre enostavno za okolje (teh internets), kjer se pač da narediti to in ono. SQL injection, session hijacking, session fixation, XSS, CSRF? Brez izjeme aplikacijski problemi, ki absolutno niso omejeni le na PHP. Poznam vsaj eno slovensko spletno stran, spisano v ASP, ki prijazno podpira SQL injection. Še več; če vzameš poljubno slovensko spletno stran, ne glede na tehnologijo, lahko zelo verjetno najdeš luknjo prej kot v parih minutah. Gre samo zato, da mora programer vedeti, kaj počne. Programiranje tudi najbolj navadne spletne strani je že zdavnaj preraslo igračkanje z SQL in for-stavki. Nenavadno je, da to ni jasno niti tako tehničnemu občinstvu, kot je prisotno tukaj. Če želiš spisati varno aplikacijo, moraš obvladati cel kup stvari -- ali pa uporabiti framework, ki pokriva tvoje neznanje.
Looka: stvar je natanko obratna. če programer nima znanja, mu je s frameworkom bolje. Si že videl začetnika, ki piše varne aplikacije? Še več -- poznam par strani, kjer programirajo ne-začetniki in so stvari vseeno luknjaste. Problem je v lastnem razvoju. Če se greš to, moraš natanko vedeti kaj počneš, drugače imaš garantirano več lukenj, kot kakšen stabilen framework. Po drugi strani pa če programer ve, kaj dela, potem ponovno profitira s frameworkom, ker zna izbrati pravega. Po možnosti še odkrije in odpravi kakšen hrošč in vsi profitirajo.
PHP je pač najbolj razširjena tehnologija na spletu in ima zato največ aplikacij (tudi največ slabih aplikacij), vendar to še ne pomeni, da je PHP nevaren. Ima največ primerov med spletnimi napadi, kar je spet logično, ker ima največ strani na spletu. Ima spisano goro aplikacij in je najpogostejša tarča.
Prava slabost PHP-ja (v smislu varnosti, ima seveda tudi druge), je v tem, da ima nizko vstopno mejo in hiter output. Vsak otrok lahko v njem spiše in postavi spletno stran iz nule, česar ne morem trditi za ostale jezike. To pa seveda pomeni, da bo cel kup začetnikov hitro spisalo cel kup nevarnih aplikacij. Ki bodo sicer nevarne same od sebe, ne zaradi PHP-ja, ampak je PHP na nek način to omogočil.
vse to je res. ni programski jezik kriv, če je programer smotan. in da, tudi v phpju obstajajo frameworki, ki ti olajšajo take in podobne stvari.
jaz sem pač hotel poudarit, da ima django (verjetno, tudi kakšni php frameworki) to pošlihtan, in že framework sam pri sebi poskrbi za varnost proti npr SQL injectionu. Prednost tega se mi zdi, da tebi ni potrebno pisat stvari ki so trivialne. reinvent the wheel, temu pravjo, saj verjetno poznate rek.
drgač se pa strinjam da je to svar aplikacije in mora programer za take stvari poskrbet. edin tople vode vsak dan posebi pač nima smisla izumljat.
Ja, je stvar programerja. Vendar se PHPju pozna,d a je bil razvit že leta nazaj, zato za razliko od npr. Djangota v sam jezik niso vgrajene ustrezen kontrole.
Preverjanje URL vnosov se seveda da v PHP prav lepo izvesti, vendar je v Djangotu v primerjavi s PHP to otročje lahko. V tem je "nevarnost" PHPja.
Zloraba oblasti, avtokracija in tema nikoli ne pridejo hipoma, vedno je vmesno
obdobje mračenja, ko se dan preveša v noč; biti moramo pozorni opazovalci
okolja in varuhi luči, da ne postanemo nemočni ujetniki teme. --W. Douglas
Ja, je stvar programerja. Vendar se PHPju pozna,d a je bil razvit že leta nazaj, zato za razliko od npr. Djangota v sam jezik niso vgrajene ustrezen kontrole. Preverjanje URL vnosov se seveda da v PHP prav lepo izvesti, vendar je v Djangotu v primerjavi s PHP to otročje lahko. V tem je "nevarnost" PHPja.
če že primerjaš primerjaj jezike, ne pa frameworka in jezika
tudi vsak resen php framework ima ustrezne validatorje
Kot algoritem za one-way hash je pomoje SHA-1 boljsa izbira kot MD5. Pri MD5 obstajajo collisioni. Mozno je v sekundi zgenerirati dve datoteki z razlicno vsebino in istim hashom. Ce isto stvar dodas obem datotekam bo hash se vedno enak za obe datoteki. To potem lahko izkoristis tako, da tisti skupen del nekako dela razlicne stvari glede na zacetek datoteke, kjer je razlika. Tako lahko naredis par prijazen / zloben PDF, program itd. Vsak od teh seveda vsebuje payload od zlobnega in dobrega programa. Noter je en if, ki gleda na zacetek datoteke in se tako ena drugace obnasa kot druga.
crypt() je samo wrapper za crypt() iz sistemske knjiznice. Tukaj imas ponavadi izbiro med DES, MD5 in Blowfish. Ce hoces shraniti izvlecek passworda je to cisto dovolj dobro. Razlika je samo v tem kako hitro lahko nekdo iz hash-a pridobi plain-text geslo. Pri MD5 in Blowfish recimo je samo kodiranje pocasneje kar pomeni, da password cracker za preverjanje istega stevila moznosti (pri napadu z grobo silo oz. slovarjem) potrebuje dalj casa, je pa seveda tako tudi tvoj program (zanemarljivo) pocasnejsi. Je pa MD5 v tem primeru pomoje se zmeraj dovolj varen. Problem je le ce se zanasas na MD5 hash datoteke.
Pri crypt() imas tudi salt - nakljucna vrednost, ki povzroci da se isti password ne shashira zmeraj v isto vrednost. Seveda to lahko naredis tudi na roko, tako da nekaj random appendas passwordu in ga spustis cez recimo MD5. Edina razlika je, da je vse skupaj bolj zakomplcirano s crypt pac lepo takoj dobis izhod v standardni obliki $1$salt$md5hash pri cemer je md5hash pridobljen kot MD5 (salt + password). Pri PHP-ju se ti dejansko sploh ni treba ukvarjati z generiranjem salta.
Še en članek v povezavi z varnostjo jezikov in frameworkov: Is your Rails application safe? Jasno je, da je tu problem Rails (torej ne Ruby in absolutno ne PHP) in da gre za dokaj velik problem v RoR spletih aplikacijah (ki pa ni bug, temveč kar feature).
fiction: vsak hashing algoritem ima collisione. Še več, vsak hash ima neskončno možnih collisionov, ker gre za preslikavo iz neskončne zaloge vrednosti (vsi možni vstopni podatki) v končno množico (hash fiksne dolžine). Poleg tega je primer, ki ga navajaš za md5, v praksi precej težji, kot opisuješ.
vse to je res. ni programski jezik kriv, če je programer smotan. in da, tudi v phpju obstajajo frameworki, ki ti olajšajo take in podobne stvari.
jaz sem pač hotel poudarit, da ima django (verjetno, tudi kakšni php frameworki) to pošlihtan, in že framework sam pri sebi poskrbi za varnost proti npr SQL injectionu. Prednost tega se mi zdi, da tebi ni potrebno pisat stvari ki so trivialne. reinvent the wheel, temu pravjo, saj verjetno poznate rek.
drgač se pa strinjam da je to svar aplikacije in mora programer za take stvari poskrbet. edin tople vode vsak dan posebi pač nima smisla izumljat.
Vsekakor, frameworki v PHP-ju so na spodobnem nivoju (npr. symfony je že pred Djangom uporabljal ločen subframework za output-escaping). Svetlobna leta pred programiranjem vsega tega na roko. Ampak imaš stvari, za katere framework ne more vedno poskrbeti, ker ti ne bere misli in ne zna predvideti vseh možnih situacij. Tako lahko spišeš luknjasto aplikacijo tudi v Djangotu, če ne veš, kaj delaš.
Skratka, če uporabiš spodoben PHP framework, se lahko, tako kot ti, takim novicam samo nasmehneš. Moti me samo to, da prikazujejo napačno sliko, kljub temu, da povejo dejstva -- gre za interpretacijo.
Kot da zlorab že ni dobesedno ogromno - in to vsak dan.
Zloraba oblasti, avtokracija in tema nikoli ne pridejo hipoma, vedno je vmesno
obdobje mračenja, ko se dan preveša v noč; biti moramo pozorni opazovalci
okolja in varuhi luči, da ne postanemo nemočni ujetniki teme. --W. Douglas
V čem je sploh fora teh frameworkov? Ker meni je čisti PHP normalno jasen in enostaven za uporabo - ko pa enkrat vidiš naprimer Zend Framework je pa tema.
A ni mogoče narediti normalne spletne strani brez, da bi uporabil objektiven jezik ali XXX framework...?
Seveda je. Ampak framework ti močno olajša določene stvari, pa recimo Zend Framework, ki ga omenjaš, prinese tudi možnost MVC, ki zelo olajša določene zadeve in kodo naredi bolj pregledno.
Morda framework še ni tak problem - problem je, ker se vse skupaj hoče objektno orientirano programiranje. To pa meni ravno ne gre. Pa sem prebral mnogo teorije ter pregledal ogromno primerov še vedno mi nekako ni jasno v čem je fora tega. Ker je veliko bolj logično, če se vsega lotiš po nekem postopku. Pa tale model view controller je prav tako ena čudna stvarca - ki mi je jasna še veliko manj kot OOP. To je bil tudi razlog, da nisem kaj pretirano nadaljeval z prebiranjem dokumentacije za razvijanje iPhone aplikacij.
fiction: vsak hashing algoritem ima collisione. Še ve�, vsak hash ima neskon�no moŞnih collisionov, ker gre za preslikavo iz neskon�ne zaloge vrednosti (vsi moŞni vstopni podatki) v kon�no mnoŞico (hash fiksne dolŞine). Poleg tega je primer, ki ga navajať za md5, v praksi precej teŞji, kot opisujeť.
No ok, mogoce sem se malce slabo izrazil - "ima" v stilu da je mozno najti par razlicnih vhodov, ki dajo isti hash v sprejemljivem casu. Logicno je, da mora obstajati neskoncno collisionov, ampak to nic ne pomaga, ce je zelo tezko poiskati tak par.
Primer v praksi ni nic tezji. Na podlagi teoreticnih izsledkov Wang-a in Yu-a se da narediti marsikaj z MD5. Klik
Ampak v praksi je collision na neki spletni strani še najmanjši problem. Če bi bil to edini problem, bi bile spletne strani zelo varne.
Zloraba oblasti, avtokracija in tema nikoli ne pridejo hipoma, vedno je vmesno
obdobje mračenja, ko se dan preveša v noč; biti moramo pozorni opazovalci
okolja in varuhi luči, da ne postanemo nemočni ujetniki teme. --W. Douglas
Nikoli nisem trdil cesa drugega. Vse skupaj je bilo misljeno kot odgovor na R33D3M33R-jevo vprasanje. Kot je napisal dbevfat mora do collisionov nujno priti, ker gre za preslikavo iz vecje (neskoncne) mnozice v manjso mnozico.
Razlika je samo v tem, da za MD5 obstajajo efektivni nacini kako dobiti dva vhoda z istim hashom, medtem ko cesa takega pri SHA-1 se ni. Ne recem, v prihodnosti lahko kdo najde kaj takega, ampak za enkrat se meni osebno zdi bolj varna uporaba SHA algoritmov. Med drugim je njihova dolzina tudi daljsa (> 160 bitov) za razliko od MD5 kjer je hash 128 biten.
Ampak v praksi je collision na neki spletni strani še najmanjši problem. Če bi bil to edini problem, bi bile spletne strani zelo varne.
Vecina "spletnih napadov" (XSS, CSRF, session fixation itd.) je za spletno stran oz. web server se najmanjsi problem. :) V principu je napaden uporabnik, ranljiv server sluzi samo kot neke vrste posrednik. Edina problematicna stvar, kar se tice kompromitiranja streznika, je mogoce se SQL injection.
Kako problematicen je hash collision je precej odvisno od konteksta. Spletna storitev za deljenje slik / PDF dokumentov bi recimo lahko bila prizadeta, ce bi se kot ID uporabljal MD5. Seveda bi bilo vse skupaj spet usmerjeno proti uporabniku - en uporabnik bi tako lahko npr. drugemu podtaknil dokument, ki bi izgledal veljaven (kot da je od nekoga drugega).
Hm, torej če prav razumem je načeloma vseeno katero zadevo uporabim, se pa priporoča sha1 ali hash('sha256', $string), čeprav ne bo tudi nič narobe, če uporabljam crypt?
Moja domača stran: http://andrej.mernik.eu
Na spletu že od junija 2002 ;)
:(){ :|:& };:
![[:P]](http://slike.slo-tech.com/smeski/icon_razz.gif){kind=icon}