OWASP o Open Web Security Project è un'organizzazione di beneficenza senza scopo di lucro focalizzata sul miglioramento della sicurezza del software e delle 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 necessita solo del browser web e la minima è la programmazione e gli strumenti avanzati.
- Rilevabilità -
Quanto è facile rilevare la minaccia? La più alta è l'informazione visualizzata su URL, modulo o messaggio di errore e la più bassa è il codice sorgente.
- Impatto o danno -
Quanti danni verranno causati se la vulnerabilità della sicurezza viene esposta o attaccata? Il più alto è il crash del sistema completo 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.
Le prime 10 vulnerabilità di sicurezza secondo OWASP Top 10 sono:
- SQL Injection
- Cross Site Scripting
- Autenticazione interrotta e gestione delle sessioni
- Riferimenti a oggetti diretti non sicuri
- Richiesta tra siti falsi
- Configurazione errata della sicurezza
- Archiviazione crittografica non sicura
- Mancata limitazione dell'accesso all'URL
- Protezione dello strato di trasporto insufficiente
- Reindirizzamenti e inoltri non convalidati
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 dà 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ò iniettare contenuto dannoso 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).
- 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 accesso
Accesso a un'applicazione senza avere 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 a Interpreter come di seguito
SELEZIONA * DA Utenti DOVE Nome_utente = sjones E Password = 1 = 1 'o pass123;
Raccomandazioni
- Elenco bianco dei campi di input
- Evita di visualizzare messaggi di errore dettagliati utili a un utente malintenzionato.
Cross Site Scripting
Descrizione
Cross Site Scripting è anche brevemente noto come XSS.
Le vulnerabilità XSS prendono di mira gli script incorporati in una pagina che vengono eseguiti sul lato client, ovvero sul 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'autore dell'attacco 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, 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 precedente quando viene eseguito su un browser, verrà visualizzata una finestra di messaggio se il sito è vulnerabile a XSS.
L'attacco più serio può essere eseguito se l'aggressore desidera visualizzare o memorizzare il cookie di sessione.
2. http://demo.testfire.net/search.aspx?txtSearch
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
- Campi di input della lista bianca
- Codifica input output
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 la chiusura improvvisa del browser, questi cookie devono essere invalidati, ad esempio per ogni sessione dovrebbe esserci un nuovo cookie.
Se i cookie non vengono invalidati, i dati sensibili esisteranno nel sistema. Ad esempio, un utente che utilizza un computer pubblico (Cyber Cafe), i cookie del sito vulnerabile si trovano nel sistema e sono esposti a un aggressore. 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'aggressore può fare tutto ciò che vuole dal rubare informazioni sul profilo, informazioni sulla carta di credito, ecc.
È necessario eseguire un controllo per trovare la forza dell'autenticazione e della gestione della sessione. Chiavi, token di sessione e cookie devono essere implementati correttamente senza compromettere le password.
Oggetti vulnerabili
- Gli ID di sessione esposti sull'URL possono portare ad attacchi di correzione 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 dell'applicazione autenticate sono protette tramite SSL e le password vengono archiviate in formato hash o crittografato.
- La sessione può essere riutilizzata da un utente con privilegi bassi.
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 bloccate utilizzando cookie rubati o sessioni utilizzando XSS.
Esempi
- L'applicazione di prenotazione delle compagnie aeree supporta la riscrittura degli 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 desidera informare i suoi amici della vendita e invia un'e-mail. Gli amici ricevono l'ID della sessione e possono essere utilizzati per apportare modifiche non autorizzate o utilizzare in modo improprio i dettagli della carta di credito salvati.
- Un'applicazione è vulnerabile a XSS, grazie al quale un aggressore può accedere all'ID di sessione e può essere utilizzato per dirottare la sessione.
- 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
- Tutti i requisiti di autenticazione e gestione della sessione devono essere definiti secondo lo standard di verifica della sicurezza dell'applicazione OWASP.
- Non esporre mai le credenziali negli URL o nei log.
- Dovrebbero essere compiuti sforzi anche per evitare difetti XSS che possono essere utilizzati 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 interna, come un file, una directory o una chiave di database come nell'URL o come parametro FORM. L'autore dell'attacco 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 i dati o compromettere l'applicazione.
Oggetti vulnerabili
- Nell'URL.
Esempi:
La modifica di "userid" nel seguente URL può indurre un utente malintenzionato a visualizzare le informazioni di un altro utente.
http://www.vulnerablesite.com/userid=123 Modificato in http://www.vulnerablesite.com/userid=124
Un utente malintenzionato può visualizzare le informazioni degli altri modificando il valore dell'ID utente.
Raccomandazioni:
- Implementare controlli di controllo degli accessi.
- Evita di esporre riferimenti a oggetti negli URL.
- Verifica l'autorizzazione per tutti gli oggetti di riferimento.
Richiesta tra siti falsi
Descrizione
Cross Site Request Forgery è 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 dannoso fa sì che il browser di un utente esegua un'azione indesiderata su un sito attendibile per il quale l'utente è attualmente autenticato.
Un attacco CSRF forza 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 un utente malintenzionato può modificare le informazioni del profilo utente, cambiare lo stato, creare un nuovo utente per conto dell'amministratore, ecc.
Oggetti vulnerabili
- Pagina del 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 posta da un utente malintenzionato che dice "Fare 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'autore dell'attacco acquisisce questa richiesta e crea la richiesta sottostante e la inserisce in un pulsante che dice "Supporto causa".
http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000
Poiché la sessione è autenticata e la richiesta sta arrivando attraverso il sito web della banca, il server trasferirà $ 1000 dollari all'attaccante.
Raccomandazione
- Mandare la presenza dell'utente durante l'esecuzione di azioni sensibili.
- Implementa meccanismi come CAPTCHA, ri-autenticazione e token di richiesta univoci.
Configurazione errata della sicurezza
Descrizione
La configurazione della protezione deve essere definita e distribuita per l'applicazione, i framework, il server delle applicazioni, il server Web, il server 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'aggressore può enumerare la tecnologia sottostante e le informazioni sulla versione del server delle applicazioni, le informazioni sul database e ottenere informazioni sull'applicazione per lanciare altri attacchi.
Oggetti vulnerabili
- URL
- Campi modulo
- Campi di input
Esempi
- 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 le password predefinite e può ottenere un accesso non autorizzato.
- L'elenco delle directory non è disabilitato sul tuo server. L'aggressore scopre e può semplicemente elencare le directory per trovare qualsiasi file.
Raccomandazioni
- Una solida architettura applicativa che fornisce una buona separazione e sicurezza tra i componenti.
- Cambia nomi utente e password predefiniti.
- Disabilitare gli elenchi di directory e implementare 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 di dati sensibili su un sito Web.
Questi dati verranno archiviati nel database dell'applicazione. Quando questi dati vengono archiviati in modo improprio non utilizzando 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 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, modificare tali dati scarsamente protetti per effettuare 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. Un difetto di SQL injection consente all'autore dell'attacco di recuperare il file della password. Tutti gli hash non salati possono essere forzati 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
- Garantire algoritmi standard robusti appropriati. Non creare algoritmi crittografici propri. Utilizzare solo algoritmi pubblici approvati come AES, crittografia a chiave pubblica RSA e SHA-256, ecc.
- Assicurati che i backup offsite siano crittografati, ma le chiavi siano gestite e sottoposte a backup separatamente.
Mancata limitazione dell'accesso all'URL
Descrizione
Le applicazioni Web verificano i diritti di accesso all'URL prima di eseguire il rendering di link 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à, un utente malintenzionato 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
- L'utente malintenzionato nota che l'URL indica il ruolo come "/ user / getaccounts". Modifica come "/ admin / getaccounts".
- Un utente malintenzionato può aggiungere un ruolo all'URL.
http://www.vulnerablsite.com può essere modificato come http://www.vulnerablesite.com/admin
Raccomandazioni
- Implementa forti controlli di controllo degli accessi.
- I criteri di autenticazione e autorizzazione dovrebbero essere basati sui ruoli.
- Limita l'accesso agli URL indesiderati.
Protezione dello strato 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, il che potrebbe compromettere un'applicazione Web e / o rubare informazioni sensibili.
Coinvolgimento
- Sfruttando questa vulnerabilità della sicurezza web, un utente malintenzionato può intercettare 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
- Abilita HTTP protetto e applica il trasferimento delle credenziali solo su HTTPS.
- 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 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 viene eseguita una convalida adeguata durante il reindirizzamento ad altre pagine, gli aggressori possono utilizzarla e reindirizzare le vittime a siti di phishing o malware o utilizzare i forward per accedere a pagine non autorizzate.
Coinvolgimento
- Un utente malintenzionato può inviare un URL all'utente che contiene un URL autentico aggiunto con un URL dannoso codificato. Un utente semplicemente vedendo la parte autentica dell'URL inviato dall'aggressore può sfogliarlo e 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
- Evita semplicemente di utilizzare reindirizzamenti e inoltri nell'applicazione. Se utilizzato, non implica l'utilizzo di parametri utente nel calcolo della destinazione.
- Se i parametri di destinazione non possono essere evitati, assicurarsi che il valore fornito sia valido e autorizzato per l'utente.
Questo articolo è fornito da Prasanthi Eati