Impedire accesso al DB

[Ophy94]

Ciao a tutti vado subito al sodo...
Mi sapreste fare un'esempio di script che impedisce l'accesso al DB ovvero il mio libro mi fa un'esempio di una semplice script che tramite form viene inviata alla pagina stessa e tramite htmentities i caratteri tipo " o ' dvengono preceduti dal /' o /".
Le mie domande sono 2:
Mi sapreste fare voi un'esempio più pratico dato che quello del mio libro non fa precedere gli apostrofi con gli slash.
Poi è proprio indispensabile utilizzare solo questo metodo o c'è ne sono altri?

[Gab-81]

Originariamente inviato da Ophy94
Mi sapreste fare un'esempio di script che impedisce l'accesso al DB [...] tramite htmentities i caratteri tipo " o ' dvengono preceduti dal /' o /".

Ma parli di prevenire sql injection? Forse questo fa al caso tuo

[Ophy94]

Allora con le sql injection io mi difendo con i get_magic_quotes_gpc,mysql_real_escape_string,e stripslashes....Poi con il Cros site scripting mi difendo con htmentities(), o htmlspecialchars()...
Dici che è sufficente per proteggere un sito?

[oly1982]

Originariamente inviato da Ophy94
Dici che è sufficente per proteggere un sito?

dico che stai facendo un mega confusione!!!

Cercherò di spiegartelo semplice semplice...
Le QUERY che si rivolgono al database all'interno dei nostri script vengono spessissimo formulate in maniera dinamica cioè è l'utente che direttamente o indirettamente stabilisce la formulazione della query:
a.) perchè invia i valori tramite un form (con metodo get o post)
b.) perchè invia attraverso la query string (con metodo get)
c.) perchè ha dei cookie salvati sul suo pc

Essendo che questi possono essere "controllati" dall'utente occorre assicurarci che qualsiasi cosa l'utente inserisce nella query (in maniera più o meno maliziosa) questa non assumi significati diversi da quel che ci si voglia attendere. Se invece l'utente riesce a far modificare il "significato" della query allora sta realizzando quella che si chiama sql injection.

Cosa fare??

Occorre:
1) assicurarci che ciò che proviene dall'utente è ciò che ci si attende di ricevere. A questo scopo ci sono vari metodi: validazione degli input tramite espressioni regolari e/o con apposite funzioni di php (isset, empty, is_int, is_numeric, etc etc.);
2) Immunizzare tutto ciò che proviene dal form con opportune funzioni. Quest'ultimo aspetto è quello che maggiormente è importante per difendersi dalle sql injection.

Spesso da un utente si ricevono (con metodo get, post, cookie) stringhe. queste possono contenere caratteri (', ", %, etc etc) e/o parole (NULL, DROP, etc etc) "pericolose".
Per evitare questi pericoli occorre filtrare opportunamente le stringhe provenienti dall'utente; questo genere di filtro viene detto ESCAPE. Come farlo?

Esistono due funzioni e una impostazione del php.ini

get_magic_quotes_gpc() è un'impostazione del php.ini che precede i simboli ' e " con un backslash alle variabili di tipo GET, POST COOKIE (da qui la sigla 'gpc');
addslashes() è una funzione di php che effettua l'escape delle stringhe;
mysql_real_escape_string() è una funzione che come addslashes effettual l'escape delle stringhe ma è maggiormente consigliata dato che è stata creata appositamente per lo scopo.

Quindi le stringhe in ingresso devono essere filtrate tenendo conto di quanto detto. Allo scopo ti riporto una stra-mega-famosa-funzione per effettuare l'escape delle stringhe tenendo conto di quanto detto

<?php
function EscapeString($string)
{
    //se è attiva get_magic_quotes_gpc
    if(get_magic_quotes_gpc())
    {
        // rimuoviamo gli slash inseriti automaticamente
        $string = stripslashes($string);
        // e diamo come result la stringa filtrata con opportuna funzione
        return mysql_real_escape_string($string);
    }
    //se non è attiva get_magic_quotes_gpc
    else
    {
        // diamo come result la stringa filtrata con opportuna funzione
        return mysql_real_escape_string($string);
    }
}
 
?>

L'ho fatta molto breve... ma + o -
Per approfondire
http://www.mtxweb.ch/php_learn/?p=864
http://www.phpnews.it/corsi/corso-ph...ento-dei-dati/

[Ophy94]

Oly non credo che faccio confusione dato che le cose che mi hai scritto io le sapevo già, la fiducia nei dati degli utenti, e il loro controllo....Volevo solo sapere se con tutte queste stringhe alla fine un sito diventa abbastanza sicuro....

[Gab-81]

Originariamente inviato da Ophy94
Volevo solo sapere se con tutte queste stringhe alla fine un sito diventa abbastanza sicuro....

Diciamo che sono molte le cose che concorrono alla sicurezza di un sito (o di un'applicazione in generale) sicuramente è buona norma usare anche gli accorgimenti che ben conosci...tenendo sempre a mente che non si è mai completamente al sicuro...

[Ophy94]

Gab-81 sisi sono pienamente d'accordo che un sito non è mai al 100% sicuro, ma renderlo il più possibile sicuro si può.....

[DKiller92]

Quanto detto per le SQL Injection va bene, ma ti consiglio di fare anche un controllo con le regex sugli input, per controllare la presenza di "codice maligno" tipo UNION SELECT ecc...

Per le XSS va benissimo l'htmlentities(), che è meglio dell'htmlspecialchars()...

Per il resto cerca di salvare le password nei database trasformandole prima, tipo

sha1(md5($password)); 

infine se usi un sistema di utenza, usa le sessioni che sono più sicure dei cookie

[Ophy94]

Grazie Dkiller92 anche se criptavo già come ulteriore sistema di sicurezza le password o dati sensibili, nonostante ciò ti ringrazio anche per il tuo consiglio sulle sessioni...