Corso di formazione Test di sicurezza delle applicazioni: OWASP Top 10, SAST, DAST e SCA

A01:2025 – Access Control Rotto

L'access control applica una politica che impedisce agli utenti di agire al di fuori dei propri permessi previsti. I fallimenti tipicamente portano a divulgazione non autorizzata, modifica o distruzione di tutti i dati, oppure all'esecuzione di funzioni aziendali oltre i limiti dell'utente.

Aspetti Pratici

• Esempi pratici di access control rotti

• Access control sicuri e best practices

A02:2025 – Configurazione di sicurezza errata

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

Aspetti Pratici

• Esempi reali di configurazioni errate

• Procedure per prevenire le configurazioni errate, inclusa la gestione della configurazione e gli strumenti di automazione

A03:2025 – Fallimenti nella catena di fornitura del software

I fallimenti nella catena di fornitura del software sono interruzioni o altre violazioni nel processo di creazione, distribuzione o aggiornamento del software. Sono spesso causati da vulnerabilità o modifiche malevole nel codice di terze parti, negli strumenti o in altre dipendenze su cui il sistema si affida.

A04:2025 – Fallimenti crittografici

In generale, tutti i dati in transito dovrebbero essere crittografati a livello di trasporto (layer 4 OSI). Le precedenti barriere, come le prestazioni della CPU e la gestione delle chiavi private/certificati, sono ora gestite da CPU con istruzioni progettate per accelerare la crittografia (es. supporto AES) e dalla semplificazione della gestione delle chiavi private e dei certificati tramite servizi come LetsEncrypt.org, con i principali vendor cloud che offrono servizi di gestione dei certificati ancora più integrati per le loro piattaforme specifiche.

Oltre alla sicurezza del layer di trasporto, è importante determinare quali dati necessitano di crittografia a riposo e quali dati necessitano di una crittografia aggiuntiva in transito (a livello di applicazione, layer 7 OSI).

Ad esempio, password, numeri di carta di credito, cartelle cliniche, informazioni personali e segreti aziendali richiedono una protezione aggiuntiva, soprattutto se tali dati rientrano nelle leggi sulla privacy, come il Regolamento generale sulla protezione dei dati (GDPR) dell'UE, o in normative come lo Standard di sicurezza dei dati PCI (PCI DSS).

Aspetti Pratici

• Analisi dettagliata dei fallimenti crittografici, come algoritmi di crittografia deboli o gestione impropria delle chiavi

• Importanza dei meccanismi crittografici robusti, dei protocolli sicuri (SSL/TLS) e degli esempi di crittografia moderna nella sicurezza web

A05:2025 – Iniezione

Una vulnerabilità di iniezione è un difetto di sistema che consente a un attaccante di inserire codice o comandi malevoli (come codice SQL o shell) nei campi di input di un programma, ingannando il sistema affinché esegua il codice o i comandi come se facessero parte del sistema stesso. Questo può portare a conseguenze gravissime.

Aspetti Pratici

• Analisi dettagliata di iniezioni SQL, NoSQL, OS e LDAP

• Tecniche di mitigazione utilizzando istruzioni pre-compilate, query parametrizzate ed escaping degli input

A06:2025 – Design non sicuro

Il design non sicuro è una categoria ampia che rappresenta diverse debolezze, espresse come "mancato o inefficiente design del controllo".

Il design non sicuro non è la fonte di tutte le altre categorie di rischio della Top Ten. Nota che esiste una differenza tra design non sicuro e implementazione non sicura. Distinguiamo tra difetti di design e difetti di implementazione per una ragione precisa: hanno cause radice diverse, si manifestano in momenti diversi del processo di sviluppo e richiedono rimedi diversi.

Un design sicuro può ancora presentare difetti di implementazione che portano a vulnerabilità sfruttabili. Un design non sicuro non può essere corretto da un'implementazione perfetta, poiché i controlli di sicurezza necessari non sono mai stati creati per difendersi da attacchi specifici.

Uno dei fattori che contribuisce al design non sicuro è la mancanza di profiling dei rischi aziendali intrinseco al software o sistema in sviluppo, e quindi il fallimento nel determinare quale livello di design di sicurezza sia richiesto.

Aspetti Pratici

• Esploreremo difetti di design che possono portare a vulnerabilità, come la convalida impropria degli input

• Studieremo strategie per l'architettura sicura e i principi di design sicuro

A07:2025 – Fallimenti di autenticazione

Quando un attaccante riesce a ingannare un sistema affinché riconosca un utente non valido o errato come legittimo, questa vulnerabilità è presente.

Aspetti Pratici

• Problemi comuni di autenticazione

• Strategie di autenticazione sicure, come l'autenticazione a più fattori e la corretta gestione delle sessioni

A08:2025 – Fallimenti di integrità del software o dei dati

I fallimenti di integrità del software e dei dati si riferiscono a codice e infrastrutture che non proteggono contro codice o dati non validi o non fidati che vengono trattati come fidati e validi.

Un esempio di ciò è quando un'applicazione si affida a plugin, librerie o moduli da fonti non fidate, repository e reti di distribuzione dei contenuti (CDN).

Una pipeline CI/CD non sicura, che non consuma né fornisce controlli di integrità del software, può introdurre il potenziale per accessi non autorizzati, codice non sicuro o malevolo, o compromissione del sistema.

Un altro esempio è una CI/CD che recupera codice o artefatti da luoghi non fidati e/o non li verifica prima dell'uso (controllando la firma o un meccanismo simile).

Aspetti Pratici

• Focus su problemi come aggiornamenti del software non fidati e alterazione dei dati

• Mecanismi di aggiornamento sicuri e controlli di integrità dei dati

A09:2025 – Fallimenti nel logging e nell'allerta di sicurezza

Senza logging e monitoraggio, gli attacchi e le violazioni non possono essere rilevati e, senza allerte, è molto difficile rispondere rapidamente ed efficacemente durante un incidente di sicurezza.

Un logging insufficiente, un monitoraggio continuo, una rilevazione e allerte per avviare risposte attive possono verificarsi in qualsiasi momento.

Aspetti Pratici

• Importanza del logging delle informazioni rilevanti per la sicurezza e del monitoraggio delle attività sospette

• Strumenti e pratiche per un logging adeguato e un monitoraggio in tempo reale per rilevare precocemente le violazioni

A10:2025 – Gestione scorretta delle condizioni eccezionali

La gestione scorretta delle condizioni eccezionali nel software si verifica quando i programmi non riescono a prevenire, rilevare e rispondere a situazioni insolite e imprevedibili, il che porta a crash, comportamenti inaspettati e talvolta vulnerabilità.

Questo può coinvolgere uno o più dei seguenti 3 fallimenti:

• L'applicazione non impedisce il verificarsi di una situazione insolita

• Non identifica la situazione mentre sta accadendo

• Risponde in modo scadente o non risponde affatto alla situazione successivamente

SAST – Static Application Security Testing

1. Cosa sia l'analisi statica e quando eseguirla nell'SDLC (shift left)

2. Tipi di vulnerabilità rilevabili tramite SAST, codice vulnerabile vs codice sicuro

3. Panoramica degli strumenti SAST (es. Semgrep, SonarQube, Checkmarx, a seconda dello stack del cliente)

4. Esercitazione pratica: eseguire uno scan SAST su un repository con vulnerabilità introdotte deliberatamente, interpretare i risultati, classificare falsi positivi vs vulnerabilità reali

DAST – Dynamic Application Security Testing

1. Differenza tra SAST e DAST, test black box sull'applicazione in esecuzione

2. Flusso dello scan DAST, crawling, fuzzing, analisi delle risposte

3. Panoramica degli strumenti DAST (es. OWASP ZAP, Burp Suite)

4. Esercitazione pratica: eseguire uno scan DAST su un'applicazione di test vulnerabile (es. OWASP Juice Shop), identificare e validare i risultati

SCA – Software Composition Analysis

1. Rischio delle dipendenze e librerie di terze parti, vulnerabilità ereditate

2. SBOM, Software Bill of Materials, cos'è e perché è importante

3. Panoramica degli strumenti SCA (es. Dependency Check, Snyk, GitHub Dependabot)

4. Esercitazione pratica: eseguire uno scan SCA su un progetto reale, identificare dipendenze vulnerabili e creare un piano di rimedio (aggiornamento, patch, mitigazione)