Što se tiče SQL injection-a, korišćenje prepared statement-a je najbolji, pravi vid zaštite i to je jedino što treba koristiti za odbranu od te vrste napada, tačka. SQL injection apsolutno nije moguće ako se koriste prepared statement-i. Naravno, ako se koriste na pogrešan način, tj ako developer sam, ručno "lepi" parametre u query string, i takvog ga šalje na pripremu, umesto da ih bind-uje u prethodno postavljene placeholder-e u upitu, napradi su i te kako mogući.
Sa XSS-om je stvar drugačije prirode, jer taj vid bezbednosnog propusta ne može da naškodi tvojoj aplikaciji, koliko recimo posetiocu tvog sajta. Tipa imaš neki commenting sistem, zlonameran korisnik pošalje neki HTML u poruci, ti to ne filtriraš pri submit-u, a ni ne escape-uješ pri ispisu, a onda dođe korisnik na tvoj sajt, koji je prethodno bio na nekog drugom sajtu i pritom ostao ulogovan na njemu. I sad, au tom HTML-u, zlonamerni korisnik je mogao da ubaci sliku, tj <img> tag, čiji src atribut puca na akciju za brisanje naloga na tom nekom drugom sajtu, na kojem nesrećni korisnik ima nalog.
I po učitavanju tvoje stranice, nakon što se "učita" slika, korisnik ostaje bez naloga na svom sajtu.
Tu se naravno vidi da i taj drugi sajt ima problem, jer samim tim što je tako neki request prošao, znači da je on podložan CSRF napadima.
Što se tiče prevencije XSS napada, već sam pomenuo filtriranje i/ili escape-ovanje. Kažem i/ili iz razloga što može biti dovoljno jedno ili drugo. Konkretno u tom primeru, ako odlučiš da strip-ujes sav HTML iz komentara u principu ne moraš da ga escape-uješ pri ispisu. A ako ga ne izbaciš, ali escape-uješ komentar, opet si rešio problem, jer HTML neće biti renderovan, već ispisan kao escape-ovan tekst.
A kad smo kod CSRF napada, najefikasniji vid zaštite jeste u vidu tokena u formama, prethodno generisan na server strani, upisan u sesiju, a zatim ispisan u vidu skrivenog polja u formi. Validacija te forme onda između ostalog uključuje i upoređivanje poslatog tokena iz hidden polja sa onim zapamćenim u sesiji. Tako da, ako neko pokuša spolja, nekom skriptom, da uradi submit te neke forme na tvom sajtu, neće moći, jer mora da pogodi taj token generisan i upisan u sesiju. Imajući to u vidu, jasno ti je zašto onaj gore primer ne bi prošao, da je taj drugi sajt imao CSRF zaštitu, jer u tom src-u slike, zlonamerni korisnik bi morao da nagađa i šalje i taj token kao parametar.
Zaštitia "starijih" aplikacija
