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