Le vulnerabilità più comuni della sicurezza Web

OWASP o Open Web Security Project è un’organizzazione di beneficenza senza scopo di lucro focalizzata sul miglioramento della sicurezza di software e applicazioni web.

L’organizzazione pubblica un elenco delle principali vulnerabilità della sicurezza Web in base ai dati di varie organizzazioni di sicurezza.

Le vulnerabilità della sicurezza web hanno la priorità in base a sfruttabilità, rilevabilità e impatto sul software.

• Sfruttabilità –Cosa è necessario per sfruttare la vulnerabilità della sicurezza? La massima sfruttabilità quando l’attacco richiede solo il browser Web e la più bassa programmazione e strumenti avanzati.
• Rilevabilità –Quanto è facile rilevare la minaccia? Il più alto è l’informazione visualizzata su URL, modulo o messaggio di errore e il più basso è il codice sorgente.
• Impatto o danno –Quanto danno verrà fatto se la vulnerabilità della sicurezza viene esposta o attaccata? Il più alto è il crash completo del sistema e il più basso non è niente.

L’obiettivo principale di OWASP Top 10 è educare sviluppatori, designer, manager, architetti e organizzazioni sulle più importanti vulnerabilità di sicurezza.

SQL Injection

Descrizione

L’iniezione è una vulnerabilità di sicurezza che consente a un utente malintenzionato di alterare le istruzioni SQL di backend manipolando i dati forniti dall’utente.

L’iniezione si verifica quando l’input dell’utente viene inviato a un interprete come parte di un comando o di una query e induce l’interprete a eseguire comandi involontari e consente l’accesso a dati non autorizzati.

Il comando SQL che, se eseguito dall’applicazione web, può anche esporre il database di back-end.

Coinvolgimento

• Un utente malintenzionato può iniettare contenuti dannosi nei campi vulnerabili.
• I dati sensibili come nomi utente, password, ecc. possono essere letti dal database.
• I dati del database possono essere modificati (Inserisci/Aggiorna/Elimina).
• Le operazioni di amministrazione possono essere eseguite sul database

Oggetti vulnerabili

• Campi di input
• URL che interagiscono con il database.

Esempi:

• SQL injection nella pagina di login

Accedere a un’applicazione senza disporre di credenziali valide.

Nome utente valido è disponibile e la password non è disponibile.

URL di prova: http://demo.testfire.net/default.aspx

Nome utente: sjones

Password: 1=1′ o pass123

Query SQL creata e inviata all’interprete come di seguito

SELECT * FROM Utenti WHERE User_Name = sjones AND Password = 1=1′ o pass123;

Raccomandazioni

1. Lista bianca dei campi di input
2. Evita di visualizzare messaggi di errore dettagliati utili a un utente malintenzionato.

Cross Site Scripting

Descrizione

Il Cross Site Scripting è anche noto come XSS.

Le vulnerabilità XSS prendono di mira gli script incorporati in una pagina che vengono eseguiti sul lato client, ad esempio il browser dell’utente, piuttosto che sul lato server. Questi difetti possono verificarsi quando l’applicazione acquisisce dati non attendibili e li invia al browser Web senza un’adeguata convalida.

Gli aggressori possono utilizzare XSS per eseguire script dannosi sugli utenti in questo caso i browser delle vittime. Poiché il browser non può sapere se lo script è affidabile o meno, lo script verrà eseguito e l’attaccante può dirottare i cookie di sessione, deturpare i siti Web o reindirizzare l’utente a siti Web indesiderati e dannosi.

XSS è un attacco che consente all’aggressore di eseguire gli script sul browser della vittima.

Coinvolgimento:

• Sfruttando questa vulnerabilità di sicurezza, un utente malintenzionato può iniettare script nell’applicazione, può rubare cookie di sessione, deturpare siti Web e può eseguire malware sui computer della vittima.

Oggetti vulnerabili

• Campi di input
• URL

Esempi

1. http://www.vulnerablesite.com/home?”<script>alert(“xss”)</script >

Lo script sopra quando viene eseguito su un browser, verrà visualizzata una finestra di messaggio se il sito è vulnerabile a XSS.

L’attacco più grave può essere eseguito se l’attaccante desidera visualizzare o memorizzare i cookie di sessione.

2. http://demo.testfire.net/search.aspx?txtCerca <iframe > <src = http://google.com larghezza = 500 altezza 500></iframe>

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

L’attacco può essere aggravato eseguendo uno script dannoso sul browser.

Raccomandazioni

1. Campi di input della lista bianca
2. Codifica ingresso uscita

Autenticazione interrotta e gestione delle sessioni

Descrizione

I siti Web di solito 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 viene terminata tramite il logout o il browser viene chiuso bruscamente, questi cookie dovrebbero essere invalidati, ad esempio per ogni sessione dovrebbe esserci un nuovo cookie.

Se i cookie non vengono invalidati, i dati sensibili rimarranno nel sistema. Ad esempio, un utente che utilizza un computer pubblico (Cyber ​​Cafe), i cookie del sito vulnerabile si trovano sul sistema ed esposti a un utente malintenzionato. Un utente malintenzionato utilizza lo stesso computer pubblico dopo un po’ di tempo, i dati sensibili vengono compromessi.

Allo stesso modo, un utente che utilizza un computer pubblico, invece di disconnettersi, chiude bruscamente il browser. Un utente malintenzionato utilizza lo stesso sistema, quando naviga nello stesso sito vulnerabile, verrà aperta la sessione precedente della vittima. L’attaccante può fare tutto ciò che vuole rubando informazioni sul profilo, informazioni sulla 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 ad attacchi di fissazione della sessione.
• ID di sessione uguali prima e dopo il logout e il login.
• I timeout di sessione non sono implementati correttamente.
• L’applicazione assegna lo stesso ID di sessione per ogni nuova sessione.
• Le parti autenticate dell’applicazione sono protette tramite SSL e le password sono archiviate in formato hash o crittografato.
• La sessione può essere riutilizzata da un utente con privilegi limitati.

Coinvolgimento

• Sfruttando questa vulnerabilità, un utente malintenzionato può dirottare una sessione, ottenere un accesso non autorizzato al sistema che consente la divulgazione e la modifica di informazioni non autorizzate.
• Le sessioni possono essere potenziate utilizzando cookie rubati o sessioni utilizzando XSS.

Esempi

1. L’applicazione di prenotazione aerea supporta la riscrittura dell’URL, inserendo 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 informare i suoi amici della vendita e invia un’e-mail. Gli amici ricevono l’ID di sessione e possono essere utilizzati per apportare modifiche non autorizzate o utilizzare in modo improprio i dettagli della carta di credito salvati.
2. Un’applicazione è vulnerabile a XSS, grazie al quale un utente malintenzionato può accedere all’ID di sessione e può essere utilizzato per dirottare la sessione.
3. I timeout delle applicazioni non sono impostati correttamente. L’utente utilizza un computer pubblico e chiude il browser invece di disconnettersi e se ne va. L’aggressore utilizza lo stesso browser qualche tempo dopo e la sessione viene autenticata.

Raccomandazioni

1. Tutti i requisiti di autenticazione e gestione della sessione devono essere definiti secondo lo standard di verifica della sicurezza delle applicazioni OWASP.
2. Non esporre mai credenziali negli URL o nei log.
3. Dovrebbero essere fatti anche grandi sforzi per evitare difetti XSS che possono essere usati per rubare gli ID di sessione.

Riferimenti a oggetti diretti non sicuri

Descrizione

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

Coinvolgimento

• Utilizzando questa vulnerabilità, un utente malintenzionato può accedere a oggetti interni non autorizzati, modificare dati o compromettere l’applicazione.

Oggetti vulnerabili

• Nell’URL.

Esempi:

La modifica di “userid” nel seguente URL può far sì che un utente malintenzionato visualizzi le informazioni di altri utenti.

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

Un utente malintenzionato può visualizzare altre informazioni modificando il valore dell’ID utente.

Raccomandazioni:

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

Falsificazione della richiesta su più siti

Descrizione

Cross Site Request La contraffazione è una richiesta contraffatta proveniente dal cross site.

L’attacco CSRF è un attacco che si verifica quando un sito Web, un’e-mail o un programma dannosi induce il browser di un utente a eseguire un’azione indesiderata su un sito attendibile per il quale l’utente è attualmente autenticato.

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

Un collegamento verrà inviato dall’aggressore alla vittima quando l’utente fa clic sull’URL dopo aver effettuato l’accesso al sito Web originale, i dati verranno rubati dal sito Web.

Coinvolgimento

• L’utilizzo di questa vulnerabilità come utente malintenzionato può modificare le informazioni del profilo utente, modificare lo stato, creare un nuovo utente per conto dell’amministratore, ecc.

Oggetti vulnerabili

• Pagina del profilo utente
• Moduli account utente
• Pagina delle transazioni commerciali

Esempi

La vittima ha effettuato l’accesso a un sito Web di una banca utilizzando credenziali valide. Riceve la posta da un utente malintenzionato che dice “Fai clic qui per donare $ 1 alla causa”.

Quando la vittima fa clic su di esso, verrà creata una richiesta valida per donare $ 1 a un determinato account.

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

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

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

Poiché la sessione è autenticata e la richiesta arriva attraverso il sito Web della banca, il server trasferirà $ 1000 dollari all’attaccante.

Raccomandazione

1. Assegna la presenza dell’utente durante l’esecuzione di azioni sensibili.
2. Implementa meccanismi come CAPTCHA, riautenticazione e token di richiesta univoci.

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 utente malintenzionato può avere accesso non autorizzato a dati o funzionalità sensibili.

A volte tali difetti si traducono in un completo compromesso del sistema. Mantenere il software aggiornato è anche una buona sicurezza.

Coinvolgimento

• Sfruttando questa vulnerabilità, l’autore dell’attacco può enumerare la tecnologia sottostante e le informazioni sulla versione del server delle applicazioni, le informazioni sul database e ottenere informazioni sull’applicazione per eseguire altri attacchi.

Oggetti vulnerabili

• URL
• Campi modulo
• Campi di input

Esempi

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

Raccomandazioni

1. Una solida architettura applicativa che fornisce una buona separazione e sicurezza tra i componenti.
2. Modifica nomi utente e password predefiniti.
3. Disabilita gli elenchi di directory e implementa i controlli di controllo degli accessi.

Archiviazione crittografica non sicura

Descrizione

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

Le credenziali dell’utente, le informazioni sul profilo, i dettagli sanitari, le informazioni sulla carta di credito, ecc. rientrano nelle informazioni sui dati sensibili su un sito web.

Questi dati verranno archiviati nel database dell’applicazione. Quando questi dati vengono archiviati in modo improprio senza utilizzare la crittografia o l’hashing*, saranno vulnerabili agli aggressori.

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

Coinvolgimento

• Utilizzando questa vulnerabilità, un utente malintenzionato può rubare, modificare tali dati debolmente protetti per condurre furti di identità, frodi con carta di credito o altri reati.

Oggetti vulnerabili

• Banca dati delle applicazioni.

Esempi

In una delle applicazioni bancarie, il database delle password utilizza hash non salati * per memorizzare le password di tutti. Un difetto di SQL injection consente all’aggressore di recuperare il file della password. Tutti gli hash non salati possono essere brutalmente forzati in pochissimo tempo, mentre le password salate impiegherebbero migliaia di anni.

(*Hash non salati – Salt è un dato casuale aggiunto ai dati originali. Salt è aggiunto alla password prima dell’hashing)

Raccomandazioni

1. Garantire algoritmi standard forti appropriati. Non creare algoritmi crittografici propri. Utilizzare solo algoritmi pubblici approvati come AES, crittografia a chiave pubblica RSA e SHA-256, ecc.
2. Assicurati che i backup offsite siano crittografati, ma che le chiavi siano gestite e sottoposte a backup separatamente.

Mancata restrizione dell’accesso all’URL

Descrizione

Le applicazioni Web controllano i diritti di accesso all’URL prima di visualizzare collegamenti e pulsanti protetti. Le applicazioni devono eseguire controlli di accesso simili ogni volta che si accede a queste pagine.

Nella maggior parte delle applicazioni, le pagine, le posizioni e le risorse privilegiate non vengono presentate agli utenti privilegiati.

Con un’ipotesi intelligente, un utente malintenzionato può accedere alle pagine dei privilegi. Un utente malintenzionato può accedere a pagine sensibili, richiamare funzioni e visualizzare informazioni riservate.

Coinvolgimento

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

Oggetti vulnerabili:

• URL

Esempi

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

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

Raccomandazioni

1. Implementa severi controlli di controllo degli accessi.
2. I criteri di autenticazione e autorizzazione devono essere basati sui ruoli.
3. Limita l’accesso agli URL indesiderati.

Protezione del livello di trasporto insufficiente

Descrizione

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

L’utilizzo di algoritmi deboli o l’utilizzo di certificati scaduti o non validi o il mancato utilizzo di SSL può consentire l’esposizione della comunicazione a utenti non attendibili, che potrebbero compromettere un’applicazione Web e/o rubare informazioni sensibili.

Coinvolgimento

• Sfruttando questa vulnerabilità della sicurezza Web, un utente malintenzionato può annusare le credenziali dell’utente legittimo e ottenere l’accesso all’applicazione.
• Può rubare i dati della carta di credito.

Oggetti vulnerabili

• Dati inviati in rete.

Raccomandazioni

1. Abilita HTTP protetto e applica il trasferimento delle credenziali solo su HTTPS.
2. Assicurati che il tuo certificato sia valido e non scaduto.

Esempi:

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

Reindirizzamenti e inoltri non convalidati

Descrizione

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

Se non esiste una convalida adeguata durante il reindirizzamento ad altre pagine, gli aggressori possono farne uso e reindirizzare le vittime a siti di phishing o malware o utilizzare inoltri per accedere a pagine non autorizzate.

Coinvolgimento

• Un utente malintenzionato può inviare un URL all’utente che contiene un URL genuino con l’aggiunta di un URL dannoso codificato. Un utente, semplicemente vedendo la parte genuina dell’URL inviato dall’attaccante, può esplorarlo e potrebbe 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. Evita semplicemente di utilizzare reindirizzamenti e inoltri nell’applicazione. Se utilizzato, non implica l’utilizzo di 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 per l’utente.