Glasanje: prevencija "SQL injection"

[LiquidBrain]

jeste, ali je mysqli vezan samo za mysql, nesto nije portabilan? A sem toga postoje ljudi koji koriste i druge baze...

[Ivan]

Uglavnom, kao sto je i navedeno do sada bitno je filtrirati ulazne vrednosti tj odstraniti ono sto ne treba da se pojavi u upitu.

Vecina stvari se zavrsi cast-ovanjem varijabli i zabranom kljucnih reci (SELECT, INSERT, SLEEP, ...) i/ili karaktera (', %, ;,...).

Dosta je bitno sta se zapravo od logike aplikacije ocekuje a sta ne, nekad security moze da smanji upotrebljivost aplikacije pa se samim tim mora ici drugim putem ...

[degojs]

Parametri.. i rešena stvar, nema brige. A ako iz nekog razloga ne može sa parametrima, onda ne može, šta da se radi

[Dejan Topalovic]

Originalno napisao Dragi Tata

За сада ми се допадају Робијев и Јабланов одговор. Него, баш ме занима шта мисле Дејан Топаловић, Дегојс и још пар људи који се не јављају.

Evo javljam se Ejs ko da sam ja neki autoritet na podrucju baza podataka, pa da ti treba i moje misljenje hehehe

Iskreno, sa MySQL-om ne radim aktivno vec nekoliko godina , jer zbog prirode posla sam prinudjen iskljucivo na Oracle bazu, tako da mogu samo za nju nesto reci...

Mi imamo kompleksan sistem, u kojem se koriste razne intranet i internet aplikacije, pocevsi od desktop aplikacija uradjenih u Delphiju i Visual Basicu, preko batch operacija (scheduler + sqlplus i sl.), pa sve do viseslojnih Java aplikacija (browser based: proxy, connection manager, application server).
Vjeruj mi da je tesko postici neko homogeno rjesenje, kojim bi se 100% sprijecio neki napad ili provala u sistem.

Ukratko, direktno u bazi koristimo parametrizovane procedure, redovno kontrolisem access logove (plus auditing svih SYSDBA komandi) i instaliram sigurnosne zakrpe (Critical Patch Update).

Java programeri koriste "sanitization" ulaznih podataka (dvojica od njih trenutno cak zavrsavaju master studij zasnovan na IT security podrucju) i nismo imali jos nijedan slucaj upada u sistem preko neke Java aplikacije.

Imali smo do sada 2 manja upada u sistem, tj. na web server, a za sve je bilo krivo nekoliko bugova u PHP-u, pomocu kojih je bio omogucen remote exploit. Nismo imali nikakve vece stete, osim par dana prekovremenog rada i izgubljenih zivaca. Zbog ta 2 slucaja je donesena odluka da se PHP u potpunosti izbaci iz sistema i da se svi buduci online projekti zasnivaju na Javi.

Eto, ne znam sta bih vise dodao na ovu temu ...

[ivanhoe]

@dejan: Jel moze samo malo detaljnije ovo oko bugova u php-u, jel mislis na bagove u php skriptama, ili bas propuste u samom php-u?

@svi: Da li koristite view-ove i stored procedure kao meru zastite?

[robi-bobi]

^ hm, zasto bi (t.j. kako) view bio mera zastite?
P.S. da, i mene interesuje ovo za php

[Dejan Topalovic]

Originalno napisao ivanhoe

@dejan: Jel moze samo malo detaljnije ovo oko bugova u php-u, jel mislis na bagove u php skriptama, ili bas propuste u samom php-u?

Nakon svakog upada, angazovali smo eksternu security firmu (al' su nas oderali, satnica im je bila 200 EUR), koja je pregledala sve application servere i nakon visesatne/visednevne lobotomije ustanovila da se radilo o propustima u samom PHP-u, a u drugom slucaju o PHP-u i ActiveDirectory-u.

Od tada je PHP banovan kod nas.

[mangia]

Ne bih da budem prepotentan ali za 0 Eura ću vam reći (sa sigurnošću od 99.998%) da je u pitanju propust programera a ne PHP-a...

[Dejan Topalovic]

^ de "Milane" vidi nabrzaka sta mi pise u horoskopu i baci grah nabrzaka, vidi sa 99.99999% sigurnoscu sta ce mi donijeti bliza buducnost ...

[LiquidBrain]

PHP nije jedini koji ima mana i bugova... Ako cemo tako ni Java nije 100% sigurna... Svakako morash da terash za javu neki aplikativni server... Pogledaj samo koliko propusta postoji za Tomcat, Glassfish, JBOSS...

Poenta je da drzite sistem up to date...