Guinguette Marais Poitevin

2. http://demo.testfire.net/search.aspx?txtSearch<iframe><src = http://google.com width = 500 height 500></iframe>

Lo script qui sopra quando viene eseguito, il browser caricherà un frame invisibile che punta a http://google.com.

L’attacco può essere reso serio eseguendo uno script malevolo sul browser.

Raccomandazioni

1. White Listing input fields
2. Input Output encoding

Broken Authentication and Session Management

Descrizione

I siti web solitamente creano un cookie di sessione e un ID di sessione per ogni sessione valida, e questi cookie contengono dati sensibili come nome utente, password, ecc. Quando la sessione si conclude o con il logout o con la chiusura improvvisa del browser, questi cookie dovrebbero essere invalidati, cioè per ogni sessione dovrebbe esserci un nuovo cookie.

Se i cookie non vengono invalidati, i dati sensibili rimarranno nel sistema. Per esempio, un utente che usa un computer pubblico (Cyber Cafe), i cookie del sito vulnerabile si trovano sul sistema e sono esposti a un attaccante. Un aggressore usa lo stesso computer pubblico dopo qualche tempo, i dati sensibili sono compromessi.

Nella stessa maniera, un utente che usa un computer pubblico, invece di disconnettersi, chiude bruscamente il browser. Un attaccante utilizza lo stesso sistema, quando naviga lo stesso sito vulnerabile, la sessione precedente della vittima sarà aperta. L’attaccante può fare tutto ciò che vuole, dal rubare le informazioni del profilo, le informazioni della carta di credito, ecc.

Un controllo dovrebbe essere fatto per trovare la forza dell’autenticazione e della gestione della sessione. Chiavi, token di sessione, cookie dovrebbero essere implementati correttamente senza compromettere le password.

Oggetti vulnerabili

• Gli ID di sessione esposti sull’URL possono portare a un attacco di fissazione della sessione.
• Gli ID di sessione sono gli stessi prima e dopo il logout e il login.
• I timeout di sessione non sono implementati correttamente.
• L’applicazione sta assegnando lo stesso ID di sessione per ogni nuova sessione.
• Le parti autenticate dell’applicazione sono protette utilizzando SSL e le password sono memorizzate in formato hashed o criptato.
• La sessione può essere riutilizzata da un utente con bassi privilegi.

Implicazione

• Facendo uso di questa vulnerabilità, un attaccante può dirottare una sessione, ottenere un accesso non autorizzato al sistema che permette la divulgazione e la modifica di informazioni non autorizzate.
• Le sessioni possono essere elevate utilizzando cookie rubati o sessioni utilizzando XSS.

Esempi

1. Un’applicazione di prenotazione aerea supporta la riscrittura dell’URL, mettendo gli ID di sessione nell’URL:

   http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Vendita di biglietti per le Maldive)

   Un utente autenticato del sito vuole far sapere ai suoi amici della vendita e invia un’e-mail. Gli amici ricevono l’ID di sessione e possono essere usati per fare modifiche non autorizzate o abusare dei dettagli della carta di credito salvati.

2. Un’applicazione è vulnerabile a XSS, con cui un attaccante può accedere all’ID di sessione e può essere usato per dirottare la sessione.
3. Il timeout delle applicazioni non è impostato correttamente. L’utente utilizza un computer pubblico e chiude il browser invece di disconnettersi e se ne va. L’attaccante usa lo stesso browser qualche tempo dopo, e la sessione viene autenticata.

Raccomandazioni

1. Tutti i requisiti di autenticazione e di gestione della sessione dovrebbero essere definiti secondo l’OWASP Application Security Verification Standard.
2. Non esporre mai le credenziali negli URL o nei log.
3. Sforzi notevoli dovrebbero essere fatti anche per evitare le falle XSS che possono essere usate per rubare gli ID di sessione.

Riferimenti insicuri a oggetti diretti

Descrizione

Si verifica quando uno sviluppatore espone un riferimento a un oggetto interno di implementazione, come un file, una directory o una chiave di database come URL o come parametro FORM. L’attaccante può usare queste informazioni per accedere ad altri oggetti e può creare un attacco futuro per accedere ai dati non autorizzati.

Implicazione

• Utilizzando questa vulnerabilità, un attaccante può ottenere l’accesso a oggetti interni non autorizzati, può modificare i dati o compromettere l’applicazione.

Oggetti vulnerabili

• Nell’URL.

Esempi:

Cambiare “userid” nel seguente URL può far sì che un attaccante veda le informazioni di altri utenti.

http://www.vulnerablesite.com/userid=123 Modificato in http://www.vulnerablesite.com/userid=124

Un attaccante può visualizzare le informazioni degli altri cambiando il valore dell’id utente.

Raccomandazioni:

1. Implementare i controlli di controllo degli accessi.
2. Evitare di esporre i riferimenti agli oggetti negli URL.
3. Verificare l’autorizzazione a tutti gli oggetti di riferimento.

Cross Site Request Forgery

Descrizione

Cross Site Request Forgery è una richiesta falsificata proveniente dal sito trasversale.

L’attacco CSRF è un attacco che si verifica quando un sito web, un’email o un programma malevolo induce il browser di un utente a eseguire un’azione indesiderata su un sito affidabile per il quale l’utente è attualmente autenticato.

Un attacco CSRF costringe il browser di una vittima autenticata a inviare una richiesta HTTP falsificata, includendo il cookie di sessione della vittima e qualsiasi altra informazione di autenticazione inclusa automaticamente, a un’applicazione web vulnerabile.

Un link sarà inviato dall’attaccante alla vittima quando l’utente clicca sull’URL quando ha effettuato l’accesso al sito web originale, i dati saranno rubati dal sito web.

Implicazione

• Utilizzando questa vulnerabilità un attaccante può cambiare le informazioni del profilo utente, cambiare lo stato, creare un nuovo utente a nome dell’amministratore, ecc.

Oggetti vulnerabili

• Pagina del profilo dell’utente
• Forme del conto utente
• Pagina delle transazioni commerciali

Esempi

La vittima è entrata nel sito di una banca usando credenziali valide. Riceve una mail da un attaccante che dice: “Per favore clicca qui per donare 1$ alla causa”.

Quando la vittima ci clicca sopra, viene creata una richiesta valida per donare 1$ ad un particolare conto.

http://www.vulnerablebank.com/transfer.do?account=cause&amount=1

L’attaccante cattura questa richiesta e crea una richiesta sottostante e la incorpora in un pulsante che dice “I Support Cause.”

http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000

Siccome la sessione è autenticata e la richiesta arriva attraverso il sito web della banca, il server trasferisce 1000 dollari all’attaccante.

Raccomandazione

1. Obbligare la presenza dell’utente durante l’esecuzione di azioni sensibili.
2. Implementare meccanismi come, Re-Authentication, e Token di richiesta unici.

Configurazione errata della sicurezza

Descrizione

La configurazione della sicurezza deve essere definita e distribuita per l’applicazione, i framework, il server delle applicazioni, il server web, il server del database e la piattaforma. Se questi sono configurati correttamente, un attaccante può avere accesso non autorizzato a dati sensibili o funzionalità.

A volte queste falle portano alla completa compromissione del sistema. Mantenere il software aggiornato è anche una buona sicurezza.

Implicazione

• Facendo uso di questa vulnerabilità, l’attaccante può enumerare la tecnologia sottostante e le informazioni sulla versione del server delle applicazioni, le informazioni sul database e ottenere informazioni sull’applicazione per montare qualche altro attacco.

Oggetti vulnerabili

• URL
• Campi modulo
• Campi di input

Esempi

1. La console di amministrazione dell’application server viene installata automaticamente e non viene rimossa. Gli account predefiniti non vengono modificati. L’attaccante può accedere con le password predefinite e può ottenere un accesso non autorizzato.
2. L’elenco delle directory non è disabilitato sul server. L’attaccante scopre e può semplicemente elencare le directory per trovare qualsiasi file.

Raccomandazioni

1. Una forte architettura dell’applicazione che fornisce una buona separazione e sicurezza tra i componenti.
2. Cambiare nomi utente e password di default.
3. Disabilitare gli elenchi delle directory e implementare i controlli di accesso.

Archiviazione crittografica insicura

Descrizione

L’archiviazione crittografica insicura è una vulnerabilità comune che esiste quando i dati sensibili non sono archiviati in modo sicuro.

Le credenziali dell’utente, le informazioni del profilo, i dettagli sulla salute, le informazioni della carta di credito, ecc. rientrano nelle informazioni dei dati sensibili su un sito web.

Questi dati vengono memorizzati nel database dell’applicazione. Quando questi dati sono memorizzati in modo improprio, non usando la crittografia o l’hashing*, saranno vulnerabili agli attaccanti.

(*Hashing è la trasformazione dei caratteri della stringa in stringhe più corte di lunghezza fissa o in una chiave. Per decifrare la stringa, l’algoritmo usato per formare la chiave dovrebbe essere disponibile)

Implicazione

• Utilizzando questa vulnerabilità, un aggressore può rubare, modificare tali dati debolmente protetti per condurre furti di identità, frodi con carte di credito o altri crimini.

Oggetti vulnerabili

• Database dell’applicazione.

Esempi

In una delle applicazioni bancarie, il database delle password utilizza hash non salati * per memorizzare le password di tutti. Una falla di SQL injection permette all’attaccante di recuperare il file delle password. Tutti gli hash non salati possono essere forzati in pochissimo tempo, mentre le password salate richiederebbero migliaia di anni.

(*Hash non salato – Il sale è un dato casuale aggiunto ai dati originali. Il sale viene aggiunto alla password prima dell’hashing)

Raccomandazioni

1. Assicurare algoritmi standard forti e appropriati. Non creare algoritmi crittografici propri. Usare solo algoritmi pubblici approvati come AES, crittografia a chiave pubblica RSA e SHA-256, ecc.
2. Assicurarsi che i backup fuori sede siano crittografati, ma le chiavi siano gestite ed eseguite separatamente.

Mancata limitazione dell’accesso agli URL

Descrizione

Le applicazioni web controllano i diritti di accesso agli URL prima di visualizzare link e pulsanti protetti. Le applicazioni devono eseguire simili controlli di accesso ogni volta che si accede a queste pagine.

Nella maggior parte delle applicazioni, le pagine, i luoghi e le risorse privilegiate non sono presentate agli utenti privilegiati.

Con un’ipotesi intelligente, un attaccante può accedere alle pagine privilegiate. Un attaccante può accedere a pagine sensibili, invocare funzioni e visualizzare informazioni riservate.

Implicazione

• Facendo uso di questa vulnerabilità l’attaccante può ottenere l’accesso agli URL non autorizzati, senza accedere all’applicazione e sfruttare la vulnerabilità. Un attaccante può accedere a pagine sensibili, invocare funzioni e visualizzare informazioni riservate.

Oggetti vulnerabili:

• URLs

Esempi

1. Attacker nota che l’URL indica il ruolo come “/user/getaccounts.” Modifica come “/admin/getaccounts”.
2. Un attaccante può aggiungere il ruolo all’URL.

http://www.vulnerablsite.com può essere modificato come http://www.vulnerablesite.com/admin

Raccomandazioni

1. Implementare forti controlli di accesso.
2. Le politiche di autenticazione e autorizzazione dovrebbero essere basate sui ruoli.
3. Restriggere l’accesso agli URL indesiderati.

Protezione insufficiente del livello di trasporto

Descrizione

Si occupa dello scambio di informazioni tra l’utente (client) e il server (applicazione). Le applicazioni trasmettono spesso informazioni sensibili come i dettagli di autenticazione, i dati della carta di credito e i token di sessione su una rete.

Utilizzando algoritmi deboli o utilizzando certificati scaduti o non validi o non utilizzando SSL si può permettere che la comunicazione sia esposta a utenti non fidati, che possono compromettere un’applicazione web e o rubare informazioni sensibili.

Implicazione

• Facendo uso di questa vulnerabilità di sicurezza web, un attaccante può fiutare le credenziali di un utente legittimo e ottenere l’accesso all’applicazione.
• Può rubare le informazioni della carta di credito.

Oggetti vulnerabili

• Dati inviati in rete.

Raccomandazioni

1. Abilitare HTTP sicuro e imporre il trasferimento delle credenziali solo su HTTPS.
2. Assicurarsi che il certificato sia valido e non scaduto.

Esempi:

1. Un’applicazione che non usa SSL, un attaccante semplicemente monitorerà il traffico di rete e osserverà un cookie di sessione autenticato della vittima. Un attaccante può rubare quel cookie ed eseguire un attacco Man-in-the-Middle.

Reindirizzamenti e inoltri non convalidati

Descrizione

L’applicazione web utilizza alcuni metodi per reindirizzare e inoltrare gli utenti ad altre pagine per uno scopo previsto.

Se non c’è un’adeguata validazione durante il reindirizzamento ad altre pagine, gli aggressori possono approfittarne e possono reindirizzare le vittime a siti di phishing o malware, o usare gli inoltri per accedere a pagine non autorizzate.

Implicazione

• Un attaccante può inviare un URL all’utente che contiene un URL genuino con un URL maligno codificato. Un utente, vedendo solo la parte genuina dell’URL inviato dall’attaccante, può navigare e può diventare una vittima.

Esempi

1.http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com

Modificato in

http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com

Raccomandazioni

1. Evitare semplicemente di utilizzare redirect e forward nell’applicazione. Se utilizzati, non utilizzare i parametri utente nel calcolo della destinazione.
2. Se i parametri di destinazione non possono essere evitati, assicurarsi che il valore fornito sia valido e autorizzato dall’utente.

Questo articolo è stato contribuito da Prasanthi Eati