SQL Injection : mysql_real_escape_string basta?

[markzzz]

salve, ho da poco appreso di questi possibili attacchi, così ho applicato (prima di ogni query da inviare) il mio bel mysql_real_escape_string($string);

ora leggendo in internet però, molti parlano di essere ancora più paranoici, creare delle ban-word-list, gestire l'input in altri modi (esempio se ci si aspetta caratteri, verificare che siano solo caratteri, etc etc). quello che mi chiedo è? ma allora mysql_real_escape_string non è la soluzione effettiva alle SQL Injection, o si?

se qualcuno riesce a farmi un esempio di dove quella funzione potrebbe fallire sarebbe ottimo

saluti

[Samleo]

E' già buona cosa, ma non basta!

Per esempio, se non sono contenuti html (tipo input con editor) potresti mettere un per htmlentities();

[markzzz]

ciao, e grazie della risposta. non ti seguo : in che senso "non sono contenuti html" ? se io ho la mia pagina php e quella funzione, non capisco come possa essere possibile un'ulteriore infiltrazione. non stò dicendo che non sia possibile, stò dicendo che "vorrei capire" in che altro modo dovrei difendermi...

[bubi1]

gia', sarei curioso anche io di sapere perche' convertire inutilmente i caratteri in entita' html sui dati su cui e' gia' stato fatto l'escape

[Samleo]

Perchè, per assurdo, sarebbe possibile mettere anche una bel xss...oltre all'injection!

[markzzz]

bhè, ma per quanto ne sò (magari poco, sicuramente poco ) SQL injection và vista come "falla in entrata" sul database! XSS và gestita al momento della visualizzazione (nel senso, se il contenuto che stampo a video è dentro per esempio a funzioni come "htmlspecialchars", sul database ci può anche essere del JS malefico; verrà cmq visto come del semplice testo. ovviamente và applicato ai vari form/querystring, non solo al database).

non credo (forse si?) che con XSS si possa andare a influire nelle operazioni di UPDATE/SELECT/DELETE di un database (ovviamente filtrato con mysql_real_escape_string), o sbaglio?

[Samleo]

Ovviamente no, ma siccome si sta parlando in maniera generica di proteggere un form..è ovvio che lo proteggi sia in entrata che in uscita no?

[markzzz]

sisi, indubbiamente. però io per esempio preferisco avere una funzione (all'inizio di tutto) che mi filtra i vettori get/post tramite htmlentities(), così da annullare eventuali XSS (così dovrei essere al sicuro, no? ), permettendo comunque di scrivere tali attacchi sul DB (in modo da rendermi conto se effettivamente qualcuno stà facendo qualcosa che non dovrebbe ).

ovviamente è un sito in cui riesco a rendermi conto di queste cose, fosse un sito da milioni di utenti forse sarebbe bene impedire fin dal principio tutto ciò

resta il fatto che non ho ancora capito l'importanza di quelle valutazioni sulle stringhe (es. se mi aspetto caratteri, verificare che siano caratteri). questo controllo per me và fatto per rispettare la "coerenza" sui dati che mi aspetto; non capisco cosa centri con la sicurezza...

[Samleo]

Come hai ben detto, si tratta appunto di una questione di coerenza!

Se per caso stai controllando un campo id è conveniente che sia int

Se stai controllando un'indirizzo email, è conveniente che sia nel formato: testo@test.testo(2)

Ecc ecc...

In termini di sicurezza, diciamo che limita in qualche modo il range di possibili "campi" da testare!

[markzzz]

chiaro

un ultima cosa che non ho mai capito : con htmlentities() posso stare al sicuro anche con eventuali stringhe in GET e POST codificate? non ho mai capito se "entetizza" anche il %...