Glasanje: prevencija "SQL injection"

[holodoc]

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

Nije ni PHP baš toliko nevin s obzirom da ima jako interesantnu istoriju bagovitih buildova posebno u periodu dok je "četvorka" žarila i palila web development scenom. Često se dešavalo da upravo novi build unese nove propuste koji u prethodnoj verziji nisu postojali pa je tako neko osnovno pravilo koje se preporučuje u slučaju PHPa da se pre updatea na novu verziju ostavi da ona "sazri". Drugim rečima tek kada bug trackeri za dotičnu verziju počnu da skapaju od gladi i naslovi tema na mailing listama vezanim za novu verziju PHPa ne prestanu da počinju sa "[Help]", "[Bug]" itd. preporučuje se prelazak na novu verziju. Po meni jedina stvar koja je gora od korišćenja stare verzije softvera za koju su poznati svi ozbiljni bugovi je korišćenje nove za koju se ne zna kakve sve boljke može da sadrži pod haubom.

Vezano za tehnike prevencije SQL injekcije moj stav je da kada god mogu koristim PDO. U PHPu, koji najčešće koristim u poslednje vreme, nažalost često dolazim u situaciju da PDO nije dostupan ili je jednostavno u pitanju postojeći kod gde mora da se koriste ugrađene PHP funkcije za prevenciju injekcije. U takvim slučajevima ne preostaje ništa drugo nego otvaranje šestoro očiju jer escape-ovanje ugrađenim PHP funkcijama može ponekad da bude veoma "mutno". Poslednje negativno iskustvo koje sam imao sa njima je bilo pre par meseci kada sam na analizu dobio gotov sistem koji je uporno propuštao injektovane podatke u bazu koji su kasnije mogli da se bez problema iskoriste za XSS napade. Ispostavilo se da je originalni autor veoma uspešno rešio problem prevencije SQL injekcije korišćenjem mysql_real_escape_string funkcije nad početnim podacima (klasično textarea polje) međutim pretpostavio je da jednom escapeovani maliciozni podaci u bazi više ne predstavljaju problem tako da kada se "povuku" iz baze više nisu opasni. Drugim rečima, u toku upisa podataka nakon njihove izmene (edit) nije korišćen mysql_real_escape_string jer je autor pogrešno pretpostavio da pomenuta funkcija u stvari "čisti" maliciozni kod koji se upisuje u bazu.

Što se tiče korisnih alatki za testiranje web sajtova na najznačajnije propuste zaista od srca preporučujem Acunetix Web Vulnerability Scanner. Tačno je da je izuzetno skupa a i da se veoma teško može naći u "narodskoj" verziji ali iako izgleda kao još jedna u nizu aplikacija koja "ubode" tu i tamo pokoji propust u web aplikacijama ova alatka se kod mene pokazala kao odličan izvor jako korisnih informacijama o propustima na sajtu. Dobra stvar je što za svaki propust koji se pronađe u web aplikaciji postoje detaljni opisi i linkovi ka dodatnim informacijama o konkretnom propustu što znači i da je ekstra pogodna za edukativne svrhe.

[bOkIcA]

Ovo gore navedeno vazi za svaki OS, programski jezik ili aplikaciju odnosno ne znam niti jedan na koji to ne moze da se primeni.

[mb_sa]

@holodoc

Jesu li rješili problem sa SEO (clean) URL-ovima? Koristio sam poodavno Acunetix Web Vulnerability Scanner i koliko se sjećam nije mogao da testira sajtove koji su imali SEO urls.

[holodoc]

Originalno napisao mb_sa

@holodoc

Jesu li rješili problem sa SEO (clean) URL-ovima? Koristio sam poodavno Acunetix Web Vulnerability Scanner i koliko se sjećam nije mogao da testira sajtove koji su imali SEO urls.

Verzije koje sam koristio u poslednje dve-tri godine nisu imale apsolutno nikakvih problema sa bilo kojim oblikom SEO optimizovanih linkova.

[ivanhoe]

Originalno napisao robi-bobi

^ hm, zasto bi (t.j. kako) view bio mera zastite?

u kombinaciji sa stored procedurama kao vid kontrole koje podatke mozes da dohvatas, a koje ne..

[mangia]

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

Ne moze... Ne slusas "White Snake"

Šalu na stranu ali pokušavam reći da je PHP jedan od najčešćih i nalakših jezika za početnike od kojih većina prve korake pravi zahvaljujući sumnjivim tutorialima i copy - paste metodom bez imalo razmišljanja o bezbijednosti...

Ako su ti profesionalci već rekli da je do PHP-a niste morali prepisivati aplikaciju drugim jezikom. Mogli ste uraditi update ili prepravku problematičnog dijela koda...

sta ce mi donijeti bliza buducnost ...

Vidim neko pivo na moj račun... Samo da dodješ u BL...

[Dejan Topalovic]

Originalno napisao mangia

Ako su ti profesionalci već rekli da je do PHP-a niste morali prepisivati aplikaciju drugim jezikom. Mogli ste uraditi update ili prepravku problematičnog dijela koda...

Pa prvi put je šef progledao PHP-u kroz prste i ta aplikacija se nastavila razvijati u PHP-u. Međutim, nakon drugog slučaja je šef bez puno razmišljanja otpisao PHP za sve buduće projekte...
Naravno da su u mnogim slučajevima krivi i sami programeri, ali ove propuste u PHP-u je potvrdila eksterna security firma, tako da se skine krivica sa programera...

Vidim neko pivo na moj račun... Samo da dodješ u BL...

Kad je beg bio cicija?
Nego, ćevapi sa pivom bi bili još bolji, a?


A sad ću ja da vam napišem nešto o sigurnosti baza podataka...

Kao prvo, najveću zaslugu za sigurnost neke baze podataka, u mom slučaju Oracle baze, imaju na prvom mjestu network administratori (tj. Cisco stručnjaci), koji su na prvoj liniji odbrane. Ako oni dobro podese access filtere, firewalle, proxye i druge "networkalije", onda je to veliko olakšanje drugoj (system administratori) i trećoj (database administratori) liniji odbrane.

Znači, database administrator može i da nešto previdi, zaboravi, iz neiskustva loše konfiguriše bazu i td., ali će se taj previd teže uočiti ukoliko network i system administratori svojim odličnim radom onemoguće neovlašten pristup bazi.

Oracle RDBMS je pun rupa i bugova, maltene bušan ko sir (karirikam), ali je te propuste teško iskoristiti, jer se moraju najprije proći prva i druga linija zaštite. Kad bi network i system administratori zakazali, te omogućili neovlašten pristup Oracle bazi, 50% Oracle administratora bi dobili otkaz...

Ne kažem ja da je tih 50% Oracle administratora nesposobno, jer oni nisu krivi za neki bug u Oracle bazi, zbog kojeg neki napadač ima neovlašten pristup bazi i mogućnost da nanese štetu...

I za kraj jedan savjet svim administratorima baza podataka - budite prijatelji sa svojim developerima, network i system administratorima, jer od njih zavisi i vaš posao.