Programmazione sicura in PHP Fabio Fabbri
Introduzione Internet è una zona di guerra La sicurezza assoluta non esiste La sicurezza non va trascurata durante lo sviluppo
SQL INJECTION http://xkcd.com/327
SQL INJECTION “INSERT INTO Students(firstname) VALUES('$firstname');” “INSERT INTO Students(firstname) VALUES('Robert'); DROP TABLE Students; --');” I target erano principalmente le scuole $firstname = mysqli_real_string_escape($firstname) Con PDO meglio usare i metodi prepare() e execute() Se si deve impostare il charset, va fatto prima con mysqli_set_charset() o in PDO con il parametro charset del DSN (Database Source Name) durante l’inizializzazione
SQL INJECTION “SELECT … WHERE num = {$_GET[‘numero’]}” $numero = (int) $_GET[‘numero’]
SQL INJECTION “SELECT … ORDER BY {$_GET[‘colonna’]}” in_array($_GET[‘colonna’], array(‘nomi’, ‘delle’, ‘colonne’, ‘valide’))
XSS (cross-site scripting) <html>...<body>… Hai cercato <?php echo $_GET[‘s’]; ?> Se induco un utente del sito a visitare il link page.php?s=<script type=”text/javascript” src=”http://example.com/exploit.js”></script> posso ottenere i dati di accesso e/o informazioni personali e/o alterare la pagina Se riesco a salvare questo codice (ad esempio in un commento o in un log) e questo viene visualizzato senza filtri, l’exploit diventa “permanente” Se un utente con privilegi di amministrazione visualizza la pagina buggata, posso compromettere il sito Bisogna effettuare un escape dei caratteri speciali di HTML con htmlspecialchars($testo, ENT_QUOTES) o filtrare il codice html con una libreria apposita (come HTML Purifier) strip_tags() non è sicuro perché non impedisce l’inclusione di javascript negli attributi dei tag in whitelist Questo va fatto anche per il contenuto salvato ogni volta che viene incluso nell’html
javascript injection <script type=”text/javascript”> var a = “<?php echo $testo; ?>” Se $testo contiene le doppie virgolette si può iniettare codice javascript Se $testo contiene </script> può iniettare html e altro javascript $testo = json_encode($testo, JSON_HEX_TAG | JSON_HEX_APOS | JSON_HEX_AMP | JSON_HEX_QUOT); Funzione sicura da PHP 5.3 in poi
Header injection header('Location: '.$_GET['url']); page.php?url=%0DSet-Cookie:+NAME=foo Se si includono nell'header HTTP dei valori, controllare che non contengano mandate a capo strtr($stringa, array('\n' => '', '\r' => ''); Meglio fare anche dei controlli con espressioni regolari che il formato dell'input sia quello atteso
Email injection Mail('webmaster@example.com',$_POST['subject'],$_ POST['message'],”From: {$_POST['from']}”); From: sender@anonymous.example Cc: recipient@example.com Bcc: a@example.com,b@example.com... Usare librerie come phpmailer Evitare di lasciare che l’utente cambi il From
Inclusione file <?php include($_GET['pagina']) ?> pagina=../../../etc/passwd Whitelist dei valori validi di pagina Mappa per far corrispondere un valore alla pagina da includere array(1=>'a.php',2=>'b.php' ...
Salvataggio Password utenti Mettere in conto che qualcuno potrebbe riuscire a fare un dump del database degli utenti con tutte le password Mai salvare le password in chiaro! Un semplice hash non è sufficiente: esistono delle rainbow table Generare $salt random per ogni utente e salvarlo, $hash = hash($salt . $password) Controllare che gli hash siano uguali con === per evitare il caso particolare dell'hash in formato 0e123456789 Per essere sicuri di far per bene, da PHP 5.5 si può usare password_hash() e password_verify()
Cross Site Request Forgery (XSRF) <img src=”http://bank.example/index.php?action=transfer&to=e ve-account&value=1000” /> Chi è loggato sul sito della banca potrebbe eseguire un trasferimento di denaro ogni volta che visualizza la pagina Evitare di eseguire azioni con richieste di tipo GET, usare POST Non è sufficiente per proteggersi da XSRF visto che una richiesta POST può essere iniziata da un altro sito via JavaScript Controllare il referrer dell’azione Chiedere conferma prima di eseguire un’azione Aggiungere tra i campi nascosti del form un nonce (number once) diverso per ogni utente e di durata limitata Affidarsi alle librerie del CMS/Framework per creare form sicuri Lato utente, visitare i siti critici come l’Home Banking con un altro browser o “in incognito”, visitando solo quel sito e uscendo al termine
Regole d’oro Non fidarsi mai dell’input degli utenti e dei dati salvati Trattare i dati “con i guanti”, come se fosse “biohazard” ☣ Pensare a cosa succede quando i dati sono diversi da quelli attesi Sanitizzare adeguatamente i contenuti prima di includerli in un qualche linguaggio
Altri consigli Evitare opzioni insicure delle vecchie versioni di PHP Register Globals Magic Quotes Safe Mode Non mettere in output errori e warning del PHP, ma registrare tutto su un file di log Usare un database e un utente ad hoc per la web application Su hosting condiviso, eseguire php con l’utente ad hoc per il sito La validazione lato client può essere aggirata facilmente, può essere usata come “cortesia” all’utente ma non sostituisce la validazione lato server Conservare l’indirizzo email originale dell’utente