A05:2021 – Security Misconfiguration

Fattori

CWEs corrispondenti	Tasso di incidenza Max	Tasso di incidenza Medio	Sfruttabilità pesata	Impatto Medio	Copertura Max	Copertura media	Occorrenze Totali	CVE Totali
20	19.84%	4.51%	8.12	6.56	89.58%	44.84%	208,387	789

Panoramica

Sale dalla posizione #6 della scorsa edizione, il 90% delle applicazioni testate sono risultate vulnerabili ad una qualche forma di malconfigurazione, con un tasso medio di incidenza del 4%, e più di 208k occorrenze di Common Weakness Enumeration (CWE) in questa categoria di rischio. Con un trend in crescita verso software sempre più configurabili, non sorprende vedere queste categoria salire in classifica. Le CWE incluse sono CWE-16 Configuration and CWE-611 Improper Restriction of XML External Entity Reference.

Descrizione

L'applicazione potrebbe risultare vulnerabile se:

Manca l'hardening di sicurezza appropriato in qualsiasi parte dello stack applicativo o permessi configurati in modo improprio sui servizi cloud.
Sono abilitate o installate funzioni non necessarie (ad es. porte, servizi, pagine, account o privilegi non necessari).
Gli account di default sono ancora abilitati e presentano password predefinite.
A seguito di condizioni di errore, vengono rivelate agli utenti stack traces o altri messaggi di errore troppo verbosi.
Per i sistemi aggiornati, le ultime funzionalità di sicurezza sono disabilitate o non configurate in modo adeguato.
Le impostazioni di sicurezza negli application server, nei framework (ad esempio, Struts, Spring, ASP.NET), nelle librerie, database, ecc. non sono configurate su valori sicuri.
Il server non invia header o direttive di sicurezza o non sono impostati su valori sicuri.
Il software non è aggiornato o è vulnerabile (vedere A06:2021-Vulnerable and Outdated Components).

Senza un processo coordinato e ripetibile per la configurazione della sicurezza delle applicazioni, i sistemi presentano un rischio maggiore.

Come prevenire

Dovrebbero essere implementati processi di installazione sicuri, tra cui:

Un processo di hardening ripetibile rende veloce e facile il deploy di un altro ambiente preconfigurato in modo sicuro. Gli ambienti di sviluppo, QA e di produzione dovrebbero essere tutti configurati in modo speculare, con credenziali diverse per ogni ambiente. Questo processo dovrebbe essere automatizzato per minimizzare lo sforzo richiesto per impostare un nuovo ambiente configurato in modo sicuro.
Una piattaforma minimale senza funzionalità,componenti, documentazione ed esempi inutili. Rimuovere o non installare funzionalità e framework inutilizzati.
Un task per rivedere e aggiornare le configurazioni appropriate a tutte le security notes, aggiornamenti e patch come parte del processo di gestione delle patch (vedere A06:2021-Vulnerable and Outdated Components). Revisionare i permessi del cloud storage (ad esempio, i permessi dei bucket S3).
Un'architettura applicativa segmentata fornisce un'efficace e sicura separazione tra componenti o tenant, con segmentazione, containerizzazione, o cloud security groups (ACL).
L'invio di direttive di sicurezza ai client, ad esempio, i Security Headers.
Un processo automatizzato per verificare l'efficacia delle configurazioni e impostazioni in tutti gli ambienti.

Esempi di scenari d'attacco

Scenario #1: L'application server viene fornito con applicazioni di esempio non rimosse dal server di produzione. Queste applicazioni di esempio hanno falle di sicurezza note che gli attaccanti usano per compromettere il server. Supponiamo che una di queste applicazioni sia la console di amministrazione e che gli account predefiniti non siano stati cambiati. In questo caso, l'attaccante accede con le password predefinite e prende il controllo.

Scenario #2: La funzionalità di directory listing non è disabilitata sul server. Un attaccante scopre che si possono elencare tutte le directory. L'attaccante trova e scarica le classi Java compilate, su cui esegue la decompilazione e il reverse engineering per visualizzare il codice sorgente. L'attaccante trova poi una grave difetto di controllo degli accessi nell'applicazione.

Scenario #3: La configurazione dell'application server permette di restituire agli utenti messaggi di errore dettagliati, ad esempio la stack trace. Questa problematica potenzialmente espone informazioni sensibili o problematiche come versioni dei componenti che sono note per essere vulnerabili.

Scenario #4: Un cloud service provider ha dei permessi di condivisione predefiniti aperti a Internet da altri utenti nell'header Content Security Policy (CSP). Questo permette l'accesso ai dati sensibili memorizzati nel cloud storage.