PHP & INSERT INTO mySQL ne radi :(

[Ilija Studen]

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]

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]

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]

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]

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

SQL :: 4 queries were made.

http://maestitia.net/index.php?u=116z

SQL :: No queries were made.

[Ivan]

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]

XSS? Naravno. Opet se zastita svodi na proveru ulaznih podataka.

[Ilija Studen]

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]

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.

[Ivan]

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 ...