Le 10 vulnerabilità più comuni della sicurezza web

OWASP, ovvero Open Web Security Project, è un'organizzazione benefica senza scopo di lucro che si occupa di migliorare la sicurezza del software e delle applicazioni web.

L'organizzazione pubblica un elenco delle principali vulnerabilità della sicurezza web basato sui dati di varie organizzazioni di sicurezza.

La priorità delle vulnerabilità della sicurezza web dipende dalla sfruttabilità, dalla rilevabilità e dall'impatto sul software.

• Sfruttabilità –Cosa è necessario per sfruttare la vulnerabilità della sicurezza? Massima sfruttabilità quando l'attacco richiede solo il browser web e minima quando si tratta di programmazione e strumenti avanzati.
• Rilevabilità – Quanto è facile rilevare la minaccia? Il valore più alto è l'informazione visualizzata nell'URL, nel modulo o nel messaggio di errore, mentre il valore più basso è il codice sorgente.
• Impatto o danno –Quanti danni verranno arrecati se la vulnerabilità della sicurezza viene scoperta o attaccata? Il massimo è il crash completo del sistema e il minimo è il nulla.

L'obiettivo principale di OWASP Top 10 è quello di istruire sviluppatori, progettisti, manager, architetti e organizzazioni sulle più importanti vulnerabilità di sicurezza.

Le 10 principali vulnerabilità di sicurezza secondo OWASP Top 10 sono:

SQL Injection

Descrizione

L'iniezione è una vulnerabilità della sicurezza che consente a un utente malintenzionato di alterare il backend SQL dichiarazioni 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 non desiderati e consente l'accesso a dati non autorizzati.

Il comando SQL che, se eseguito dall'applicazione Web, può anche esporre il database back-end.

Coinvolgimento

• Un utente malintenzionato può inserire contenuti dannosi nei campi vulnerabili.
• Dati sensibili come nomi utente, password, ecc. possono essere letti dal database.
• I dati del database possono essere modificati (Inserisci/Aggiorna/Elimina).
• Amministrazione Operapossono essere eseguite sul database

Oggetti vulnerabili

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

Esempi:

• SQL Injection nella pagina di accesso

Accedere a un'applicazione senza disporre di credenziali valide.

È disponibile un nome utente valido 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 Nome_utente = sjones AND Password = 1=1′ o pass123;

raccomandazioni

1. Elenco bianco dei campi di input
2. Evitare di visualizzare messaggi di errore dettagliati utili a un utente malintenzionato.

Cross Site Scripting

Descrizione

Cross Site Scripting è anche brevemente conosciuto come XSS.

Le vulnerabilità XSS prendono di mira gli script incorporati in una pagina che vengono eseguiti sul lato client, ovvero il browser dell'utente, anziché sul lato server. Questi difetti possono verificarsi quando l'applicazione accetta 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'aggressore potrà dirottare i cookie di sessione, deturpare 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à della sicurezza, un utente malintenzionato può inserire script nell'applicazione, rubare cookie di sessione, deturpare siti Web ed eseguire malware sui computer della vittima.

Oggetti vulnerabili

• Campi di input
• URL

Esempi

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

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

L'attacco più grave può essere effettuato se l'aggressore desidera visualizzare o archiviare cookie di sessione.

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

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

L'attacco può essere reso grave eseguendo uno script dannoso sul browser.

raccomandazioni

1. Campi di input della White List
2. Codifica ingresso-uscita

Autenticazione interrotta e gestione delle sessioni

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 viene terminata tramite il logout o la chiusura improvvisa del browser, questi cookie dovrebbero essere invalidati, ad esempio per ogni sessione dovrebbe esserci un nuovo cookie.

Se i cookie non vengono invalidati, i dati sensibili saranno presenti nel sistema. Ad esempio, se un utente utilizza un computer pubblico (Cyber ​​Cafe), i cookie del sito vulnerabile si depositano sul sistema e sono esposti a un utente malintenzionato. Un utente malintenzionato utilizza lo stesso computer pubblico e dopo qualche 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 e quando naviga nello stesso sito vulnerabile verrà aperta la sessione precedente della vittima. L'aggressore può fare tutto ciò che vuole, rubando informazioni sul profilo, informazioni sulla carta di credito, ecc.

Dovrebbe essere effettuato un controllo per verificare la forza dell'autenticazione e della gestione della sessione. Chiavi, token di sessione e 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.
• Gli ID di sessione sono gli stessi prima e dopo il logout e l'accesso.
• I timeout della sessione non sono implementati correttamente.
• L'applicazione assegna lo stesso ID sessione per ogni nuova sessione.
• Le parti autenticate dell'applicazione sono protette tramite SSL e le password vengono 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 sfruttate utilizzando cookie rubati o sessioni utilizzando XSS.

Esempi

1. L'applicazione di prenotazione della compagnia aerea supporta la riscrittura dell'URL, inserendo gli ID di sessione nell'URL:http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Vendita biglietti per le Maldive) Un utente autenticato del sito desidera far sapere ai 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 all'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 andarsene. L'attaccante utilizza lo stesso browser qualche tempo dopo e la sessione viene autenticata.

raccomandazioni

1. Tutti i requisiti di autenticazione e gestione delle sessioni devono essere definiti secondo lo standard OWASP Application Security Verification.
2. Non esporre mai le credenziali negli URL o nei log.
3. Dovrebbero essere compiuti sforzi notevoli anche per evitare difetti XSS che possono essere utilizzati per rubare gli ID di sessione.

Riferimenti di oggetti diretti non sicuri

Descrizione

Si verifica quando uno sviluppatore espone un riferimento a un oggetto di implementazione interna, come un file, una directory o una chiave di database come nell'URL o come parametro FORM. L'aggressore può utilizzare queste informazioni per accedere ad altri oggetti e 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:

Modificando "userid" nell'URL seguente, un aggressore potrebbe visualizzare le informazioni di altri utenti.

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

Un utente malintenzionato può visualizzare le informazioni di altri modificando il valore dell'ID utente.

Raccomandazioni:

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

Cross Site Request Forgery

Descrizione

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

Un attacco CSRF è un attacco che si verifica quando un sito web, un'e-mail o un programma dannoso 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 della vittima che ha effettuato l'accesso 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

• Utilizzando questa vulnerabilità come utente malintenzionato è possibile modificare le informazioni del profilo utente, modificare lo stato, creare un nuovo utente per conto dell'amministratore, ecc.

Oggetti vulnerabili

• Pagina Profilo utente
• Moduli di account utente
• Pagina delle transazioni commerciali

Esempi

La vittima ha effettuato l'accesso al sito web di una banca utilizzando credenziali valide. Riceve una mail da un aggressore che dice "Clicca 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 seguente e la incorpora in un pulsante che dice "Supporto la causa".

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 trasferirebbe $ 1000 dollari all'aggressore.

Consigli

1. Richiedi la presenza dell'utente durante l'esecuzione di azioni sensibili.
2. Implementare 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 di 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 comportano la compromissione completa del sistema. Anche mantenere il software aggiornato è una buona sicurezza.

Coinvolgimento

• Sfruttando questa vulnerabilità, l'aggressore può enumerare la tecnologia sottostante e le informazioni sulla versione del server dell'applicazione, le informazioni sul database e ottenere informazioni sull'applicazione per sferrare alcuni 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 rimossa. Gli account predefiniti non vengono modificati. L'aggressore può accedere con password predefinite e ottenere un accesso non autorizzato.
2. L'elenco delle directory non è disabilitato sul tuo server. L'aggressore scopre e può semplicemente elencare le directory per trovare qualsiasi file.

raccomandazioni

1. Un'architettura applicativa solida che garantisce 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 utente, le informazioni del profilo, i dati sanitari, le informazioni sulla carta di credito, ecc. rientrano tra i 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ù brevi di lunghezza fissa o in una chiave. Per decrittografare la stringa, dovrebbe essere disponibile l'algoritmo utilizzato per formare la chiave)

Coinvolgimento

• Utilizzando questa vulnerabilità, un utente malintenzionato può rubare e modificare dati scarsamente protetti per commettere furti di identità, frodi con carte di credito o altri crimini.

Oggetti vulnerabili

• Banca dati dell'applicazione.

Esempi

In una delle applicazioni bancarie, il database delle password utilizza hash non salati * per archiviare 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 sottoposti a forzatura brutale in pochissimo tempo, mentre le password salate richiederebbero migliaia di anni.

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

raccomandazioni

1. Garantire algoritmi standard adeguati e robusti. 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 fuori sede siano crittografati, ma le chiavi vengono gestite e sottoposte a backup separatamente.

Impossibile limitare l'accesso all'URL

Descrizione

Le applicazioni Web controllano i diritti di accesso all'URL prima di eseguire il rendering di collegamenti e pulsanti protetti. Le applicazioni devono eseguire controlli di controllo dell'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'aggressore può accedere 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'aggressore nota che l'URL indica il ruolo come "/user/getaccounts". Si modifica come “/admin/getaccounts”.
2. Un utente malintenzionato può aggiungere un ruolo all'URL.

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

raccomandazioni

1. Implementare controlli rigorosi sul controllo degli accessi.
2. Le politiche di autenticazione e autorizzazione dovrebbero essere basate 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 di certificati scaduti o non validi o il mancato utilizzo di SSL può consentire che la comunicazione venga esposta a utenti non attendibili, il che potrebbe 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 sicuro e applica il trasferimento delle credenziali solo su HTTPS.
2. Assicurati che il tuo certificato sia valido e non scaduto.

Esempi:

1. In un'applicazione che non utilizza SSL, un utente malintenzionato monitorerà semplicemente il traffico di rete e osserverà un cookie di sessione della vittima autenticata. 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 alcuni metodi per reindirizzare e inoltrare gli utenti ad altre pagine per uno scopo previsto.

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

Coinvolgimento

• Un utente malintenzionato può inviare all'utente un URL che contiene un URL autentico a cui viene aggiunto un URL dannoso codificato. Un utente semplicemente vedendo la parte autentica dell'URL inviato dall'aggressore può esplorarlo e potrebbe diventare una vittima.

Esempi

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

Modificato a

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 dei 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.