La sicurezza è un concetto interessante e attrae molte persone. Purtroppo è un argomento complesso e anche i professionisti si sbagliano. Ho trovato falle di sicurezza in Google (CSRF), Facebook (più CSRF), diversi importanti rivenditori online (principalmente SQL injection / XSS), nonché migliaia di siti più piccoli sia aziendali che personali.
Questi sono i miei consigli:
1) Utilizza query parametrizzate
Le query parametrizzate forzano i valori passati alla query a essere trattati come dati separati, in modo che i valori di input non possano essere analizzati come codice SQL dal DBMS. Molte persone ti consiglieranno di eseguire l'escape delle tue stringhe usando mysql_real_escape_string() , ma contrariamente alla credenza popolare non una soluzione universale per SQL injection. Prendi ad esempio questa query:
SELECT * FROM users WHERE userID = $_GET['userid']
Se $_GET['userid'] è impostato su 1 OR 1=1 , non ci sono caratteri speciali e non verrà filtrato. Ciò comporta la restituzione di tutte le righe. O, peggio ancora, cosa succede se è impostato su 1 OR is_admin = 1 ?
Le query parametrizzate impediscono che si verifichi questo tipo di iniezione.
2) Convalida i tuoi input
Le query parametrizzate sono ottime, ma a volte valori imprevisti potrebbero causare problemi con il codice. Assicurati di convalidare che siano entro il raggio d'azione e che non consentiranno all'utente corrente di modificare qualcosa che non dovrebbero essere in grado di fare.
Ad esempio, potresti avere un modulo di modifica della password che invia una richiesta POST a uno script che cambia la password. Se inserisci il loro ID utente come variabile nascosta nel modulo, potrebbero cambiarlo. Invio di id=123 invece di id=321 potrebbe significare che cambiano la password di qualcun altro. Assicurati che TUTTO sia validato correttamente, in termini di tipo, portata e accesso.
3) Usa htmlspecialchars per sfuggire all'input utente visualizzato
Supponiamo che il tuo utente inserisca il suo "su di me" in questo modo:</div><script>document.alert('hello!');</script><div>
Il problema è che l'output conterrà il markup inserito dall'utente. Cercare di filtrarlo da soli con le liste nere è solo una cattiva idea. Usa htmlspecialchars per filtrare le stringhe in modo che i tag HTML vengano convertiti in entità HTML.
4) Non utilizzare $_REQUEST
Gli attacchi CSRF (cross-site request forgery) funzionano facendo in modo che l'utente faccia clic su un collegamento o visiti un URL che rappresenta uno script che esegue un'azione su un sito per il quale ha effettuato l'accesso. Il $_REQUEST variabile è una combinazione di $_GET , $_POST e $_COOKIE , il che significa che non puoi distinguere tra una variabile che è stata inviata in una richiesta POST (cioè tramite un input tag nel tuo modulo) o una variabile che è stata impostata nel tuo URL come parte di un GET (ad es. page.php?id=1 ).
Diciamo che l'utente vuole inviare un messaggio privato a qualcuno. Potrebbero inviare una richiesta POST a sendmessage.php , con to , subject e message come parametri. Ora immaginiamo che qualcuno invii invece una richiesta GET:
sendmessage.php?to=someone&subject=SPAM&message=VIAGRA!
Se stai usando $_POST , non vedrai nessuno di questi parametri, poiché sono impostati in $_GET invece. Il tuo codice non vedrà il $_POST['to'] o una qualsiasi delle altre variabili, quindi non invierà il messaggio. Tuttavia, se stai usando $_REQUEST , il $_GET e $_POST rimangono bloccati insieme, quindi un utente malintenzionato può impostare quei parametri come parte dell'URL. Quando l'utente visita quell'URL, invia inavvertitamente il messaggio. La parte veramente preoccupante è che l'utente non deve fare nulla. Se l'autore dell'attacco crea una pagina dannosa, potrebbe contenere un iframe che punta all'URL. Esempio:
<iframe src="http://yoursite.com/sendmessage.php?to=someone&subject=SPAM&message=VIAGRA!">
</iframe>
Ciò fa sì che l'utente invii messaggi alle persone senza mai rendersi conto di aver fatto qualcosa. Per questo motivo dovresti evitare $_REQUEST e usa $_POST e $_GET invece.
5) Tratta tutto ciò che ti viene dato come sospetto (o addirittura dannoso)
Non hai idea di cosa ti stia inviando l'utente. Potrebbe essere legittimo. Potrebbe essere un attacco. Non fidarti mai di ciò che un utente ti ha inviato. Converti in tipi corretti, convalida gli input, usa le whitelist per filtrare dove necessario (evita le blacklist). Ciò include qualsiasi cosa inviata tramite $_GET , $_POST , $_COOKIE e $_FILES .
Se segui queste linee guida, sei in una posizione ragionevole in termini di sicurezza.
