Si può sfruttare una sql injection se al parametro vengono eliminate le slashes?

[zacca94]

Ho letto in qualche manuale che addslahses NON è sicuro: perchè?
Premetto che faccio questa domanda in quanto effettuo già una specie di htmlspecialchars con questa funzione:

function my_htmlspecialchars( $html )
{
    $text = array ( "<" , ">" , "\"" , "'" );
    $replace = array ( "<" , ">" , """ , "'" );
    return str_replace( $text , $replace , $html );
} 

E dato che utilizzo sprintf/vsprintf per le query, utilizzare anche mysql_real_escape_string renderebbe le query a dir poco lunghissime.

In parole povere: basta che utilizzo my_htmlspecialchars ( che definisco comunque dato che estraggo tutte le informazioni come il referer, user agent etc... all'inizio dello script ) per prevenire attacchi di tipo sql injection o devo per forza utilizzare ANCHE mysql_real_escape_string?

grazie.

[k.b]

http://shiflett.org/blog/2006/jan/ad...-escape-string

Miglior difesa contro SQL injections: fare le query con prepared statements

[zacca94]

risposta al mio primo quesito...
anche se provando in locale a me lo slashes veniva aggiunto sia con addslashes che con mysql_real_escape_string. ( parlando di PHP 5.3.0 e creando la tabella con i caratteri gbk )

Poi comunque non comprendo come possa funzionare in quanto la funzione chr() anche se passata via GET o POST verrà letta semplicemente come carattere e non come funzione PHP...

[ aggiunto successivamente ]
e lo stesso vale per la funzione chr() di mysql infatti essa verebbe letta solamente DOPO che è stato chiuso la parte cone username = ' ... fare ciò che fa quello che ha scritto quell'articolo sarebbe : username='chr(0xbf)chr(0x27)' ovvero INUTILE in quanto il tutto è letto come CARATTERE e non come funzione...
[ / aggiunto successivamente ]

secondo me chi ha scritto quell'articolo vaneggia di brutto... ( poi posso pure sbagliarmi in quanto non sono un esperto in sicurezza )
poi non mi dilungo neppure tanto perchè non mi interessa più di tanto.

Ritornando a me, e per farla breve, in quanto NON utilizzo il set di caratteri gbk, e nel mio file php.ini c'è piazzato un bel: default_charset = "iso-8859-1", mi basta utilizzare la mia funzione my_htmlspecialchars?

[daniele_dll]

allora, per star tranquilli con le sql injection, indipendentemente dalla codifica, è necessario:
- verificare se il magic_quotes_gpc è attivo ed eventualmente disabilitarlo tramite htaccess
- se non è possibile disabilitare l'htaccess effettuare uno stripslashes dei parametri GET/POST/FILES in ingresso

Dopo di che scrivere una funzione/metodo che prenda la query più N parametri, acquisendo i parametri aggiuntivi tramite func_get_args rimuovendo però il primo elemento, che cicli l'array passandoci su il mysql_real_escape_string ed infine che lanci la query utilizzando vsprintf.

Usando questo sistema siete abbastanza al sicuro dalle sql injection perché qualunque parametro passate alla query viene sistemato senza dovrescrivere altro codice. Ovviamente è opportuno scrivere una funzione di escape che richiami il mysql_real_escape_string da usare quando non si possono usare i singoli parametri (che so, si sta costruendo una clausola where con IN ad esempio o si sta costruendo una join multipla)

Usare vsprintf permette anche di aggiungere ulteriori controlli perché è possibile formattare gli argomenti o forzarne il tipo (ad es se mi serve inserire una valuta in un campo posso usare %.02f, o se ho bisogno di aggiungere gli zeri davanti ad un valore interno posso usare %010d ... o se ho bisogno di inserire i parametri nella query che sono però posizionati con altro ordine ... %2$010d .... %1$.02f ... insomma c'è ne per tutti i gusti)

l'unica nota dolente è che vi dovete ricordare di raddoppiare i % quando li inserite altrimenti succede un gran casino

Riagganciandoci a prima, è importante che quest'operazione, ovvero la sostituzione di % con %% la effettui la funzione di escape senno il codice rischia di diventare vulnerabile (anche se poco) ma ancora di più di far dare errore che è fastidioso!