Prepared statements sa ili bez htmlspecialchars

Pozdrav,
posto vecinu toga radim sa MySql-om i neko vreme mi nece trebaci kacenje na druge baze,umesto PDO sam se odlucio za prepared statements,i samo me jedna (bitna) sitnica buni....podatke izvlacim iz niza $_post,stavljam ih u odredjenu pomenljivu i posle bindujem,i sve ostalo sto treba radi ok,a mene zanima da li podatke iz niza $_post koje prebacim u promenljivu tipa $username=$_post[username] treba da provucem kroz funkciju htmlspecialchars pa onda da odradim bind i execute?
Podaci se unose iz forme,znaci korisnik ih unosi,podaci idu u bazu,pa se posle iz baze izlistavaju.
Pozz o//

Ne znam koje druge prepared statements koristis, ako ne od PDO-a, iako ih i on podrzava, ali je logika ista. Prvo se salje upit, pa pridruzeni podaci. Samo je pitanje sta zelis da imas u bazi. Moze slobodno bez htmlspecialchars.

Potpis

Pera električar 0637129710, BG, preporučujem.

htmlspecialchars() te čuva XSS napada, nebitno da li radiš sa pripremljenim upitima ili ne.

Kada ne radiš sa pripremljenim upitima, već sastavljaš direktno SQL upite opasnost je ne XSS već SQL ubrizgavanje. Za odbranu od SQL ubrizgavanja koristi se mysql_real_escape_string() ili kompatibilna funkcija. Ranije je savetovana upotreba addslashes() ali to nije dovoljno sigurno i podložno napadima sa neobičnim kodnim stranama.

XSS je rizik pri prikazu podataka koji nisu prošli kroz htmlspecialchars() ili kroz neko HTML čišćenje. Napadač može da unese javascript kod ili uključi resurse sa drugih stranica i izvrši napad na ostale korisnike kojima se strana sa podacima prikazuje.

Potpis

http://sr.libreoffice.org — slobodan kancelarijski paket, obrada teksta, tablice,
prezentacije, legalno bez troškova licenciranja

"htmlspecialchars() te čuva XSS napada, nebitno da li radiš sa pripremljenim upitima ili ne."

E ovo sam hteo da cujem:) to me je bunilo,posto do sad nisam obracao paznju mnogo na XSS i SWQ injections ali sad se poslovi namnozili,pa sam resio da uplovim u sigurnije vode da na miru spavam i onda sam resio da sve upite u kojima sam koristio mysql_real_escape_string() prilagodim prepared statementsima,mislim da sam zlonamerni kod skinuo sa strip_tags ali u nekim projektima koristim fck editor pa mi je potrebno da korisnici azuriraju bazu upravo sa tagovima.
Svaka cast na brzim i detlajnim odgovorima.
Pozdrav o//

p.s. onaj izraz (poslovi se namnozili ne znaci da sam neki klinac koji se pali vec cackam sve po malo i to se sad nagomilalo)

Ne razumem ovo. Ako ja pošaljem <b>Hello <h1>World</h1></b> htmlspecialchars() vraća &lt;b&gt;Hello &lt;h1&gt;World&lt;/h1&gt;&lt;/b&gt;. Na koji način ovo čuva tagove? Ako ih ti kasnije vraćaš nazad onda si podjednako ugrožen od XSS napada kao i da ništa ne radiš. XSS smeta pri finalnom prikazu, ni na koji način ne ugrožava bazu.

Razlika u odnosu na striptags() je što čuva HTML, na primer ako imaš neki webdev blog, onda želiš da zadržiš HTML u komentarima. Ako hoćeš da zadržiš HTML iz nekog editora moraš ili 1) da veruješ da korisnik neće zloupotrebiti XSS (na primer ako korisnik održava sopstvenu prezentaciju) ili 2) da koristiš HTML Purifier. Lista dozvoljenih tagova u striptags() nije dovoljno sigurna ako dozvoljavaš <a>, <img>,...

Sa XSS moraš biti oprezan pri ručnom sastavljanju HTML izlaza (umećeš delove koje je ostavio korisnik), kao što treba biti oprezan pri ručnom sastavljanju SQL izraza za odbranu od SQL ubrizgavanja. Dodatno stavi header('Content-Type: text/html; charset=UTF-8'); na početak svake strane, ako tvoj veb server već nije podešen da šalje UTF-8 kao kodnu stranicu u HTTP zaglavlju.

Potpis

http://sr.libreoffice.org — slobodan kancelarijski paket, obrada teksta, tablice,
prezentacije, legalno bez troškova licenciranja

U pravu si,hvala za detaljan opis,ovo ce mi biti od velike koristi u narednim projektima,a konkretno projekat gde koristim Fck editor radi nas dvoje od toga druga osoba ubacuje textove tako da sam siguran da nece da se igra sa zlonamernim kodom.
Komentare sam resio tako sto striptags() radi bez dozvoljenih tagova,a zanima me da li bi mogao da dozvolim neke,a posle da odradim jedan preg_replace() gde bih recimo stavio $nedozvoljene='/[@$%^*!\|;,~<>{}[\]()\-+]+|(?:SELECT|UPDATE|DELETE|INSERT|DROP|CONCAT)/i'; pa i onda uradio preg_replace($nedozvoljene," ", $ulaznipodaci). Da li je to ok resenje ili se moze efikasnije to odraditi?
P.S. ne trazim gotovo resenje vec samo upute gde da zavirim,procitam,naucim.
Hvalaaa :)
Pozdrav.

Ne! Ne! Ne! Ne!

Pokušavam već dva puta da ti kažem da postoje dva nezavisna problema.

Prvi je SQL ubrizgavanje. To rešavaš sa mysql_real_escape_string() ili pripremljenim upitima. Bilo gde gde sastavljaš SQL upit (na primer "SELECT ... FROM table WHERE".$where) moraš da budeš posebno oprezan i paziš kako $where izgleda i da ne umećeš slobodan unos korisnika u upit. Nikakav preg_replace, nedozvoljene reči i slično, to nije dovoljno.

Drugi je XSS napad. Problem je tu pri prikazu. Nema veze sa bazom, nije problem da kod koji sadrži XSS napad upišeš u bazu, problem je kada pročitaš i ispišeš drugom korisniku. Opet nedozvoljene reči i preg_replace rešenja nisu dovoljna. Ako ti tagovi ne trebaju, htmlspecialchars() ili strip_tags(). Ako ti tagovi trebaju, za sada je najbolje rešenje pomenuti HTML Purifier. To možeš da radiš pre upisa u bazu ili nakon čitanja prilikom ispisa, i jedno i drugo ima prednosti i mane. U svakom slučaju forisraj Content Type charset zaglavlje na UTF-8 ili šta već koristiš.

Potpis

http://sr.libreoffice.org — slobodan kancelarijski paket, obrada teksta, tablice,
prezentacije, legalno bez troškova licenciranja

Ukapirao,mislim da cu da ubacim u bazu sa tagovima pa cu onda da "cistim"pri ispisu na ekran, a UTF-8 forsiram svuda po defaultu tako da sa te strane ne bi trebalo da bude problema.Hvala puno.
Pozdrav :)

Posto je tema prebacena u deo za pocetnike, nadam se da se necete ljutiti ako vas upitam da postavite neki primer svega ovoga sto pricate. Recimo, glupo je sto u skoli (srednja ili fax, svejedno) nas nisu ucili nista o zastiti PHP stranica. Sve te 'cake' sam pohvatao na netu jer cak ni mnoge knjige nedovoljno posvecuju paznju recimo SQL "ubrizgavanju" a tek sada po prvi put cujem za XSS napad.
Bilo bi super kada bi dali primere loseg koda i primer zasto je taj kod los.

Ja sam pravio neke sajtice gde postoji logovanje korisnika sa raznim pravima, pa razne pretrage i slicni rizicni SQL upiti, i 'valjda' sam se zastitio ako sam svaki upit filtrirao sa mysql_real_escape_string() funkcijom, ali opet, mozda i nisam...
Zatim sam pravio sajt sa mogucnostima komentarisanja, tu je dvojaka zastita. Prva je logicka, znaci komentari se ne objavljuju momentalno vec admin mora da ih odobri (samo od odredjenih korisnika moze direktno ali njih je malo), a druga 'zastita' je sa preg_replace() funcijom koja ne dozvoljava pojedine kljucne reci u komentarima.

E sad, za ovo drugo sam naucio da nije dovoljna zastita ali do nedavno ni takvu vrstu zastite nisam stavljao tako da sam jos i dobar :)

Samo stavljaj zastitu gde god stignes,nikad ne znas ko ce doci na sajt i pozeleti da se zabavi.baci pogled na sledece linkove
Zastita 1
Zastita 2
i naravno stari dobri Essential PHP Security, by Chris Shiflett, izdavac O'Reilly, imas je ne netu pa pogledaj,mnogo je korisno.
pozdrav

Evo po 1000 put na ovom forumu:)
http://phpsec.org/projects/guide/sr/
Na srpskom je sve!