Comments for post PHP: Come difendersi dal problema dell'SQL Injection

magomerlino writes: Ciao a tutti, per difendersi da sql injection non basta sanizzare l'entrata, purtroppo bisogna fare la validazione completa :-( Cetamente sanizzare l'input ti compre dal 70 o 80% degli attacchi ed attaccanti ma .... Como fare una validazione degli input ed output? Allora pima bisgna fare una caninicalizzazione (convertire l'input in una forma stadard che non possa essere alterata, es: utf-8), pi viene la sanizzazzione per i caratteri pericolosi che dobbiamo permettere come input (es: se en un messagio dobbiamo permettere ' e quindi lo sanizzaimo per esempio con funzioni come mysql_real_escape) ed infine viene la vera validazione, permettere solo cio che e permesso come entrata: controllare che l'input rispetta rango di caratteri o numeri, formato, dimensione (es: se e un numeor di telefono si controlla la lunghezza, che contenga solo numeri [0-9] e che abbia il formato corretto); questo si puo fare con espressioni regolari. Se inoltre volete fare dei test de intrusione potete scegliere diverse soluzioni presenti nel mercato, dalle free (sql me,...) alle commerciali. Vi consiglio guardare www.security-guardian.com sono dei fuori classe. attualemnte il servizio e gratis. Fanno dei test online della web e nell'area di amministrazione ti mostrano i risultati con le soluzioni che bisogna implementare per risolvere le vulnerabilita detettate. Saluti
Navigatore Anonimo writes: "Di norma PHP forza il programmatore a fare l'escape manuale dei parametri delle query SQL. Cio' e' chiaramente disumano." non è vero... "la sicurezza non puo' essere affidata alla capacita' di non dimenticare mai un escape" significa che l'approccio iniziale è già sbagliato... abbastanza banale.. bastava dire che in assenza di magic_quotes bisogna escapare tutte le stringhe in inserimento. Ciò è anche obbligatorio per legge adottare un framework serio ovvia tutti questi problemi.
Marco Grazia writes: Antirez cosa ne pensi del modo di interfacciarsi ai database proposto dalla libreria PDO in PHP?
ruto writes: ottima funzione...anche se poi a parere mio ti impone di scrivere le query in un certo modo...sarebbe bello scrivere una query normale senza stare attento a metter " etc... cmq il io giudizio e' positivo..complimenti!
' writes: '
<?php $query = "SELECT * FROM users WHERE user='".$_POST['user']."' AND pwd='".$_POST['pwd']."'"; $sql = mysql_query($query); if(mysql_affected_rows($sql)>0) { } ?> writes:
ThRiX writes: Ciao a tutti! sto cercando una soluzione VALIDA! per evitare problemi (vedi sql injection appunto) sul mio gestionale. Ho notato che nella descrizione della funzione, non viene descritto il suo utilizzo con il comando UPDATE. Ho provato ad adattarla in qualche modo senza esiti positivi! Ciao a tutti...
antirez writes: @Fra_T: cool :)
Fra_T writes: Ho iniziato ad usare questa funzione e in effetti la trovo molto comoda :D
antirez writes: @Fra_T: esatto, bisogna usare la virgola. Non c'e' modo per evitare l'interpolazione se l'utente la usa esplicitamente, la cosa buona e' che pero' quando questo serve (ad esempio se una parte dell'SQL e' prodotto da una funzione diversa) e' possibile evitare il quoting automatico. Ormai usiamo queste funzioni da alcuni mesi, l'utilizzo della virgola dopo un po' diventa cosi' automatico che e' molto difficile sbagliare.
Fra_T writes: Interessanti queste funzioni, solo che se anziché scrivere: mysqlCreateQuery("SELECT * FROM rubrica WHERE name=",$name); Scriviamo: mysqlCreateQuery("SELECT * FROM rubrica WHERE name=$name"); $name salta mysql_escape_string. O sbaglio?
www.dario-avellino.it writes: Ciao ho fatto la tesina su questo argomento! A presto.
emix writes: Ottima scelta quella di Ruby! Lo uso già da un po' e da qualche settimana sto giochicchiando con Rails. Il framework è spettacolare, ma in effetti la sensazione che si ha è quella di essere un po' troppo abbottonati.
antirez writes: Ciao Emix, Segnalo e Oknotizie sono stati fatti esplicitamente perche' pensavamo che sarebbero diventati oggetto di un accordo con qualche grosso operatore del settore. In tale ottica ci sembrava che la buzzword PHP potesse fungere da lascia passare, in maniera simile a Java, ma tra i due preferivamo di gran lunga PHP. Non sapevamo ancora con chi avremmo fatto l'accordo e in quali termini, ma utilizzare un linguaggio non "mainstream" avrebbe potuto far temere al nostro partner un effetto lock-in perche' loro in caso di cessione dei sorgenti potrebbero non aver avuto le competenze interne per scrivere codice in tali linguaggi (in particolare Tcl, che era quello che desideravo usare io). Per i prossimi progetti di Merzia ci sposteremo con buona probabilita' verso Ruby. E' un ordine di grandezza migliore di PHP e ormai e' abbastanza conosciuto e causa minore preoccupazione di Tcl :) In ogni caso per i nuovi progetti il problema e' meno severo perche' una partnership non e' piu' il nostro obiettivo principale, ma il supporto in termini di librerie e comunita' rimane importante dunque Ruby potrebbe essere il candidato ideale. Difficilmente pero' useremo Rails, perche' nella nostra filosofia di sviluppo i framework sono considerati come portatori di problemi piu' che un vantaggio.
emix writes: Domanda: perché hai usato PHP per questi due progetti?
home