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.
Vsekakor vredno branja.
Novice » Varnost » Manj znane varnostne ranljivosti PHP programske kode
preem ::
še en razlog več, zakaj se je treba počas oddaljit od phpja.
odkar uporabljam python in django, se takim člankom samo še nasmehnem
odkar uporabljam python in django, se takim člankom samo še nasmehnem
bsaksida ::
dej no.Pythonu se da tud zlorabit, tud če so znane ali neznane metode. Nič ni 100% VAREN
upirna ::
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.
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]
Zgodovina sprememb…
- spremenil: upirna ()
Alpheus ::
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.
VI VERI VENIVERSUM VIVUS VICI.
R33D3M33R ::
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.
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 ;)
:(){ :|:& };:
Na spletu že od junija 2002 ;)
:(){ :|:& };:
R33D3M33R ::
Torej session podatki se shranjujejo na strežniku? Kaj se pa potem shranjuje v brskalniku?
Moja domača stran: http://andrej.mernik.eu
Na spletu že od junija 2002 ;)
:(){ :|:& };:
Na spletu že od junija 2002 ;)
:(){ :|:& };:
Looooooka ::
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.
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.
dbevfat ::
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.
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.
nvr2fat
preem ::
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.
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.
poweroff ::
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.
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.
sudo poweroff
R33D3M33R ::
@arjan_t : Hvala za odgovor.
Imam pa še eno vprašanje, kaj je varneje md5(), sha1(), crypt() ali password()?
Imam pa še eno vprašanje, kaj je varneje md5(), sha1(), crypt() ali password()?
Moja domača stran: http://andrej.mernik.eu
Na spletu že od junija 2002 ;)
:(){ :|:& };:
Na spletu že od junija 2002 ;)
:(){ :|:& };:
arjan_t ::
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
arjan_t ::
Imam pa še eno vprašanje, kaj je varneje md5(), sha1(), crypt() ali password()?
če se da uporabi hash('sha256', $string) s saltingom
tudi md5 in sha1 sta s saltingom sprejemljiva
fiction ::
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.
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.
dbevfat ::
Š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š.
lp
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š.
lp
nvr2fat
Loki ::
urrm se da videti kodo php funkcij kje? oz. so le-te napisane v php in se potem izvajajo?
I left my wallet in El Segundo
dbevfat ::
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.
lp
nvr2fat
dbevfat ::
urrm se da videti kodo php funkcij kje? oz. so le-te napisane v php in se potem izvajajo?
Native code je napisan v C-ju in je na voljo preko CVS-ja ali downloada. Določene knjižnice so pa spisane v PHP-ju, vendar te ne spadajo v PHP jedro.
lp
nvr2fat
Icematxyz ::
Če bi PHP res tako zlahka zlorabili potem bi vrjetno polovica spletnih strani delovala bistveno slabše kot deluje.
Pa se svet še vedno vrti v pravo smer.
Pa se svet še vedno vrti v pravo smer.
roli ::
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...?
A ni mogoče narediti normalne spletne strani brez, da bi uporabil objektiven jezik ali XXX framework...?
http://www.r00li.com
KoMar- ::
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.
Zgodovina sprememb…
- spremenil: KoMar- ()
roli ::
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.
http://www.r00li.com
fiction ::
Malce offtopic:
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
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
$ ./fastcoll -o test.1 test.2
MD5 collision generator v1.0
by Marc Stevens (http://www.win.tue.nl/hashclash/)
Using output filenames: 'test.1' and 'test.2'
Using initial value: 0123456789abcdeffedcba9876543210
Generating first block: .....
Generating second block: ......
Running time: 188.45 s
$ md5sum test.1 test.2
9123145d4e30d475f0561035bf8712b3 test.1
9123145d4e30d475f0561035bf8712b3 test.2
$ echo "nek tekst" >> test.1
$ echo "nek tekst" >> test.2
$ md5sum test.1 test.2
0827a08437d5953dabaf19a86b87ee0d test.1
0827a08437d5953dabaf19a86b87ee0d test.2
$ xxd test.1
0000000: 0bd8 7e91 43e7 364c 51f3 8649 d4ef 4862 ..~.C.6LQ..I..Hb
0000010: bb39 70d9 38e3 248a 3b91 7d6b 3ac8 559e .9p.8.$.;.}k:.U.
0000020: d56c 0406 0940 b443 1be3 7874 1333 31d3 .l...@.C..xt.31.
0000030: da1e 4309 ed8d 2be9 492a 3b87 27c5 c4b1 ..C...+.I*;.'...
0000040: 5326 4ef6 7c65 9e66 9bb8 d82b 5caa 5ecc S&N.|e.f...+\.^.
0000050: d7bb 3828 c4de 4c2e 1afd f547 d1ac 9cef ..8(..L....G....
0000060: 5d07 b39a af1a bb8c 4a9a 574f 840c d29b ].......J.WO....
0000070: 0a91 3aa7 55ba 13d5 f1a2 2edf 1b7f 08fa ..:.U...........
0000080: 6e65 6b20 7465 6b73 740a nek tekst.
$ xxd test.2
0000000: 0bd8 7e91 43e7 364c 51f3 8649 d4ef 4862 ..~.C.6LQ..I..Hb
0000010: bb39 7059 38e3 248a 3b91 7d6b 3ac8 559e .9pY8.$.;.}k:.U.
0000020: d56c 0406 0940 b443 1be3 7874 13b3 31d3 .l...@.C..xt..1.
0000030: da1e 4309 ed8d 2be9 492a 3b07 27c5 c4b1 ..C...+.I*;.'...
0000040: 5326 4ef6 7c65 9e66 9bb8 d82b 5caa 5ecc S&N.|e.f...+\.^.
0000050: d7bb 38a8 c4de 4c2e 1afd f547 d1ac 9cef ..8...L....G....
0000060: 5d07 b39a af1a bb8c 4a9a 574f 848c d19b ].......J.WO....
0000070: 0a91 3aa7 55ba 13d5 f1a2 2e5f 1b7f 08fa ..:.U......_....
0000080: 6e65 6b20 7465 6b73 740a nek tekst.
Matevžk ::
rolihandrej, objektno programiranje in MVC sta se razvila iz potrebe. Na resnih, velikih projektih boš brez tega zelo zabredel ... IMHO.
lp, Matevžk
roli ::
To je seveda čisto možno. Trenutno nisem opazil še nobene potrebe po tem. Pa tudi nisem imel ravno kaki mali projekt.
http://www.r00li.com
poweroff ::
Collisioni so možni povsod. Tudi v SHA.
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.
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.
sudo poweroff
fiction ::
Collisioni so možni povsod. Tudi v SHA.
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).
R33D3M33R ::
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 ;)
:(){ :|:& };:
Na spletu že od junija 2002 ;)
:(){ :|:& };:
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Varno nakupovanje preko e-bayaOddelek: Loža | 5790 (4438) | THXMASTER |
| » | 1830 (1301) | SeMiNeSanja | |
| » | Flame izkoriščal Microsoftove certifikateOddelek: Novice / Varnost | 7787 (5692) | MrStein |
| » | iPad in BigBang (se zgodi)Oddelek: Strojna oprema | 5465 (4826) | bezerk |
| » | Vgrajeni GPS-čipi v telefonih prinašajo nove pastiOddelek: Novice / Android | 7336 (5586) | techfreak :) |