Cos’è OWASP? OWASP: le 10 principali vulnerabilità

Nota: il seguente articolo ti aiuterà con: Cos’è OWASP? OWASP: le 10 principali vulnerabilità

OWASP sta per Open Web Application Security Project. È un’organizzazione no-profit che rilascia documenti di sensibilizzazione standard, strumenti come OWASP ZAP e tecnologie per la sicurezza delle applicazioni web. Tutte queste risorse sono gratuite e open source.

La comunità OSWAP segue il modello di “comunità aperta” in base al quale chiunque può contribuire ai progetti OWASP.

La sicurezza informatica è essenziale per mantenere i nostri dati al sicuro e preservare la privacy nell’era odierna. OWASP è un’organizzazione no-profit che si occupa della sicurezza delle applicazioni web. Immergiamoci nell’articolo per comprendere OWASP e le dieci principali vulnerabilità di OWASP.

La comunità OWASP pubblica una top 10 OWASP ogni due o tre anni. Questo elenco contiene i dieci principali rischi per la sicurezza o vulnerabilità delle applicazioni Web, con i passaggi e le migliori pratiche per prevenirli.

Si consiglia alle aziende di adottare questo documento per mantenere la sicurezza della propria applicazione e garantire che la propria applicazione non presenti questi rischi o vulnerabilità.

Vediamo le prime 10 vulnerabilità OWASP secondo l’ultimo elenco pubblicato nel 2021.

Quando l’autenticazione e i controlli di accesso di un’applicazione web non sono implementati correttamente, gli aggressori possono accedere a informazioni riservate sugli utenti e agire come utenti o amministratori, operazione nota come Broken Access Control.

Secondo i test, il 94% delle applicazioni web ha violato il controllo degli accessi con un tasso di incidenza medio del 3,81%.

Alcuni esempi di controllo degli accessi interrotti possono essere:

• Gli aggressori possono accedere al punto API REST per POST, DELETE e altre operazioni se manca l’autenticazione.
• I metadati dell’applicazione possono essere manipolati, ad esempio manomettendo i cookie o il token di controllo dell’accesso JWT.
• L’aggressore può visualizzare, modificare o eliminare i dettagli dell’utente.
• L’aggressore può aggirare i controlli di controllo modificando gli URL.

Puoi proteggere la tua applicazione dal controllo degli accessi interrotti utilizzando alcune delle misure preventive menzionate di seguito.

• Utilizza i test di penetrazione per scoprire alcuni controlli di accesso non funzionanti nell’applicazione.
• La tua applicazione dovrebbe avere forti meccanismi di controllo dell’accesso e dell’autorizzazione implementati nell’applicazione web.
• L’accesso a qualsiasi dato dovrebbe richiedere un’autorizzazione, ad eccezione delle risorse pubbliche.
• Utilizza l’autenticazione a più fattori per migliorare la sicurezza dell’applicazione.
• Puoi utilizzare le soluzioni IAST (Interactive Application Security Testing) per rilevare la falsificazione delle richieste cross-site o l’archiviazione non sicura dei dati sensibili degli utenti.
• L’utente dovrebbe essere avvisato in caso di errori nel controllo degli accessi e i registri dovrebbero anche essere archiviati per riferimento futuro.
• I token di sessione dovrebbero essere di breve durata in modo che gli aggressori non abbiano abbastanza tempo e opportunità per entrare nel sistema.

Leggi anche: Cos’è la crittografia? Spiegazione di 5 tipi di crittografia

Il fallimento crittografico, precedentemente noto come esposizione dei dati sensibili, porta all’esposizione di dati sensibili e compromette il sistema. L’errore crittografico può verificarsi se:

• Gli algoritmi di crittografia utilizzati sono vecchi e presentano alcune vulnerabilità.
• Mancano alcune intestazioni HTTP.
• I dati trasmessi non vengono sottoposti ad hashing correttamente,
• Vengono utilizzate funzioni hash o algoritmi di crittografia deprecati.

I dati sensibili crittografati in modo improprio, come i dettagli delle carte di credito/debito e le password, possono essere esposti agli aggressori. Pertanto, se necessario, dovrebbero essere archiviati con particolare cautela poiché questi dati rientrano nelle leggi e nei regolamenti sulla privacy come GDPR e PCI DSS.

Puoi proteggere la tua applicazione da errori crittografici utilizzando alcune misure preventive specificate di seguito.

• Identificare e classificare i dati sensibili secondo le leggi, le norme e i regolamenti sulla privacy.
• Continua ad aggiornare regolarmente gli algoritmi e i protocolli di crittografia.
• Dovrebbero essere archiviati solo i dati altamente richiesti e il resto dovrebbe essere scartato o troncato.
• È necessario utilizzare funzioni di hashing avanzate per archiviare password come Argon2, scrypt, bcrypt..
• Utilizza gli strumenti IAST e SAST (Static Application Security Testing) per identificare qualsiasi rischio di esposizione dei dati e algoritmi difettosi.

L’invio di dati non validi all’applicazione web da parte dell’aggressore per raccogliere alcune informazioni o per fare qualcosa che l’applicazione non dovrebbe fare è noto come iniezione di codice. I dati non validi vengono inviati tramite l’aiuto di un comando o di una query come una query SQL. Esempi di iniezioni sono iniezioni SQL, iniezioni LDAP, iniezioni di comandi del sistema operativo.

Cross-Site Scripting (XSS) fa ora parte dei criteri di inserimento. Puoi proteggere la tua applicazione dagli attacchi Injection utilizzando alcune delle misure preventive specificate di seguito.

• Convalidare l’input fornito dall’utente sul lato server.
• Utilizza gli strumenti SAST e IAST per identificare i difetti di iniezione durante i test.
• Utilizzare lo schema di escape sull’input dell’utente prima di inserire l’input nella query.
• È necessario utilizzare i controlli SQL e Limit in modo che molti record non vengano divulgati durante un attacco SQL injection.
• Mantieni aggiornati il ​​tuo ambiente di sviluppo e i tuoi pacchetti.

Leggi anche: Cos’è una SQL Injection? Come prevenirlo?

I difetti presenti nella progettazione dell’applicazione possono portare a rischi che rientrano nella categoria Progettazione insicura. Questa categoria è stata introdotta nel 2021.

Ad esempio, non hai considerato alcuni requisiti di sicurezza, come l’aggiunta di vincoli relativi alla password durante la fase di progettazione. L’applicazione che verrà sviluppata successivamente non avrà vincoli di password; quindi, sarà un rischio. L’utente può aggiungere qualsiasi password di stringa intera come qwertyuiop, password. L’aggressore può forzare l’applicazione poiché l’indisponibilità dei vincoli faciliterà il suo lavoro.

La differenza tra i rischi di progettazione sicuri e quelli non sicuri è che i progetti sicuri possono presentare alcuni bug o problemi di implementazione che possono essere risolti. Tuttavia, questo non è il caso dei progetti insicuri.

Seguire le misure preventive specificate di seguito per ridurre al minimo i rischi di progettazione non sicura nella propria applicazione.

• Prima della fase di sviluppo – nella fase di progettazione – ogni requisito dovrebbe essere considerato attentamente, in particolare i requisiti di sicurezza.
• Durante la progettazione del flusso dell’applicazione, esamina sempre le fasi di errore: quando l’applicazione può fallire e cosa dovrebbe fare l’applicazione in caso di fallimento o errore.
• Scrivere test di integrazione e unitari e coprire tutte le fasi del fallimento.
• L’aggressore può abusare dell’applicazione per trovare scappatoie o alcune informazioni sensibili. Pertanto, durante il test dell’applicazione, copri tutti gli aspetti, inclusi i casi d’uso e i casi di uso improprio.
• Condurre workshop sulla modellazione delle minacce per esaminare i principali problemi di sicurezza come l’accesso e l’autenticazione.
• Impara dai precedenti problemi di progettazione non sicura e tieni presente di considerarli nella tua nuova applicazione.

La mancanza di sicurezza che si verifica a causa di impostazioni, funzionalità o autorizzazioni non configurate correttamente o non necessarie rientra nella categoria di errata configurazione della sicurezza. Dipende dalla configurazione dello sviluppatore.

Circa il 90% delle applicazioni testate nel 2021 presentavano errori di configurazione.

Un classico esempio di errata configurazione della sicurezza potrebbe essere che l’account e le password predefiniti ottenuti con l’applicazione di esempio siano ancora validi e abilitati. L’aggressore può facilmente utilizzarli per accedere all’applicazione come amministratore.

Gli attacchi XML External Entities (XXE) rientrano nella categoria degli errori di configurazione della sicurezza. In questo attacco viene presa di mira l’applicazione che analizza gli input XML. Può verificarsi un attacco se il parser XML configurato in modo errato analizza un input XML avente un riferimento a un’entità esterna.

Di seguito sono elencate alcune misure preventive per verificare l’errata configurazione della sicurezza.

• Utilizza il test dinamico per scoprire configurazioni errate nella tua applicazione.
• Tutte le applicazioni e i sistemi operativi devono essere configurati in modo sicuro e aggiornati regolarmente.
• Non conservare funzionalità, impostazioni o componenti non necessari nell’applicazione.
• Il server dovrebbe inviare intestazioni di sicurezza e avere valori sicuri.
• Mantieni identici i tuoi sistemi di sviluppo, produzione e QA, tuttavia, con valori di credenziali diversi.

Leggi anche: Cos’è un attacco DoS e DDoS? Tipi di attacchi

L’utilizzo di componenti vulnerabili e obsoleti come pacchetti, framework e API nella tua applicazione la espone a vulnerabilità. L’aggressore può avere un impatto negativo sulla tua applicazione, ad esempio grave perdita di dati o acquisizione del server. Questa categoria era precedentemente chiamata “Utilizzo di componenti con vulnerabilità note”.

Recentemente è stata scoperta in tutto il mondo la vulnerabilità logj4, attraverso la quale l’hacker può prendere il controllo dei dispositivi vulnerabili ed eseguire qualsiasi codice su di essi. A causa di questa vulnerabilità è stata affrontata un’enorme perdita. La vulnerabilità log4j è un esempio perfetto e recente della categoria dei componenti vulnerabili e obsoleti.

Controlla i modi indicati di seguito per mantenere la tua applicazione lontana dalle vulnerabilità in questa categoria.

• Continua ad aggiornare le librerie e gli altri componenti utilizzati regolarmente dalla tua applicazione.
• Non conservare funzionalità, dipendenze o file inutilizzati nell’applicazione.
• Tieni d’occhio le ultime notizie sulla sicurezza e, se qualche componente che usi viene sfruttato, rimuovilo dalla tua applicazione o applica la patch se rilasciata il prima possibile.
• Tieni traccia di tutte le versioni dei componenti che utilizzi.
• Configura molto bene la tua applicazione.
• Continua a testare tempestivamente la compatibilità di ogni componente.

Quando le funzionalità di autenticazione e gestione della sessione non sono implementate correttamente, viene data all’aggressore l’autorizzazione o la facilità di rubare l’identità dell’utente compromettendo la password. Questa categoria era precedentemente nota come Autenticazione interrotta. Di seguito sono elencati alcuni esempi di quando possono verificarsi errori di identificazione e autenticazione.

• Le password e altri dati sensibili non sono sottoposti ad hashing forte.
• Viene utilizzata una password debole.
• L’aggressore può usare la forza bruta nell’applicazione.
• Il processo di “password dimenticata” è fragile e vengono utilizzate “domande basate sulla conoscenza”.
• La sessione non è gestita correttamente. Ad esempio, dopo la disconnessione, l’ID della sessione non viene annullato oppure i dettagli della sessione vengono esposti tramite l’URL.

Seguire le misure preventive specificate di seguito per ridurre al minimo gli errori di identificazione e autenticazione dell’applicazione.

• Implementare l’autenticazione a più fattori per rafforzare la sicurezza dell’applicazione.
• Non distribuire l’applicazione con credenziali predefinite come “admin, admin”.
• Utilizza una password complessa per la tua applicazione che includa alfabeti (az AZ), numeri (0-9) e caratteri speciali (!, &, -).
• Non utilizzare password facilmente indovinabili come nome, data di nascita e nemmeno password facili come “abcdef” o “password”.
• Limita il numero di tentativi di accesso non riusciti e avvisa l’utente.
• Continua a modificare tempestivamente le tue password.
• Esegui test DAST e SCA prima di distribuire l’applicazione e rimuovi o correggi tutte le vulnerabilità rilevate.
• Utilizza una funzionalità di gestione sicura delle sessioni e assicurati che i dettagli della sessione non vengano esposti tramite URL.

Leggi anche: Cos’è com.sec.epdg?

Come suggerisce il nome “integrità del software e dei dati”, il guasto dovuto ad alcuni codici compromette l’integrità dei dati rientra in questa categoria.

Ad esempio, quando utilizzi una libreria o un plug-in proveniente da una fonte non attendibile, potresti esporre la tua pipeline CI/CD all’aggressore per ottenere l’accesso al tuo sistema. Una volta che l’aggressore ottiene l’accesso al tuo sistema, può creare e caricare aggiornamenti. Attraverso la funzionalità di aggiornamento automatico, centinaia e migliaia di sistemi possono essere colpiti dal download di questo aggiornamento dannoso.

La deserializzazione non sicura, una parte di questa categoria, consente all’aggressore di eseguire codice nel sistema. L’aggressore può anche avviare l’attacco Denial of Service (DoS).

Seguire le misure preventive specificate di seguito per ridurre al minimo i problemi di integrità nell’applicazione.

• Utilizzare i test di penetrazione per ridurre il rischio.
• Assicurati che le librerie e i plugin che stai utilizzando provengano da una fonte attendibile.
• Verifica che i dati/aggiornamenti che ricevi provengano da una fonte attendibile utilizzando le firme digitali.
• Esamina di tanto in tanto il codice e la configurazione per verificare se è presente o meno codice dannoso.
• La pipeline CI/CD deve avere controlli di accesso e configurazione adeguati.

Quando la sicurezza di un’applicazione viene compromessa, i registri vengono utilizzati per rilevare l’attacco e rispondere ad esso. L’incapacità della funzionalità di registrazione e monitoraggio dell’applicazione di fornire dettagli sufficienti e adeguati rientra nella categoria degli errori di registrazione e monitoraggio della sicurezza.

Se i log non sono presenti, non è possibile controllare o monitorare se si è verificata o meno un’interruzione. Pertanto, la registrazione e il monitoraggio sono componenti essenziali di qualsiasi applicazione.

Scopri le modalità indicate di seguito che puoi implementare nella tua applicazione per proteggerla dalla registrazione di sicurezza e dal monitoraggio degli errori.

• Assicurarsi che tutti gli errori relativi alla sicurezza, come gli errori di accesso o di convalida dell’input, vengano registrati nel sistema.
• Assicurati che il tuo registro contenga dati adeguati per identificare attacchi o attività sospette.
• Utilizza i test di penetrazione per verificare la registrazione e il monitoraggio della tua applicazione.
• Assicurati che i log non siano visibili all’utente o all’aggressore.
• Utilizzare funzionalità di monitoraggio e avviso in modo che non appena viene rilevata un’attività sospetta, questa venga segnalata alla persona responsabile e venga intrapresa un’azione.

La falsificazione delle richieste lato server si verifica quando l’applicazione recupera alcuni dati dall’URL specificato dall’utente senza nemmeno prima convalidare l’URL. In uno scenario del genere, l’aggressore può specificare qualsiasi URL come input e il server protetto da un firewall richiederebbe le risorse da quell’URL senza nemmeno convalidare l’URL.

Controlla i modi indicati di seguito per mantenere la tua applicazione lontana dalle vulnerabilità in questa categoria.

• Non accettare l’URL come input dall’utente finché non viene richiesto.
• Convalida sempre l’input dell’utente.
• Assicurati che la tua applicazione non reindirizzi le richieste HTTP.
• Blocca il traffico indesiderato utilizzando la policy firewall “nega per impostazione predefinita”.

Leggi anche: Spiegazione degli attacchi ransomware