A02:2025 Security Misconfiguration

Contesto.

Salendo dal #5 dell'edizione precedente, il 100% delle applicazioni testate è risultato avere qualche forma di configurazione errata, con un tasso medio di incidenza del 3,00% e oltre 719k occorrenze di una Common Weakness Enumeration (CWE) in questa categoria di rischio. Con lo spostamento sempre maggiore verso software altamente configurabile, non sorprende vedere questa categoria salire. Tra le CWE degne di nota vi sono CWE-16 Configuration e CWE-611 Improper Restriction of XML External Entity Reference (XXE).

Tabella dei punteggi.

CWE Mappate	Tasso Massimo di Incidenza	Tasso Medio di Incidenza	Copertura Massima	Copertura Media	Exploit Medio Ponderato	Impatto Medio Ponderato	Totale Occorrenze	Totale CVE
16	27,70%	3,00%	100,00%	52,35%	7,96	3,97	719.084	1.375

Descrizione.

La Security Misconfiguration si verifica quando un sistema, un'applicazione o un servizio cloud è configurato in modo errato dal punto di vista della sicurezza, creando vulnerabilità.

L'applicazione potrebbe essere vulnerabile se:

Manca un adeguato hardening della sicurezza in qualsiasi parte dello stack applicativo o i permessi sui servizi cloud sono configurati in modo errato.
Funzionalità non necessarie sono abilitate o installate (es. porte, servizi, pagine, account, framework di testing o privilegi non necessari).
Gli account di default e le relative password sono ancora abilitati e non modificati.
Manca una configurazione centrale per intercettare messaggi di errore eccessivi. La gestione degli errori rivela stack trace o altri messaggi di errore eccessivamente informativi agli utenti.
Per i sistemi aggiornati, le ultime funzionalità di sicurezza sono disabilitate o non configurate in modo sicuro.
Eccessiva priorità alla compatibilità con le versioni precedenti che porta a configurazioni non sicure.
Le impostazioni di sicurezza nei server applicativi, nei framework applicativi (es. Struts, Spring, ASP.NET), nelle librerie, nei database, ecc. non sono impostate su valori sicuri.
Il server non invia header o direttive di sicurezza, o non sono impostati su valori sicuri.

Senza un processo ripetibile e concertato di hardening della configurazione della sicurezza applicativa, i sistemi sono a rischio più elevato.

Come prevenire.

Devono essere implementati processi di installazione sicuri, incluso:

Un processo di hardening ripetibile che consenta la distribuzione rapida e semplice di un altro ambiente adeguatamente protetto. Gli ambienti di sviluppo, QA e produzione devono essere configurati in modo identico, con credenziali diverse utilizzate in ciascun ambiente. Questo processo deve essere automatizzato per minimizzare lo sforzo necessario per configurare un nuovo ambiente sicuro.
Una piattaforma minimale senza funzionalità, componenti, documentazione o campioni non necessari. Rimuovere o non installare funzionalità e framework non utilizzati.
Un'attività di revisione e aggiornamento delle configurazioni appropriate a tutte le note di sicurezza, aggiornamenti e patch come parte del processo di gestione delle patch (vedi A03 Software Supply Chain Failures). Revisionare i permessi dello storage cloud (es. permessi dei bucket S3).
Un'architettura applicativa segmentata che fornisca una separazione efficace e sicura tra componenti o tenant, con segmentazione, containerizzazione o gruppi di sicurezza cloud (ACL).
Invio di direttive di sicurezza ai client, es. Security Headers.
Un processo automatizzato per verificare l'efficacia delle configurazioni e delle impostazioni in tutti gli ambienti.
Aggiungere proattivamente una configurazione centrale per intercettare messaggi di errore eccessivi come backup.
Se queste verifiche non sono automatizzate, devono essere verificate manualmente almeno annualmente.
Utilizzare la federazione di identità, credenziali di breve durata o meccanismi di accesso basati sui ruoli forniti dalla piattaforma sottostante anziché incorporare chiavi o segreti statici nel codice, nei file di configurazione o nelle pipeline.

Scenari di attacco di esempio.

Scenario #1: Il server applicativo include applicazioni di esempio non rimosse dal server di produzione. Queste applicazioni di esempio hanno falle di sicurezza note che gli attaccanti utilizzano per compromettere il server. Supponiamo che una di queste applicazioni sia la console di amministrazione e che le credenziali predefinite non siano state cambiate. In tal caso, l'attaccante accede con la password predefinita e prende il controllo.

Scenario #2: Il directory listing non è disabilitato sul server. Un attaccante scopre che può semplicemente elencare le directory. L'attaccante trova e scarica le classi Java compilate, che decompila e fa reverse engineering per visualizzare il codice. L'attaccante trova quindi una grave falla nel controllo degli accessi nell'applicazione.

Scenario #3: La configurazione del server applicativo consente la restituzione di messaggi di errore dettagliati, come stack trace, agli utenti. Ciò potrebbe esporre informazioni sensibili o falle sottostanti, come le versioni dei componenti note per essere vulnerabili.

Scenario #4: Un cloud service provider (CSP) ha come default i permessi di condivisione aperti a Internet. Ciò consente l'accesso ai dati sensibili archiviati nello storage cloud.