Newsgroup: it.comp.www.php
Titolo: PDO MySQL & SQL Injection

Non ho mai usato PDO, ma volevo fare alcune prove.
Ho visto che per fare una query bisogna usare dei
prepared statement e bindare le variabili a dei placeholder.
Esempio:
$pdo = $dbh->prepare("insert into test set nome = :nome");
$pdo->bindParam(':nome', $nome, PDO_PARAM_STR, 64);
$nome = 'Pippo';
$pdo->execute();
Cosï¿œ facendo, forzo la variabile nome ad essere una stringa lunga
massimo 64 caratteri.
Dovrebbe proteggermi da varie sql injection e atti poco carini, giusto?
Non devo far altro?
Ho poi letto in giro che si puï¿œ fare anche qualcosa di simile:
$pdo->prepare('insert into test set name = %64s)
     ->execute('pippo');
che dovrebbe fare la stessa cosa ma con una sintassi notevolmente
piï¿œ breve. Nel primo caso, infatti, se avessi 12 parametri da inserire
avrei anche 12 righe di binding piï¿œ 2 righe tra connessione ed execute.
Nel secondo caso invece avrei una sola riga che fa tutto.
Ma entrambe le modalitï¿œ proteggono da sql injection in egual maniera
oppure oltre alle precauzioni di cui sopra bisogna considerare altri
fattori?
Ad esempio, potrei passare tranquillamente come parametro $_GET['nome']
senza rischio che mi venga distrutta la query? (ho volutamente
tralasciato tutti gli altri problemi derivanti dall'utilizzo diretto
di variabili senza la "risanatura". Voglio parlare solo di sql injection)

 di variabili senza la "risanatura". Voglio parlare solo di sql injection)
Attento che alcune funzionalità del bindParam di pdo non sono del
tutto chiare:
http://stackoverflow.com/questions/833510/php-pdobindparam-data-types-how-does-it-work

 
http://stackoverflow.com/questions/833510/php-pdobindparam-data-types-how-does-it-work
Quindi il modo migliore per proteggersi da sql injection?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito � di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 sradicando il male dai campi che conosciamo.
cerca su google 'php sanitize data', trovi migliaia di esempi.
Bind params è di certo una cosa in più, il mio intervento di prima era
per dire che non puoi contare SOLO su di lui e dormire tranquillo ;)

 per dire che non puoi contare SOLO su di lui e dormire tranquillo ;)
Nel mio messaggio per� avevo scritto di aver volutamente omesso tutti
gli altri problemi del caso. So che devo sanitizzare i dati, ma un
banale
' OR 1==1 --
il bindParam lo risolverebbe gi� di suo?
In pratica, tralasciando tutti i rischi derivanti dall'utilizzo diretto
delle variabili GET,POST,REQUEST o di qualunque altra variabile in
cui l'utente possa metter becco, i prepared statement di cui sopra, mi
tutelano dai banali sql injection di cui sopra?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito � di fare il possibile per la


 sradicando il male dai campi che conosciamo.
In teoria si, nel senso che in teoria basta che la query sia fatta
tramite prepared_statement e dovresti essere tranquillo, ma sempre in
teoria.
In pratica, ti consiglio di testare, sempre, prima di mandare del
codice in produzione.
qui trovi alcune risorse utili:
Sql Injection Cheatsheet
http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/
(e già che siamo in tema)
Xss Cheat Sheet
http://ha.ckers.org/xss.html