-
PHP
(
http://www.devprotalk.com/forumdisplay.php?f=9)
| Ilija Studen |
13. 10. 2006. 18:27 |
Citat:
Originalno napisao LiquidBrain
Pa ukoliko dodje do kompromisovanja baze, eventualno cu da imam IP (sem ukoliko ne ide preko proksija) A btw, logujem ceo query, tako da ukoliko imam propust, mogu da ispravim odmah, jer znam gde je :)
|
To je pointless IMO. Šta misliš i ideji da napraviš tako priču da jednostavno koje god parametre da proslediš ti dobiješ ispravan SQL na kraju, pravilno escapeovan? Tako nešto radi kod gore - greška neće biti uzrokovana vrednostima parametara, već samo ako pogrešno formiraš upit (a to nije security risk).
PHP je na lošem glasu baš zato što su rešenja koja "loguju IP adrese kada nešto pođe loše" i rade slične mađijanja koja nemaju previše smisla rasprostranjenija od rešenja koja ne dozvoljavaju da injectiona dođe.
My $0.02 |
| ivanhoe |
13. 10. 2006. 18:47 |
Citat:
Originalno napisao Ilija Studen
To je pointless IMO. Šta misliš i ideji da napraviš tako priču da jednostavno koje god parametre da proslediš ti dobiješ ispravan SQL na kraju, pravilno escapeovan? Tako nešto radi kod gore - greška neće biti uzrokovana vrednostima parametara, već samo ako pogrešno formiraš upit (a to nije security risk).
PHP je na lošem glasu baš zato što su rešenja koja "loguju IP adrese kada nešto pođe loše" i rade slične mađijanja koja nemaju previše smisla rasprostranjenija od rešenja koja ne dozvoljavaju da injectiona dođe.
My $0.02
|
Ne slazem se. Po meni je vrlo smisleno da ako upit nije dobar lepo napises kulturnu poruku o gresci i logujes dogadjaj u neki fajl, a ukoliko je ocigledno da se radi o napadu, onda ne samo da logujes IP, nego i blokiras doticnog smaraca na 10-15 minuta, ili ga posaljes na laznu stranu gde moze da se igra pokusavajuci da nesto uhakuje (takozvani "tar hole")
Ukoliko se radi o napadacu koji pokusava da te uhakuje, sta ima njemu da popravljas sql, koji je smisao toga, samo se povecava sansa da pronadje neku rupu (jer mu dajes feedback, za razliku od genericke poruke o gresci)
A ukoliko imas bug u aplikaciji onda je bolje da upit pukne, pa da tokom testiranja mozes lepo da vidis da nesto ne valja, nego da skripta trosi procesorsko vreme da popravi pogresan upit, potencijalno sireci bug kroz aplikaciju i otezavajuci debug.
Ok naravno, postoje neki primeri gde ne treba biti extreman, tipa unos broja telefona ili broja kreditne kartice, logicno da treba pokusati da popravis pogresno formatirane podatke, a ne da smaras korisnika.. |
| LiquidBrain |
13. 10. 2006. 19:01 |
Naravno da prvo impementiram reshenje koje proverava ispravnost parametara prosledjenih u query. A ako taj query nije ispravan i ima znake pokushaja napada, onda mi je logicno da u fajl strpam podatke koje ce mi pomoci da vidim shta je doticni pokushao, i da li mu je uspelo. Svi znamo da ne postoji bug free kod. A to je pogotovu slucaj sa AJAX-om, koji je implementiran u projekat iz price. Poshto su zahtevi na skripte "maskirani" i obican korisnih ih ne vidi, a javascript radi proveru podataka, ako dodje do nekog "cudnog" querija bolje mi je da logujem celu pricu jer je jasno da to nije neki obican korisnik uradio, vec neko ko je analizirao javascript.
Naravno ista provera parametara se vrshi i u php skriptama... Shto je sigurno sigurno je ;)
|
| Ilija Studen |
13. 10. 2006. 19:13 |
Pogrešno sam se odrazio. Ne popravljanje nego pravilno escapeovanje. Ako su podaci pravilno escapeovani, a programer je napisao pravilan upit jedina situacija kada će tako nešto da pukne je ako server baze počne da brlja, a to se ne dešava tako često.
Znači ne popravljanje nego prosleđivanje uvek pravilno formatiranog upita sa escapeovanim parametrima.
Da li će neko da se igra sa parametrima ili ne apsolutno te ne zanima pošto šta god da uradi to će biti sačuvano u bazi kao string (tu uvek važi pravilo i escapeovanja outputa).
|
| bojan_bozovic |
13. 10. 2006. 21:49 |
Citat:
Originalno napisao ivanhoe
Ne slazem se. Po meni je vrlo smisleno da ako upit nije dobar lepo napises kulturnu poruku o gresci i logujes dogadjaj u neki fajl, a ukoliko je ocigledno da se radi o napadu, onda ne samo da logujes IP, nego i blokiras doticnog smaraca na 10-15 minuta, ili ga posaljes na laznu stranu gde moze da se igra pokusavajuci da nesto uhakuje (takozvani "tar hole")
Ukoliko se radi o napadacu koji pokusava da te uhakuje, sta ima njemu da popravljas sql, koji je smisao toga, samo se povecava sansa da pronadje neku rupu (jer mu dajes feedback, za razliku od genericke poruke o gresci)
A ukoliko imas bug u aplikaciji onda je bolje da upit pukne, pa da tokom testiranja mozes lepo da vidis da nesto ne valja, nego da skripta trosi procesorsko vreme da popravi pogresan upit, potencijalno sireci bug kroz aplikaciju i otezavajuci debug.
Ok naravno, postoje neki primeri gde ne treba biti extreman, tipa unos broja telefona ili broja kreditne kartice, logicno da treba pokusati da popravis pogresno formatirane podatke, a ne da smaras korisnika..
|
To je bespotrebno komplikovanje.
1.Proveris da li je URI enkodiran ispravno
2. Uvek proveris tip i opseg svakog podatka koji korisnik moze poslati (je li alfanumericki npr. ili broj, dobar i enkodiran URI itd. Tu spada svaki GET i POST parametar, kao podaci cookija)
3. Dodeli inicijalnu vrednost svakoj promenjljivoj koju ces koristiti.
Zato je lose i meni se ne svidja sto PHP nije strongly-typed,mnogo stosta bi interpreter automatski proveravao, ne bih to morao sam raditi. Provera je jednostavna, samo greska i izostavljanje iste moze da bude problem.
EDIT: evo primera:
http://maestitia.net/index.php?u=116
Citat:
SQL :: 4 queries were made.
|
http://maestitia.net/index.php?u=116z
Citat:
SQL :: No queries were made.
|
|
O ovome moze da se prica ceo dan ali da sumiram:
Nije dovoljno zastiti se samo od SQL injectiona jer postoji jos puno vrsta napada koji na kraju cak mogu da naprave SQL propuste koji se mogu iskoristiti.
Printanje detaljnih poruka o greskama je dobra praksa pri developingu a logovanje pri samom radu aplikacije.
E sad, ako ce da pricamo o vrstama zastita i mestima gde se greske prave, onda da lepo otvorimo novu temu ;)
|
| bojan_bozovic |
14. 10. 2006. 00:28 |
XSS? Naravno. Opet se zastita svodi na proveru ulaznih podataka.
|
| Ilija Studen |
14. 10. 2006. 00:34 |
Citat:
Originalno napisao bojan_bozovic
XSS? Naravno. Opet se zastita svodi na proveru ulaznih podataka.
|
Ne nužno. Postoje aplikacije kojima je normalno da im podaci budu potencijalno opasni ako se ne esacapeuju pravilno. Primera radi, neki korisnik activeCollaba postuje JS snippet u poruci ili komentaru - to je skroz OK, ali moglo bi biti potancijalan propust da ga activeCollab ne escapuje.
Za ovo je bitno escapeovanje podataka pri printanju. Ulaz može da bude "zagađen". |
| bojan_bozovic |
14. 10. 2006. 00:44 |
JS snippet nije opasan. Moguc je injection JS ali opet ako ne proveris ulazne podatke idemo ovako http://www.google.com" onload='alert(document.cookie)'></a>
Fala bogu ovo samo na najgorem mogucem radi - pa sa window.open otvorimo url na nasem serveru i logujemo cookije.
Evo ga:
" [img] http://maestitia.net/stats/ar.png [/img] "
Ne mislim da phishujem ovde. Ovo admin da vidi.
Busno je ovo da ga nema gde.
I samo se u log pogleda, nego sta. neko ce da naleti. |
Da, sto se tice XSS tu je bitno kako printamo output. Tj prilikom projektovanja aplikacije prvo treba videti sta ona treba da radi i na koji nacin a onda odluciti koju tehniku koristiti za zastitu od navedenih propusta. Najbolje je razdvojiti funkcije koje sluze za prevenciju ulaznih i izlaznih podataka.
Nije preterano komplikovano napraviti ni neku univerzalnu funkciju kojoj mozemo zadavati parametre koje zelimo tj sta i kada zelimo da radi ali opet to je sve stvar potrebe ...
|
| Vreme je GMT +2. Trenutno vreme je 19:55. |
|
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.
