analisi e gestione della sicurezza di una complessa applicazione ...

More documents

Recommendations

Info

6.3 Broken Access Control CAPITOLO VI - Gli attacchi e il progetto OWASP All’interno di applicazioni web multiutente, come lo è Talete, sono spesso presenti dei meccanismi di autorizzazione denominati controlli d’accesso. La corretta implementazione consente di associare ad ogni tipologia d’utenza un corrispettivo gruppo di appartenenza con ruoli, credenziali e privilegi diversi. La gestione delle autorizzazioni deve iniziare dalla formalizzazione di alcune policy che regolano che cosa è lecito per ogni diversa classe d’utenza; già durante la fase di design è importante considerare attentamente ogni singolo aspetto. Nella fase successiva, quella dell’implementazione, è bene evitare alcuni classici errori: • Parametri non controllati: le applicazioni usano le informazioni presenti nella richiesta HTTP per decidere come rispondere. Un attacco potrebbe avvenire modificando una qualsiasi parte della richiesta HTTP, l’url, la querystring, gli headers, i cookies o i campi dei form. Per ovviare a questo tipo di attacchi è importante filtrare i dati in arrivo, ci sono tre politiche principali per il filtraggio: 1. Accettare solo dati validi 2. Rifiutare dati non validi 3. Sanare i dati in arrivo La prima opzione è la più sicura, imposizioni di lunghezza e formato limitano molto le possibili manomissioni, al contrario un filtro che elimina alcuni caratteri speciali potrebbe essere facilmente oltrepassato con una qualche codifica. Un altro importante regola è quella di non fidarsi mai di un controllo di validità lato client, questi controlli sono utili da punto di vista delle performances e dell’usabilità, ma sono molto semplici da evitare. • File permission: molti server web utilizzano sistemi di controllo d’accesso forniti dal file system della piattaforma in uso. Anche se tutti i dati vengono conservati su server posizionati nel backend, ci sono sempre dei file conservati localmente sui web e application server che non devono essere accessibili da tutti (file di configurazione, file 128
CAPITOLO VI - Gli attacchi e il progetto OWASP default e script). Solamente i file che devono essere visualizzati dagli utenti via web devono essere marcati come leggibili usando il sistema di gestione dei permessi del sistema operativo (la maggior parte delle directory deve essere nascosta e pochissimi file, se non nessuno, deve essere marcato come eseguibile). • Forced browsing per superare una restrizione d’accesso: molte applicazioni, tra cui Talete, prevedono dei controlli prima di accedere ad un indirizzo profondamente nidificato all’interno del sito. È necessario evitare che un utente possa saltare tali controlli forzando la navigazione (es: non fidarsi della variabile HTTP_REFERER). • Insecure ID: non bisogna affidarsi alla segretezza degli ID usati comunemente per distinguere gli utenti, i gruppi di appartenenza e quindi i relativi privilegi. Se un aggressore riuscisse a leggere tali valori e capire la logica dell’assegnazione (es: il valore "0" per l’utente root) potrebbe generare delle richieste HTTP modificate, scardinando il meccanismo di controllo implementato. Fondamentale in Talete è il parametro ID presente nelle query; in pratica se fosse l’unico parametro presente, chiunque potrebbe provare ad indovinare quell’id scrivendone uno a caso. In questo modo, se l’id fosse presente, sarebbero visualizzati dei dati che non dovrebbero essere mostrati. Per questo, nelle query di Talete, è stato inserito un altro parametro, che è l’id dell’organizzazione, in modo tale che, se l’id tirato a caso dall’utente di quella stessa organizzazione è giusto, i dati vengono mostrati (ma comunque è un utente appartenente a quell’organizzazione), altrimenti la query non restituisce alcun risultato perché non viene specificato l’esatto parametro relativo all’id dell’organizzazione. • Client Side Caching: le pagine salvate in cache dai moderni browser sono un pericolo costante per la riservatezza dei dati di quelle persone che navigano attraverso postazioni pubbliche (scuole, internet point, etc.). Si dovrebbe adottare tutte le soluzioni tecniche per evitare il caching delle pagine contenenti informazioni sensibili oppure dati 129
Page 1 and 2:
UNIVERSITÀ POLITECNICA DELLE MARCH
Page 3 and 4:
INDICE INDICE .....................
Page 5 and 6:
ELENCO DELLE FIGURE Figura 1 Home p
Page 7 and 8:
CAPITOLO I - Introduzione 5
Page 9 and 10:
CAPITOLO I - Introduzione tecniche
Page 11 and 12:
CAPITOLO I - Introduzione 2 Gestion
Page 13 and 14:
CAPITOLO II - Talete: Autenticazion
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
• Ampliamento della superficie di
Page 25 and 26:
Page 27 and 28:
Page 29 and 30:
Page 31 and 32:
Page 33 and 34:
Page 35 and 36:
2.4.5 Diagramma delle classi CAPITO
Page 37 and 38:
Page 39 and 40:
Page 41 and 42:
Page 43 and 44:
CAPITOLO III - Progettare un’appl
Page 45 and 46:
3.2 Il significato dei design patte
Page 47 and 48:
Page 49 and 50:
Page 51 and 52:
Page 53 and 54:
Page 55 and 56:
4.1 Introduzione CAPITOLO IV - La s
Page 57 and 58:
CAPITOLO IV - La sicurezza nelle we
Page 59 and 60:
Page 61 and 62:
Page 63 and 64:
Page 65 and 66:
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
Page 77 and 78:
Page 79 and 80: CAPITOLO IV - La sicurezza nelle we
Page 87 and 88: Mentre con AnomynousTemplate si ha:
Page 95 and 96: CAPITOLO V - La sicurezza nell’ar
Page 105 and 106: 1 porsi dalla prospettiva dell’at
Page 113 and 114: CAPITOLO VI - Gli attacchi e il pro
Page 115 and 116: 6.1 Progetto OWASP CAPITOLO VI - Gl
Page 125 and 126: 6.2.5 I vantaggi nascosti CAPITOLO
Page 129: CAPITOLO VI - Gli attacchi e il pro
Page 149 and 150: 6.10 Denial of Service CAPITOLO VI
Page 151 and 152: 6.11 Insecure Configuration Managem
Page 153 and 154: CAPITOLO VII - Test per valutare la
Page 155 and 156: 7.1.1 Analisi del codice sorgente C
Page 163 and 164: vulnerabilità critiche di applicaz
Page 165 and 166: • Aggiungere la tecnologia SSL e
Page 167 and 168: Durante questi anni universitari so
Page 169 and 170: M. Fowler, D. Rice, M. Foemmel, E.
show all

analisi e gestione della sicurezza di una complessa applicazione ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?