diff --git a/2025/docs/it/0x00_2025-Introduction.md b/2025/docs/it/0x00_2025-Introduction.md new file mode 100644 index 000000000..4d7675035 --- /dev/null +++ b/2025/docs/it/0x00_2025-Introduction.md @@ -0,0 +1,113 @@ +![OWASP Logo](../assets/TOP_10_logo_Final_Logo_Colour.png) + +# I Dieci Rischi di Sicurezza delle Applicazioni Web Più Critici + +# Introduzione + +Benvenuto all'8ª edizione dell'OWASP Top Ten! + +Un enorme ringraziamento a tutti coloro che hanno contribuito con dati e prospettive nel sondaggio. Senza di voi, questa edizione non sarebbe stata possibile. **GRAZIE!** + + +## Presentazione dell'OWASP Top 10:2025 + + + +* [A01:2025 - Broken Access Control](A01_2025-Broken_Access_Control.md) +* [A02:2025 - Security Misconfiguration](A02_2025-Security_Misconfiguration.md) +* [A03:2025 - Software Supply Chain Failures](A03_2025-Software_Supply_Chain_Failures.md) +* [A04:2025 - Cryptographic Failures](A04_2025-Cryptographic_Failures.md) +* [A05:2025 - Injection](A05_2025-Injection.md) +* [A06:2025 - Insecure Design](A06_2025-Insecure_Design.md) +* [A07:2025 - Authentication Failures](A07_2025-Authentication_Failures.md) +* [A08:2025 - Software or Data Integrity Failures](A08_2025-Software_or_Data_Integrity_Failures.md) +* [A09:2025 - Security Logging & Alerting Failures](A09_2025-Security_Logging_and_Alerting_Failures.md) +* [A10:2025 - Mishandling of Exceptional Conditions](A10_2025-Mishandling_of_Exceptional_Conditions.md) + + +## Cosa è cambiato nel Top 10 per il 2025 + +Ci sono due nuove categorie e una consolidazione nel Top Ten per il 2025. Abbiamo lavorato per mantenere il focus sulla causa principale piuttosto che sui sintomi, per quanto possibile. Con la complessità dell'ingegneria del software e della sicurezza applicativa, è praticamente impossibile creare dieci categorie senza un certo livello di sovrapposizione. + +![Mapping](../assets/2025-mappings.png) + +* **[A01:2025 - Broken Access Control](A01_2025-Broken_Access_Control.md)** mantiene la sua posizione al #1 come rischio di sicurezza applicativa più grave; i dati contribuiti indicano che in media il 3,73% delle applicazioni testate presentava una o più delle 40 Common Weakness Enumeration (CWE) in questa categoria. Come indicato dalla linea tratteggiata nella figura sopra, la Server-Side Request Forgery (SSRF) è stata incorporata in questa categoria. +* **[A02:2025 - Security Misconfiguration](A02_2025-Security_Misconfiguration.md)** è salita dal #5 del 2021 al #2 nel 2025. Le configurazioni errate sono più prevalenti nei dati di questo ciclo. Il 3,00% delle applicazioni testate presentava una o più delle 16 CWE in questa categoria. Non sorprende, poiché l'ingegneria del software continua ad aumentare la quantità di comportamenti delle applicazioni basati su configurazioni. +* **[A03:2025 - Software Supply Chain Failures](A03_2025-Software_Supply_Chain_Failures.md)** è un'espansione di [A06:2021-Vulnerable and Outdated Components](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/) per includere una portata più ampia di compromissioni che si verificano all'interno o attraverso l'intero ecosistema di dipendenze software, sistemi di build e infrastrutture di distribuzione. Questa categoria è stata votata in modo schiacciante come principale preoccupazione nel sondaggio della community. Questa categoria ha 5 CWE e una presenza limitata nei dati raccolti, ma riteniamo che ciò sia dovuto alle difficoltà nel testing e speriamo che i metodi di testing raggiungano questo settore. Questa categoria ha il minor numero di occorrenze nei dati, ma anche i punteggi medi più alti per exploit e impatto tra i CVE. +* **[A04:2025 - Cryptographic Failures](A04_2025-Cryptographic_Failures.md)** scende di due posizioni dal #2 al #4 nella classifica. I dati contribuiti indicano che, in media, il 3,80% delle applicazioni presenta una o più delle 32 CWE in questa categoria. Questa categoria porta spesso a esposizione di dati sensibili o compromissione del sistema. +* **[A05:2025 - Injection](A05_2025-Injection.md)** scende di due posizioni dal #3 al #5 nella classifica, mantenendo la sua posizione relativa rispetto a Cryptographic Failures e Insecure Design. L'Injection è una delle categorie più testate, con il maggior numero di CVE associati alle 38 CWE in questa categoria. L'Injection include una gamma di problemi che va dalle vulnerabilità di Cross-site Scripting (alta frequenza/basso impatto) alla SQL Injection (bassa frequenza/alto impatto). +* **[A06:2025 - Insecure Design](A06_2025-Insecure_Design.md)** scende di due posizioni dal #4 al #6 nella classifica mentre Security Misconfiguration e Software Supply Chain Failures la superano. Questa categoria è stata introdotta nel 2021 e abbiamo registrato miglioramenti evidenti nel settore relativi al threat modeling e una maggiore enfasi sulla progettazione sicura. +* **[A07:2025 - Authentication Failures](A07_2025-Authentication_Failures.md)** mantiene la sua posizione al #7 con una leggera modifica del nome (in precedenza era "[Identification and Authentication Failures](https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/)") per riflettere più accuratamente le 36 CWE in questa categoria. Questa categoria rimane importante, ma il maggiore utilizzo di framework standardizzati per l'autenticazione sembra avere effetti benefici sulle occorrenze di fallimenti di autenticazione. +* **[A08:2025 - Software or Data Integrity Failures](A08_2025-Software_or_Data_Integrity_Failures.md)** continua all'#8 nella lista. Questa categoria si concentra sul fallimento nel mantenimento dei confini di fiducia e nella verifica dell'integrità di software, codice e artefatti dati a un livello inferiore rispetto ai Software Supply Chain Failures. +* **[A09:2025 - Security Logging & Alerting Failures](A09_2025-Security_Logging_and_Alerting_Failures.md)** mantiene la sua posizione al #9. Questa categoria ha una leggera modifica del nome (in precedenza [Security Logging and Monitoring Failures](https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/)) per enfatizzare l'importanza della funzionalità di alerting necessaria per indurre azioni appropriate sugli eventi di logging rilevanti. Un ottimo logging senza alerting è di valore minimo nell'identificazione degli incidenti di sicurezza. Questa categoria sarà sempre sottorappresentata nei dati ed è stata nuovamente votata in una posizione nella lista dai partecipanti al sondaggio della community. +* **[A10:2025 - Mishandling of Exceptional Conditions](A10_2025-Mishandling_of_Exceptional_Conditions.md)** è una nuova categoria per il 2025. Questa categoria contiene 24 CWE incentrate sulla gestione impropria degli errori, errori logici, "failing open" e altri scenari correlati derivanti da condizioni anomale che i sistemi possono incontrare. + + +## Metodologia + +Questa edizione del Top Ten rimane informata dai dati, ma non guidata ciecamente da essi. Abbiamo classificato 12 categorie in base ai dati contribuiti e ne abbiamo consentite due da promuovere o evidenziare dalle risposte del sondaggio della community. Lo facciamo per una ragione fondamentale: esaminare i dati contribuiti equivale essenzialmente a guardare nel passato. I ricercatori di Application Security dedicano tempo all'identificazione di nuove vulnerabilità e allo sviluppo di nuovi metodi di testing. Ci vogliono settimane o anni per integrare questi test in strumenti e processi. Nel momento in cui possiamo testare in modo affidabile una debolezza su larga scala, potrebbero essere passati anni. Ci sono anche rischi importanti che potremmo non essere mai in grado di testare in modo affidabile e che sono presenti nei dati. Per bilanciare questa visione, utilizziamo un sondaggio della community per chiedere ai professionisti di Application Security e sviluppatori in prima linea cosa considerano rischi essenziali che potrebbero essere sottorappresentati nei dati di testing. + + +## Come sono strutturate le categorie + +Alcune categorie sono cambiate rispetto alla precedente edizione dell'OWASP Top Ten. Ecco un riepilogo di alto livello delle modifiche alle categorie. + +In questa iterazione, abbiamo richiesto dati senza restrizioni sulle CWE come abbiamo fatto per l'edizione 2021. Abbiamo chiesto il numero di applicazioni testate per un determinato anno (a partire dal 2021) e il numero di applicazioni con almeno un'istanza di una CWE trovata nel testing. Questo formato ci consente di monitorare quanto sia prevalente ogni CWE all'interno della popolazione di applicazioni. Ignoriamo la frequenza ai nostri fini; sebbene possa essere necessaria in altre situazioni, nasconde solo la prevalenza effettiva nella popolazione di applicazioni. Che un'applicazione abbia quattro istanze di una CWE o 4.000 non fa parte del calcolo per il Top Ten. Specialmente perché i tester manuali tendono a elencare una vulnerabilità una sola volta, indipendentemente da quante volte si ripete in un'applicazione, mentre i framework di testing automatizzato elencano ogni istanza di una vulnerabilità come unica. Siamo passati da circa 30 CWE nel 2017, a quasi 400 CWE nel 2021, a 589 CWE in questa edizione da analizzare nel dataset. Prevediamo di effettuare ulteriori analisi dei dati come supplemento in futuro. Questo significativo aumento del numero di CWE richiede modifiche al modo in cui le categorie sono strutturate. + +Abbiamo trascorso diversi mesi a raggruppare e categorizzare le CWE e avremmo potuto continuare per mesi ulteriori. Ad un certo punto era necessario fermarsi. Esistono sia tipi di CWE legati alla causa principale che ai sintomi, dove i tipi di causa principale sono come "Cryptographic Failure" e "Misconfiguration" in contrasto con i tipi di sintomo come "Sensitive Data Exposure" e "Denial of Service". Abbiamo deciso di concentrarci sulla causa principale ogni volta che è possibile, in quanto è più logico per fornire indicazioni sull'identificazione e la rimediazione. Concentrarsi sulla causa principale anziché sul sintomo non è un concetto nuovo; il Top Ten è sempre stato un mix di sintomi e cause principali. Anche le CWE sono un mix di sintomi e cause principali; stiamo semplicemente essere più deliberati nel segnalarlo. C'è una media di 25 CWE per categoria in questa edizione, con il limite inferiore a 5 CWE per A03:2025-Software Supply Chain Failures e A09:2025 Security Logging and Alerting Failures fino a 40 CWE in A01:2025-Broken Access Control. Abbiamo deciso di limitare il numero di CWE in una categoria a 40. Questa struttura di categoria aggiornata offre ulteriori vantaggi formativi poiché le aziende possono concentrarsi sulle CWE che hanno senso per un determinato linguaggio/framework. + +Ci è stato chiesto perché non passare a una lista di 10 CWE come Top 10, simile alle MITRE Top 25 Most Dangerous Software Weaknesses. Ci sono due ragioni principali per cui utilizziamo più CWE nelle categorie. In primo luogo, non tutte le CWE esistono in tutti i linguaggi di programmazione o framework. Questo causa problemi per gli strumenti e i programmi di formazione/sensibilizzazione poiché parte del Top Ten potrebbe non essere applicabile. La seconda ragione è che esistono più CWE per le vulnerabilità comuni. Ad esempio, ci sono più CWE per Injection generale, Command Injection, Cross-site Scripting, Hardcoded Passwords, Lack of Validation, Buffer Overflow, Cleartext Storage of Sensitive Information e molti altri. A seconda dell'organizzazione o del tester, potrebbero essere utilizzate diverse CWE. Utilizzando una categoria con più CWE possiamo contribuire ad alzare il livello di base e la consapevolezza dei diversi tipi di debolezze che possono verificarsi sotto un nome di categoria comune. In questa edizione del Top Ten 2025, ci sono 248 CWE all'interno delle 10 categorie. Ci sono un totale di 968 CWE nel [dizionario scaricabile da MITRE](https://cwe.mitre.org) al momento di questa pubblicazione. + + +## Come vengono utilizzati i dati per selezionare le categorie + +Analogamente a quanto fatto per l'edizione 2021, abbiamo sfruttato i dati CVE per *Sfruttabilità* e *Impatto (Tecnico)*. Abbiamo scaricato OWASP Dependency Check ed estratto i punteggi CVSS di Exploit e Impact, raggruppandoli per CWE rilevanti elencate con i CVE. Ha richiesto una discreta quantità di ricerca e sforzo, poiché tutti i CVE hanno punteggi CVSSv2, ma ci sono difetti in CVSSv2 che CVSSv3 dovrebbe correggere. Dopo un certo punto nel tempo, a tutti i CVE viene assegnato anche un punteggio CVSSv3. Inoltre, gli intervalli di punteggio e le formule sono stati aggiornati tra CVSSv2 e CVSSv3. + +In CVSSv2, sia Exploit che Impatto (Tecnico) potevano arrivare fino a 10,0, ma la formula li abbassava al 60% per Exploit e al 40% per Impact. In CVSSv3, il massimo teorico era limitato a 6,0 per Exploit e 4,0 per Impact. Con la ponderazione considerata, il punteggio di Impact è aumentato, quasi un punto e mezzo in media in CVSSv3, e la sfruttabilità è diminuita di quasi mezzo punto in media. + +Ci sono circa 175k record (rispetto ai 125k del 2021) di CVE mappati a CWE nel National Vulnerability Database (NVD), estratti da OWASP Dependency Check. Inoltre, ci sono 643 CWE uniche mappate a CVE (rispetto alle 241 del 2021). Nell'ambito dei quasi 220k CVE estratti, 160k avevano punteggi CVSS v2, 156k avevano punteggi CVSS v3 e 6k avevano punteggi CVSS v4. Molti CVE hanno più punteggi, motivo per cui il totale supera i 220k. + +Per il Top Ten 2025, abbiamo calcolato i punteggi medi di exploit e impact nel modo seguente. Abbiamo raggruppato tutti i CVE con punteggi CVSS per CWE e ponderato sia i punteggi di exploit che di impact in base alla percentuale della popolazione che aveva CVSSv3, nonché alla popolazione rimanente con punteggi CVSSv2, per ottenere una media complessiva. Abbiamo mappato queste medie alle CWE nel dataset da utilizzare come punteggi di Exploit e Impatto (Tecnico) per l'altra metà dell'equazione del rischio. + +Perché non usare CVSS v4.0? Perché l'algoritmo di punteggio è stato modificato in modo sostanziale e non fornisce più facilmente i punteggi di *Exploit* o *Impact* come fanno CVSSv2 e CVSSv3. Tenteremo di trovare un modo per utilizzare il punteggio CVSS v4.0 nelle versioni future del Top Ten, ma non siamo riusciti a determinare un modo tempestivo per farlo per l'edizione 2025. + + +## Perché utilizziamo un sondaggio della community + +I risultati nei dati sono in gran parte limitati a ciò che il settore riesce a testare in modo automatizzato. Parlate con un professionista esperto di AppSec e vi parleranno di cose che trovano e tendenze che vedono che non sono ancora nei dati. Ci vuole tempo perché le persone sviluppino metodologie di testing per certi tipi di vulnerabilità e poi ancora più tempo perché quei test vengano automatizzati ed eseguiti su una vasta popolazione di applicazioni. Tutto ciò che troviamo guarda nel passato e potrebbe mancare le tendenze dell'ultimo anno, che non sono presenti nei dati. + +Per questo motivo, scegliamo solo otto delle dieci categorie dai dati perché sono incompleti. Le altre due categorie provengono dal sondaggio della community del Top 10. Permette ai professionisti in prima linea di votare per ciò che considerano i rischi più elevati che potrebbero non essere nei dati (e che potrebbero non essere mai espressi nei dati). + + +## Grazie ai nostri contributori di dati + +Le seguenti organizzazioni (insieme a diversi donatori anonimi) hanno gentilmente donato dati per oltre 2,8 milioni di applicazioni per rendere questo il dataset di sicurezza applicativa più grande e completo. Senza di voi, questo non sarebbe stato possibile. + +* Accenture (Praga) +* Anonimo (multipli) +* Bugcrowd +* Contrast Security +* CryptoNet Labs +* Intuitor SoftTech Services +* Orca Security +* Probely +* Semgrep +* Sonar +* usd AG +* Veracode +* Wallarm + +## Autori principali +* Andrew van der Stock - X: [@vanderaj](https://x.com/vanderaj) +* Brian Glas - X: [@infosecdad](https://x.com/infosecdad) +* Neil Smithline - X: [@appsecneil](https://x.com/appsecneil) +* Tanya Janca - X: [@shehackspurple](https://x.com/shehackspurple) +* Torsten Gigler - Mastodon: [@torsten_gigler@infosec.exchange](https://infosec.exchange/@torsten_gigler) + +## Segnala problemi e pull request + +Si prega di segnalare eventuali correzioni o problemi: + +### Link al progetto: +* [Homepage](https://owasp.org/www-project-top-ten/) +* [Repository GitHub](https://github.com/OWASP/Top10) diff --git a/2025/docs/it/0x01_2025-About_OWASP.md b/2025/docs/it/0x01_2025-About_OWASP.md new file mode 100644 index 000000000..e60a137b6 --- /dev/null +++ b/2025/docs/it/0x01_2025-About_OWASP.md @@ -0,0 +1,35 @@ +# Informazioni su OWASP + +L'Open Worldwide Application Security Project (OWASP) è una comunità aperta dedicata a supportare le organizzazioni nello sviluppo, nell'acquisto e nel mantenimento di applicazioni e API affidabili. + +Su OWASP troverai gratuitamente e in formato aperto: + +- Strumenti e standard per la sicurezza delle applicazioni +- Ricerca all'avanguardia +- Controlli di sicurezza standard e librerie +- Guide complete sul testing della sicurezza applicativa, sullo sviluppo sicuro del codice e sulla revisione del codice sicuro +- Presentazioni e [video](https://www.youtube.com/user/OWASPGLOBAL) +- [Cheat sheet](https://cheatsheetseries.owasp.org/) su molti argomenti comuni +- [Incontri dei capitoli](https://owasp.org/chapters/) in tutto il mondo e online +- [Eventi, formazione e conferenze](https://owasp.org/events/) +- [Google Groups](https://groups.google.com/g/owasp) + +Scopri di più su: [https://owasp.org](https://owasp.org). + +Tutti gli strumenti, i documenti, i video, le presentazioni e i capitoli OWASP sono gratuiti e aperti a chiunque voglia migliorare la sicurezza delle applicazioni. + +Sosteniamo un approccio alla sicurezza applicativa come problema di persone, processi e tecnologia, poiché gli approcci più efficaci richiedono miglioramenti in tutte queste aree. + +OWASP è un tipo diverso di organizzazione. La nostra indipendenza dalle pressioni commerciali ci permette di fornire informazioni imparziali, pratiche ed economicamente accessibili sulla sicurezza delle applicazioni. + +OWASP non è affiliata ad alcuna azienda tecnologica, pur supportando l'uso consapevole di tecnologie di sicurezza commerciali. OWASP produce molti tipi di materiali in modo collaborativo, trasparente e aperto. + +La OWASP Foundation è l'ente no-profit che garantisce il successo a lungo termine del progetto. Quasi tutte le persone coinvolte in OWASP sono volontarie, inclusi il consiglio di amministrazione, i responsabili dei capitoli, i responsabili dei progetti e i membri dei progetti. Supportiamo la ricerca innovativa sulla sicurezza attraverso sovvenzioni e infrastrutture. + +Unisciti a noi! + +## Copyright e Licenza + +![License](../assets/license.png) + +Copyright © 2003-2025 The OWASP® Foundation, Inc. Questo documento è rilasciato sotto la licenza Creative Commons Attribution Share-Alike 4.0. Per qualsiasi riutilizzo o distribuzione, è necessario rendere chiari agli altri i termini della licenza di questo lavoro. diff --git a/2025/docs/it/0x02_2025-What_are_Application_Security_Risks.md b/2025/docs/it/0x02_2025-What_are_Application_Security_Risks.md new file mode 100644 index 000000000..ee1577e75 --- /dev/null +++ b/2025/docs/it/0x02_2025-What_are_Application_Security_Risks.md @@ -0,0 +1,113 @@ +# Cosa sono i Rischi di Sicurezza delle Applicazioni? +Gli attaccanti possono potenzialmente sfruttare molti percorsi diversi attraverso la tua applicazione per danneggiare la tua azienda o organizzazione. Ognuno di questi percorsi rappresenta un potenziale rischio che deve essere esaminato. + +![Calculation diagram](../assets/2025-algorithm-diagram.png) + + + + + + + + + + + + + + + + + + +
+ Agenti di Minaccia + + Vettori di \ +Attacco + + Sfruttabilità + + Probabilità di Assenza di Controlli +

+ + di Sicurezza +

+ Impatti +

+ + Tecnici +

+ Impatti +

+ + sul Business +

+ In base all'ambiente, \ +dinamico in base alla situazione + + In base all'esposizione dell'applicazione (per ambiente) + + Exploit Medio Ponderato + + Controlli Mancanti \ +per tasso medio di incidenza \ +ponderato per copertura + + Impatto Medio Ponderato + + Per Business +
+ + +Nella nostra valutazione del rischio abbiamo tenuto conto dei parametri universali di sfruttabilità, probabilità media di assenza di controlli di sicurezza per una debolezza e i suoi impatti tecnici. + +Ogni organizzazione è unica, e così lo sono gli attori delle minacce per quella organizzazione, i loro obiettivi e l'impatto di qualsiasi violazione. Se un'organizzazione di interesse pubblico utilizza un sistema di gestione dei contenuti (CMS) per informazioni pubbliche e un sistema sanitario utilizza lo stesso identico CMS per cartelle cliniche sensibili, gli attori delle minacce e gli impatti sul business possono essere molto diversi per lo stesso software. È fondamentale comprendere il rischio per la propria organizzazione in base all'esposizione dell'applicazione, agli agenti di minaccia applicabili per situazione (per attacchi mirati e non diretti per business e ubicazione) e agli impatti individuali sul business. + + +## Come vengono utilizzati i dati per selezionare le categorie e classificarle + +Nel 2017 abbiamo selezionato le categorie in base al tasso di incidenza per determinare la probabilità, e poi le abbiamo classificate tramite discussione del team basata su decenni di esperienza per Sfruttabilità, Rilevabilità (anche probabilità) e Impatto Tecnico. Per il 2021 abbiamo utilizzato dati per Sfruttabilità e Impatto (Tecnico) dai punteggi CVSSv2 e CVSSv3 nel National Vulnerability Database (NVD). Per il 2025 abbiamo continuato la stessa metodologia creata nel 2021. + +Abbiamo scaricato OWASP Dependency Check ed estratto i punteggi CVSS di Exploit e Impact raggruppati per CWE correlate. Ha richiesto una discreta ricerca e sforzo poiché tutti i CVE hanno punteggi CVSSv2, ma ci sono difetti in CVSSv2 che CVSSv3 dovrebbe correggere. Dopo un certo punto nel tempo, a tutti i CVE viene assegnato anche un punteggio CVSSv3. Inoltre, gli intervalli di punteggio e le formule sono stati aggiornati tra CVSSv2 e CVSSv3. + +In CVSSv2, sia Exploit che Impatto (Tecnico) potevano arrivare fino a 10,0, ma la formula li abbassava al 60% per Exploit e al 40% per Impact. In CVSSv3, il massimo teorico era limitato a 6,0 per Exploit e 4,0 per Impact. Con la ponderazione considerata, il punteggio di Impact è aumentato, quasi un punto e mezzo in media in CVSSv3, e la sfruttabilità è diminuita di quasi mezzo punto in media quando abbiamo condotto l'analisi per il Top Ten 2021. + +Ci sono circa 175k record (rispetto ai 125k del 2021) di CVE mappati a CWE nel National Vulnerability Database (NVD), estratti da OWASP Dependency Check. Inoltre, ci sono 643 CWE uniche mappate a CVE (rispetto alle 241 del 2021). Nell'ambito dei quasi 220k CVE estratti, 160k avevano punteggi CVSS v2, 156k avevano punteggi CVSS v3 e 6k avevano punteggi CVSS v4. Molti CVE hanno più punteggi, motivo per cui il totale supera i 220k. + +Per il Top Ten 2025 abbiamo calcolato i punteggi medi di exploit e impact raggruppando tutti i CVE con punteggi CVSS per CWE e ponderando entrambi i punteggi in base alla percentuale della popolazione con CVSSv3 e alla restante popolazione con CVSSv2, ottenendo una media complessiva. Abbiamo mappato queste medie alle CWE nel dataset da usare come punteggi di Exploit e Impatto (Tecnico) per l'altra metà dell'equazione del rischio. + +Perché non usare CVSS v4.0? Perché l'algoritmo di punteggio è stato modificato in modo sostanziale e non fornisce più facilmente i punteggi di *Exploit* o *Impact* come fanno CVSSv2 e CVSSv3. Tenteremo di trovare un modo per utilizzare il punteggio CVSS v4.0 nelle versioni future del Top Ten, ma non siamo riusciti a determinare un modo tempestivo per farlo per l'edizione 2025. + +Per il tasso di incidenza abbiamo calcolato la percentuale di applicazioni vulnerabili a ciascuna CWE dalla popolazione testata da un'organizzazione per un determinato periodo. Come promemoria, non utilizziamo la frequenza (ovvero quante volte un problema appare in un'applicazione), ma siamo interessati a quale percentuale della popolazione di applicazioni è risultata avere ciascuna CWE. + +Per la copertura guardiamo la percentuale di applicazioni testate da tutte le organizzazioni per una determinata CWE. Maggiore è la copertura calcolata, più forte è la garanzia che il tasso di incidenza sia accurato poiché la dimensione del campione è più rappresentativa della popolazione. + +La formula che abbiamo utilizzato per questa iterazione è simile a quella del 2021, con alcune modifiche alla ponderazione: +(Tasso Massimo di Incidenza % * 1000) + (Copertura Massima % * 100) + (Exploit Medio * 10) + (Impatto Medio * 20) + (Totale Occorrenze / 10000) = Punteggio di Rischio + +I punteggi calcolati variavano da 621,60 per la categoria Broken Access Control a 271,08 per Memory Management Errors. + +Non è un sistema perfetto, ma è utile per classificare le categorie di rischio. + +Una sfida aggiuntiva in crescita è la definizione di "applicazione". Con lo spostamento del settore verso architetture diverse composte da micro-servizi e altre implementazioni più piccole di un'applicazione tradizionale, i calcoli diventano più difficili. Ad esempio, se un'organizzazione sta testando repository di codice, cosa considera un'applicazione? Analogamente alla crescita di CVSSv4, la prossima edizione del Top Ten potrebbe dover adeguare l'analisi e il punteggio per tenere conto di un settore in costante evoluzione. + +## Fattori dei dati + +Ci sono fattori dei dati elencati per ciascuna delle categorie del Top Ten, ecco cosa significano: + +**CWE Mappate:** Il numero di CWE mappate a una categoria dal team del Top Ten. + +**Tasso di Incidenza:** Il tasso di incidenza è la percentuale di applicazioni vulnerabili a quella CWE dalla popolazione testata dall'organizzazione per quell'anno. + +**Exploit Ponderato:** Il sotto-punteggio Exploit dai punteggi CVSSv2 e CVSSv3 assegnati ai CVE mappati alle CWE, normalizzato e posto su una scala a 10 punti. + +**Impatto Ponderato:** Il sotto-punteggio Impact dai punteggi CVSSv2 e CVSSv3 assegnati ai CVE mappati alle CWE, normalizzato e posto su una scala a 10 punti. + +**Copertura (Testing):** La percentuale di applicazioni testate da tutte le organizzazioni per una determinata CWE. + +**Totale Occorrenze:** Numero totale di applicazioni in cui sono state trovate le CWE mappate a una categoria. + +**Totale CVE:** Numero totale di CVE nel DB NVD mappati alle CWE di una categoria. + +**Formula:** (Tasso Massimo di Incidenza % * 1000) + (Copertura Massima % * 100) + (Exploit Medio * 10) + (Impatto Medio * 20) + (Totale Occorrenze / 10000) = Punteggio di Rischio diff --git a/2025/docs/it/0x03_2025-Establishing_a_Modern_Application_Security_Program.md b/2025/docs/it/0x03_2025-Establishing_a_Modern_Application_Security_Program.md new file mode 100644 index 000000000..67e16e2d2 --- /dev/null +++ b/2025/docs/it/0x03_2025-Establishing_a_Modern_Application_Security_Program.md @@ -0,0 +1,301 @@ +# Stabilire un Programma Moderno di Sicurezza Applicativa + +Le liste OWASP Top Ten sono documenti di sensibilizzazione, pensati per portare attenzione sui rischi più critici di qualsiasi argomento trattino. Non sono pensate come lista completa, ma solo come punto di partenza. Nelle versioni precedenti di questa lista abbiamo prescritto l'avvio di un programma di sicurezza applicativa come il modo migliore per evitare questi rischi e altro ancora. In questa sezione tratteremo come avviare e costruire un programma moderno di sicurezza applicativa. + +Se hai già un programma di sicurezza applicativa, considera di eseguire una valutazione della maturità utilizzando [OWASP SAMM (Software Assurance Maturity Model)](https://owasp.org/www-project-samm/) o DSOMM (DevSecOps Maturity Model). Questi modelli di maturità sono completi ed esaustivi e possono essere utilizzati per aiutarti a capire dove dovresti concentrare al meglio i tuoi sforzi per espandere e maturare il tuo programma. Nota: non devi fare tutto ciò che è in OWASP SAMM o DSOMM per svolgere un buon lavoro; sono pensati per guidarti e offrire molte opzioni. Non sono pensati per offrire standard irraggiungibili o descrivere programmi inaccessibili. Sono ampi per offrirti molte idee e opzioni. + +Se stai iniziando un programma da zero, o se trovi OWASP SAMM o DSOMM "troppo" per il tuo team al momento, ti preghiamo di rivedere i seguenti consigli. + + +### 1. Stabilire un Approccio al Portfolio Basato sul Rischio: + +* Identificare le esigenze di protezione del portfolio applicativo da una prospettiva aziendale. Questo dovrebbe essere guidato in parte dalle leggi sulla privacy e da altre normative pertinenti all'asset di dati da proteggere. + +* Stabilire un [modello comune di valutazione del rischio](https://owasp.org/www-community/OWASP_Risk_Rating_Methodology) con un insieme coerente di fattori di probabilità e impatto che rifletta la tolleranza al rischio dell'organizzazione. + +* Misurare e dare priorità di conseguenza a tutte le applicazioni e API. Aggiungere i risultati al proprio [Configuration Management Database (CMDB)](https://de.wikipedia.org/wiki/Configuration_Management_Database). + +* Stabilire linee guida di assurance per definire correttamente la copertura e il livello di rigore richiesto. + + +### 2. Abilitare con una Base Solida: + +* Stabilire un insieme di policy e standard mirati che forniscano una baseline di sicurezza applicativa a cui tutti i team di sviluppo devono aderire. + +* Definire un insieme comune di controlli di sicurezza riutilizzabili che complementino queste policy e standard e forniscano indicazioni di progettazione e sviluppo sul loro utilizzo. + +* Stabilire un curriculum di formazione sulla sicurezza applicativa che sia obbligatorio e mirato a diversi ruoli di sviluppo e argomenti. + + +### 3. Integrare la Sicurezza nei Processi Esistenti: + +* Definire e integrare attività di implementazione e verifica sicura nei processi di sviluppo e operativi esistenti. + +* Le attività includono threat modeling, progettazione sicura e revisione del design, codifica sicura e code review, penetration testing e remediation. + +* Fornire esperti in materia e servizi di supporto ai team di sviluppo e di progetto per avere successo. + +* Rivedere il ciclo di vita dello sviluppo del sistema attuale e tutte le attività di sicurezza del software, strumenti, policy e processi, quindi documentarli. + +* Per il nuovo software, aggiungere una o più attività di sicurezza a ogni fase del ciclo di vita dello sviluppo del sistema (SDLC). Di seguito offriamo molti suggerimenti su cosa è possibile fare. Assicurarsi di eseguire queste nuove attività su ogni nuovo progetto o iniziativa software, in modo da sapere che ogni nuovo software sarà consegnato con una postura di sicurezza accettabile per la propria organizzazione. + +* Selezionare le attività per garantire che il prodotto finale soddisfi un livello di rischio accettabile per l'organizzazione. + +* Per il software esistente (a volte chiamato legacy) è necessario avere un piano di manutenzione formale; consultare di seguito le idee su come mantenere le applicazioni sicure nella sezione "Operazioni e Gestione dei Cambiamenti". + + +### 4. Formazione sulla Sicurezza Applicativa: + +* Considerare di avviare un programma di security champion, o un programma generale di formazione sulla sicurezza per gli sviluppatori (a volte chiamato programma di advocacy o di sensibilizzazione alla sicurezza), per insegnare loro tutto ciò che si vorrebbe che sapessero. Questo li terrà aggiornati, li aiuterà a sapere come svolgere il loro lavoro in modo sicuro e renderà più positiva la cultura della sicurezza nel luogo di lavoro. Spesso migliora anche la fiducia tra i team e crea un rapporto di lavoro più sereno. OWASP ti supporta in questo con la [OWASP Security Champions Guide](https://securitychampions.owasp.org/), che viene ampliata passo dopo passo. + +* Il Progetto OWASP Education fornisce materiali di formazione per aiutare a educare gli sviluppatori sulla sicurezza delle applicazioni web. Per l'apprendimento pratico sulle vulnerabilità, provare [OWASP Juice Shop Project](https://owasp.org/www-project-juice-shop/), o [OWASP WebGoat](https://owasp.org/www-project-webgoat/). Per rimanere aggiornati, partecipare a una [Conferenza OWASP AppSec](https://owasp.org/events/), a [OWASP Conference Training](https://owasp.org/events/), o alle riunioni del [capitolo OWASP](https://owasp.org/chapters/) locale. + + +### 5. Fornire Visibilità al Management: + +* Gestire con le metriche. Guidare le decisioni di miglioramento e finanziamento basandosi sulle metriche e sui dati di analisi raccolti. Le metriche includono l'aderenza alle pratiche e alle attività di sicurezza, le vulnerabilità introdotte, le vulnerabilità mitigate, la copertura delle applicazioni, la densità dei difetti per tipo e conteggi delle istanze, ecc. + +* Analizzare i dati delle attività di implementazione e verifica per cercare la causa radice e i pattern di vulnerabilità per guidare miglioramenti strategici e sistemici nell'intera azienda. Imparare dagli errori e offrire incentivi positivi per promuovere i miglioramenti. + + + +## Stabilire e Utilizzare Processi di Sicurezza Ripetibili e Controlli di Sicurezza Standard + +### Fase di Gestione dei Requisiti e delle Risorse: + +* Raccogliere e negoziare i requisiti aziendali per un'applicazione con il business, inclusi i requisiti di protezione per quanto riguarda la riservatezza, l'autenticità, l'integrità e la disponibilità di tutti gli asset di dati, e la logica di business prevista. + +* Compilare i requisiti tecnici inclusi i requisiti di sicurezza funzionali e non funzionali. OWASP raccomanda di utilizzare l'[OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/) come guida per definire i requisiti di sicurezza per le proprie applicazioni. + +* Pianificare e negoziare il budget che copre tutti gli aspetti di progettazione, costruzione, test e operazioni, incluse le attività di sicurezza. + +* Aggiungere le attività di sicurezza al proprio calendario di progetto. + +* Presentarsi come rappresentante della sicurezza al kick-off del progetto, in modo che sappiano con chi parlare. + + +### Richieste di Offerta (RFP) e Contrattualizzazione: + +* Negoziare i requisiti con sviluppatori interni o esterni, incluse linee guida e requisiti di sicurezza rispetto al proprio programma di sicurezza, ad esempio SDLC, best practice. + +* Valutare il soddisfacimento di tutti i requisiti tecnici, inclusa una fase di pianificazione e progettazione. + +* Negoziare tutti i requisiti tecnici, inclusi progettazione, sicurezza e service level agreement (SLA). + +* Adottare template e checklist, come [OWASP Secure Software Contract Annex](https://owasp.org/www-community/OWASP_Secure_Software_Contract_Annex).
**Nota:** *L'annex è per la legge contrattuale statunitense, quindi si prega di consultare un consulente legale qualificato prima di utilizzare l'annex di esempio.* + + +### Fase di Pianificazione e Progettazione: + +* Negoziare la pianificazione e la progettazione con gli sviluppatori e gli stakeholder interni, ad esempio gli specialisti di sicurezza. + +* Definire l'architettura di sicurezza, i controlli, le contromisure e le revisioni del design appropriate alle esigenze di protezione e al livello di minaccia previsto. Questo dovrebbe essere supportato dagli specialisti di sicurezza. + +* Piuttosto che inserire la sicurezza retroattivamente nelle applicazioni e nelle API, è molto più conveniente progettare la sicurezza fin dall'inizio. OWASP raccomanda le [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/index.html) e i [OWASP Proactive Controls](https://top10proactive.owasp.org/) come buon punto di partenza per le indicazioni su come progettare la sicurezza inclusa fin dall'inizio. + +* Eseguire il threat modeling, vedere [OWASP Cheat Sheet: Threat Modeling](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html). + +* Insegnare agli architetti software i concetti e i pattern di progettazione sicura e chiedere loro di aggiungerli ai loro design ove possibile. + +* Esaminare i flussi di dati con gli sviluppatori. + +* Aggiungere user story di sicurezza accanto a tutte le altre user story. + + +### Secure Development Lifecycle: + +* Per migliorare il processo che la propria organizzazione segue nella costruzione di applicazioni e API, OWASP raccomanda l'[OWASP Software Assurance Maturity Model (SAMM)](https://owasp.org/www-project-samm/). Questo modello aiuta le organizzazioni a formulare e implementare una strategia per la sicurezza del software su misura per i rischi specifici che affrontano. + +* Fornire formazione sulla codifica sicura agli sviluppatori software, e qualsiasi altra formazione che si ritiene possa aiutarli a creare applicazioni più robuste e sicure. + +* Code review, vedere [OWASP Cheat Sheet: Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html). + +* Fornire agli sviluppatori strumenti di sicurezza, poi insegnare loro come usarli, in particolare analisi statica, analisi della composizione del software, secret scanner e scanner [Infrastructure-as-Code (IaC)](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html). + +* Creare guardrail per gli sviluppatori, se possibile (salvaguardie tecniche per orientarli verso scelte più sicure). + +* Costruire controlli di sicurezza forti e utilizzabili è difficile. Offrire default sicuri quando possibile, e creare "strade asfaltate" (rendendo il modo più semplice anche il modo più sicuro per fare qualcosa, il modo preferito ovvio) quando possibile. Le [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/index.html) sono un buon punto di partenza per gli sviluppatori, e molti framework moderni ora includono controlli di sicurezza standard ed efficaci per autorizzazione, validazione, prevenzione CSRF, ecc. + +* Fornire agli sviluppatori plugin IDE relativi alla sicurezza e incoraggiarli a utilizzarli. + +* Fornire loro uno strumento di gestione dei segreti, licenze e documentazione su come utilizzarlo. + +* Fornire loro un'AI privata da utilizzare, idealmente configurata con un server RAG pieno di documentazione di sicurezza utile, prompt scritti dal team per risultati migliori e un server MCP che chiama gli strumenti di sicurezza preferiti dell'organizzazione. Insegnare loro come usare l'AI in modo sicuro, perché lo faranno comunque. + + +### Stabilire Test Continui di Sicurezza Applicativa: + +* Testare le funzioni tecniche e l'integrazione con l'architettura IT e coordinare i test aziendali. + +* Creare casi di test "use" e "abuse" da prospettive tecniche e aziendali. + +* Gestire i test di sicurezza in base ai processi interni, alle esigenze di protezione e al livello di minaccia presunto dell'applicazione. + +* Fornire strumenti di test della sicurezza (fuzzer, DAST, ecc.), un luogo sicuro per testare e formazione su come usarli, OPPURE eseguire i test per loro OPPURE assumere un tester. + +* Se si richiede un alto livello di assurance, considerare un penetration test formale, nonché stress testing e performance testing. + +* Lavorare con gli sviluppatori per aiutarli a decidere cosa devono correggere dai bug report e garantire che i loro manager concedano loro il tempo per farlo. + + +### Rollout: + +* Mettere in funzione l'applicazione e migrare dalle applicazioni precedentemente utilizzate se necessario. + +* Finalizzare tutta la documentazione, incluso il change management database (CMDB) e l'architettura di sicurezza. + + +### Operazioni e Gestione dei Cambiamenti: + +* Le operazioni devono includere linee guida per la gestione della sicurezza dell'applicazione (ad esempio, patch management). + +* Aumentare la consapevolezza della sicurezza degli utenti e gestire i conflitti tra usabilità e sicurezza. + +* Pianificare e gestire i cambiamenti, ad esempio migrare a nuove versioni dell'applicazione o di altri componenti come OS, middleware e librerie. + +* Assicurarsi che tutte le app siano nell'inventario, con tutti i dettagli importanti documentati. Aggiornare tutta la documentazione, incluso il CMDB e l'architettura di sicurezza, i controlli e le contromisure, inclusi eventuali runbook o documentazione di progetto. + +* Eseguire logging, monitoraggio e alerting per tutte le app. Aggiungerlo se manca. + +* Creare processi per aggiornamenti e patch efficaci ed efficienti. + +* Creare calendari di scansione regolari (idealmente dinamica, statica, segreti, IaC e analisi della composizione del software). + +* SLA per la correzione dei bug di sicurezza. + +* Fornire un modo per i dipendenti (e idealmente anche per i clienti) di segnalare bug. + +* Stabilire un team di risposta agli incidenti addestrato che comprenda come appaiono gli attacchi e gli incidenti software, strumenti di osservabilità. + +* Eseguire strumenti di blocco o protezione per fermare gli attacchi automatizzati. + +* Hardening annuale (o più frequente) delle configurazioni. + +* Penetration testing almeno annuale (a seconda del livello di assurance richiesto per la propria app). + +* Stabilire processi e strumenti per l'hardening e la protezione della supply chain software. + +* Stabilire e aggiornare la pianificazione della continuità operativa e del disaster recovery che includa le applicazioni più importanti e gli strumenti utilizzati per mantenerle. + + +### Dismissione dei Sistemi: + +* Tutti i dati richiesti devono essere archiviati. Tutti gli altri dati devono essere eliminati in modo sicuro. + +* Dismettere in modo sicuro l'applicazione, inclusa l'eliminazione di account, ruoli e permessi non utilizzati. + +* Impostare lo stato dell'applicazione su "dismesso" nel CMDB. + + +## Utilizzo dell'OWASP Top 10 come Standard + +L'OWASP Top 10 è principalmente un documento di sensibilizzazione. Tuttavia, questo non ha impedito alle organizzazioni di utilizzarlo come standard AppSec del settore de facto dalla sua nascita nel 2003. Se si desidera utilizzare l'OWASP Top 10 come standard di codifica o test, è bene sapere che è il minimo assoluto e solo un punto di partenza. + +Una delle difficoltà nell'utilizzare l'OWASP Top 10 come standard è che documentiamo i rischi AppSec e non necessariamente problemi facilmente testabili. Ad esempio, [A06:2025-Insecure Design](A06_2025-Insecure_Design.md) va oltre la portata della maggior parte delle forme di testing. Un altro esempio è testare se il logging e il monitoraggio in atto, in uso ed efficaci sono implementati, il che può essere fatto solo con interviste e richiedendo un campionamento di risposte agli incidenti efficaci. Uno strumento di analisi statica del codice può cercare l'assenza di logging, ma potrebbe essere impossibile determinare se la logica di business o il controllo degli accessi stia registrando violazioni critiche della sicurezza. I penetration tester potrebbero essere in grado solo di determinare che hanno invocato la risposta agli incidenti in un ambiente di test, che viene raramente monitorato allo stesso modo della produzione. + +Ecco le nostre raccomandazioni su quando è appropriato utilizzare l'OWASP Top 10: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Caso d'Uso + OWASP Top 10 2025 + OWASP Application Security Verification Standard +
Sensibilizzazione + Sì + +
Formazione + Livello base + Completo +
Progettazione e architettura + Occasionalmente + Sì +
Standard di codifica + Minimo indispensabile + Sì +
Secure Code review + Minimo indispensabile + Sì +
Checklist di peer review + Minimo indispensabile + Sì +
Unit testing + Occasionalmente + Sì +
Integration testing + Occasionalmente + Sì +
Penetration testing + Minimo indispensabile + Sì +
Supporto degli strumenti + Minimo indispensabile + Sì +
Secure Supply Chain + Occasionalmente + Sì +
+ + +Incoraggiamo chiunque voglia adottare uno standard di sicurezza applicativa a utilizzare l'[OWASP Application Security Verification Standard](https://owasp.org/www-project-application-security-verification-standard/) (ASVS), poiché è progettato per essere verificabile e testato, e può essere utilizzato in tutte le parti di un ciclo di sviluppo sicuro. + +L'ASVS è l'unica scelta accettabile per i vendor di strumenti. Gli strumenti non possono rilevare, testare o proteggere in modo completo contro l'OWASP Top 10 a causa della natura di alcuni dei rischi dell'OWASP Top 10, con riferimento a [A06:2025-Insecure Design](A06_2025-Insecure_Design.md). OWASP scoraggia qualsiasi affermazione di copertura completa dell'OWASP Top 10, perché è semplicemente non vera. diff --git a/2025/docs/it/A01_2025-Broken_Access_Control.md b/2025/docs/it/A01_2025-Broken_Access_Control.md new file mode 100644 index 000000000..d50f614f2 --- /dev/null +++ b/2025/docs/it/A01_2025-Broken_Access_Control.md @@ -0,0 +1,185 @@ +# A01:2025 Broken Access Control ![icon](../assets/TOP_10_Icons_Final_Broken_Access_Control.png){: style="height:80px;width:80px" align="right"} + + + +## Contesto. + +Mantenendo la sua posizione al #1 nel Top Ten, il 100% delle applicazioni testate è risultato avere qualche forma di broken access control. Tra le CWE degne di nota vi sono *CWE-200: Exposure of Sensitive Information to an Unauthorized Actor*, *CWE-201: Exposure of Sensitive Information Through Sent Data*, *CWE-918 Server-Side Request Forgery (SSRF)* e *CWE-352: Cross-Site Request Forgery (CSRF)*. Questa categoria ha il maggior numero di occorrenze nei dati contribuiti e il secondo più alto numero di CVE correlati. + + +## 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 +
40 + 20,15% + 3,74% + 100,00% + 42,93% + 7,04 + 3,84 + 1.839.701 + 32.654 +
+ + + +## Descrizione. + +Il controllo degli accessi applica policy tali per cui gli utenti non possono agire al di fuori dei propri permessi previsti. I fallimenti portano tipicamente a divulgazione non autorizzata di informazioni, modifica o distruzione di tutti i dati, o all'esecuzione di una funzione di business al di fuori dei limiti dell'utente. Le vulnerabilità comuni di controllo degli accessi includono: + + + +* Violazione del principio del minimo privilegio, comunemente noto come deny by default, dove l'accesso dovrebbe essere concesso solo per determinate capacità, ruoli o utenti, ma è disponibile a chiunque. +* Aggiramento dei controlli di accesso modificando l'URL (parameter tampering o force browsing), lo stato interno dell'applicazione o la pagina HTML, oppure utilizzando uno strumento di attacco che modifica le richieste API. +* Permettere la visualizzazione o la modifica dell'account di qualcun altro fornendo il suo identificatore univoco (insecure direct object references). +* Un'API accessibile con controlli di accesso mancanti per POST, PUT e DELETE. +* Escalation di privilegi. Agire come utente senza essere autenticati o acquisire privilegi superiori a quelli previsti per l'utente autenticato (es. accesso admin). +* Manipolazione dei metadati, come il replay o la manomissione di un token di controllo degli accessi JSON Web Token (JWT), un cookie o un campo nascosto manipolato per elevare i privilegi, o l'abuso dell'invalidazione JWT. +* La configurazione errata di CORS consente l'accesso alle API da origini non autorizzate o non attendibili. +* Force browsing (indovinare URL) verso pagine autenticate come utente non autenticato o verso pagine privilegiate come utente standard. + + +## Come prevenire. + +Il controllo degli accessi è efficace solo se implementato in codice lato server attendibile o in API serverless, dove l'attaccante non può modificare il controllo degli accessi o i metadati. + + + +* Tranne per le risorse pubbliche, negare l'accesso per default. +* Implementare i meccanismi di controllo degli accessi una sola volta e riutilizzarli in tutta l'applicazione, inclusa la minimizzazione dell'utilizzo del Cross-Origin Resource Sharing (CORS). +* I modelli di controllo degli accessi devono applicare la proprietà dei record piuttosto che consentire agli utenti di creare, leggere, aggiornare o eliminare qualsiasi record. +* I requisiti di limite di business univoci dell'applicazione devono essere applicati dai modelli di dominio. +* Disabilitare il directory listing del web server e garantire che i metadati dei file (es. .git) e i file di backup non siano presenti nelle web root. +* Registrare i fallimenti del controllo degli accessi, inviare alert agli amministratori quando appropriato (es. fallimenti ripetuti). +* Implementare limiti di frequenza sull'accesso ad API e controller per minimizzare i danni degli strumenti di attacco automatizzati. +* Gli identificatori di sessione con stato devono essere invalidati sul server dopo il logout. I token JWT senza stato devono avere una durata breve per minimizzare la finestra di opportunità per un attaccante. Per JWT con durata più lunga, considerare l'uso di refresh token e seguire gli standard OAuth per revocare l'accesso. +* Utilizzare toolkit o pattern ben consolidati che forniscono controlli degli accessi semplici e dichiarativi. + +Gli sviluppatori e il personale QA devono includere test funzionali del controllo degli accessi nei test unitari e di integrazione. + + +## Scenari di attacco di esempio. + +**Scenario #1:** L'applicazione utilizza dati non verificati in una chiamata SQL che accede alle informazioni dell'account: + + +``` +pstmt.setString(1, request.getParameter("acct")); +ResultSet results = pstmt.executeQuery( ); +``` + + +Un attaccante può semplicemente modificare il parametro 'acct' del browser per inviare qualsiasi numero di account desiderato. Se non verificato correttamente, l'attaccante può accedere all'account di qualsiasi utente. + + +``` +https://example.com/app/accountInfo?acct=notmyacct +``` + + +**Scenario #2:** Un attaccante costringe semplicemente il browser a puntare a URL specifici. Sono necessari i diritti di amministratore per accedere alla pagina di amministrazione. + + +``` +https://example.com/app/getappInfo +https://example.com/app/admin_getappInfo +``` + + +Se un utente non autenticato può accedere a una delle due pagine, si tratta di una falla. Se un non-amministratore può accedere alla pagina di amministrazione, si tratta di una falla. + +**Scenario #3:** Un'applicazione gestisce tutto il controllo degli accessi nel front-end. Sebbene l'attaccante non riesca ad accedere a `https://example.com/app/admin_getappInfo` a causa del codice JavaScript in esecuzione nel browser, può semplicemente eseguire: + + +``` +$ curl https://example.com/app/admin_getappInfo +``` + + +dalla riga di comando. + + +## Riferimenti. + +* [OWASP Proactive Controls: C1: Implement Access Control](https://top10proactive.owasp.org/archive/2024/the-top-10/c1-accesscontrol/) +* [OWASP Application Security Verification Standard: V8 Authorization](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x17-V8-Authorization.md) +* [OWASP Testing Guide: Authorization Testing](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/README) +* [OWASP Cheat Sheet: Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) +* [PortSwigger: Exploiting CORS misconfiguration](https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties) +* [OAuth: Revoking Access](https://www.oauth.com/oauth2-servers/listing-authorizations/revoking-access/) + + +## Lista delle CWE Mappate + +* [CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')](https://cwe.mitre.org/data/definitions/22.html) +* [CWE-23 Relative Path Traversal](https://cwe.mitre.org/data/definitions/23.html) +* [CWE-36 Absolute Path Traversal](https://cwe.mitre.org/data/definitions/36.html) +* [CWE-59 Improper Link Resolution Before File Access ('Link Following')](https://cwe.mitre.org/data/definitions/59.html) +* [CWE-61 UNIX Symbolic Link (Symlink) Following](https://cwe.mitre.org/data/definitions/61.html) +* [CWE-65 Windows Hard Link](https://cwe.mitre.org/data/definitions/65.html) +* [CWE-200 Exposure of Sensitive Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/200.html) +* [CWE-201 Exposure of Sensitive Information Through Sent Data](https://cwe.mitre.org/data/definitions/201.html) +* [CWE-219 Storage of File with Sensitive Data Under Web Root](https://cwe.mitre.org/data/definitions/219.html) +* [CWE-276 Incorrect Default Permissions](https://cwe.mitre.org/data/definitions/276.html) +* [CWE-281 Improper Preservation of Permissions](https://cwe.mitre.org/data/definitions/281.html) +* [CWE-282 Improper Ownership Management](https://cwe.mitre.org/data/definitions/282.html) +* [CWE-283 Unverified Ownership](https://cwe.mitre.org/data/definitions/283.html) +* [CWE-284 Improper Access Control](https://cwe.mitre.org/data/definitions/284.html) +* [CWE-285 Improper Authorization](https://cwe.mitre.org/data/definitions/285.html) +* [CWE-352 Cross-Site Request Forgery (CSRF)](https://cwe.mitre.org/data/definitions/352.html) +* [CWE-359 Exposure of Private Personal Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/359.html) +* [CWE-377 Insecure Temporary File](https://cwe.mitre.org/data/definitions/377.html) +* [CWE-379 Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) +* [CWE-402 Transmission of Private Resources into a New Sphere ('Resource Leak')](https://cwe.mitre.org/data/definitions/402.html) +* [CWE-424 Improper Protection of Alternate Path](https://cwe.mitre.org/data/definitions/424.html) +* [CWE-425 Direct Request ('Forced Browsing')](https://cwe.mitre.org/data/definitions/425.html) +* [CWE-441 Unintended Proxy or Intermediary ('Confused Deputy')](https://cwe.mitre.org/data/definitions/441.html) +* [CWE-497 Exposure of Sensitive System Information to an Unauthorized Control Sphere](https://cwe.mitre.org/data/definitions/497.html) +* [CWE-538 Insertion of Sensitive Information into Externally-Accessible File or Directory](https://cwe.mitre.org/data/definitions/538.html) +* [CWE-540 Inclusion of Sensitive Information in Source Code](https://cwe.mitre.org/data/definitions/540.html) +* [CWE-548 Exposure of Information Through Directory Listing](https://cwe.mitre.org/data/definitions/548.html) +* [CWE-552 Files or Directories Accessible to External Parties](https://cwe.mitre.org/data/definitions/552.html) +* [CWE-566 Authorization Bypass Through User-Controlled SQL Primary Key](https://cwe.mitre.org/data/definitions/566.html) +* [CWE-601 URL Redirection to Untrusted Site ('Open Redirect')](https://cwe.mitre.org/data/definitions/601.html) +* [CWE-615 Inclusion of Sensitive Information in Source Code Comments](https://cwe.mitre.org/data/definitions/615.html) +* [CWE-639 Authorization Bypass Through User-Controlled Key](https://cwe.mitre.org/data/definitions/639.html) +* [CWE-668 Exposure of Resource to Wrong Sphere](https://cwe.mitre.org/data/definitions/668.html) +* [CWE-732 Incorrect Permission Assignment for Critical Resource](https://cwe.mitre.org/data/definitions/732.html) +* [CWE-749 Exposed Dangerous Method or Function](https://cwe.mitre.org/data/definitions/749.html) +* [CWE-862 Missing Authorization](https://cwe.mitre.org/data/definitions/862.html) +* [CWE-863 Incorrect Authorization](https://cwe.mitre.org/data/definitions/863.html) +* [CWE-918 Server-Side Request Forgery (SSRF)](https://cwe.mitre.org/data/definitions/918.html) +* [CWE-922 Insecure Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/922.html) +* [CWE-1275 Sensitive Cookie with Improper SameSite Attribute](https://cwe.mitre.org/data/definitions/1275.html) diff --git a/2025/docs/it/A02_2025-Security_Misconfiguration.md b/2025/docs/it/A02_2025-Security_Misconfiguration.md new file mode 100644 index 000000000..a49b6ccfc --- /dev/null +++ b/2025/docs/it/A02_2025-Security_Misconfiguration.md @@ -0,0 +1,131 @@ +# A02:2025 Security Misconfiguration ![icon](../assets/TOP_10_Icons_Final_Security_Misconfiguration.png){: style="height:80px;width:80px" align="right"} + + +## 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](A03_2025-Software_Supply_Chain_Failures.md)). 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. + + +## Riferimenti. + +* [OWASP Testing Guide: Configuration Management](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README) +* [OWASP Testing Guide: Testing for Error Codes](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling) +* [Application Security Verification Standard V13 Configuration](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x22-V13-Configuration.md) +* [NIST Guide to General Server Hardening](https://csrc.nist.gov/publications/detail/sp/800-123/final) +* [CIS Security Configuration Guides/Benchmarks](https://www.cisecurity.org/cis-benchmarks/) +* [Amazon S3 Bucket Discovery and Enumeration](https://blog.websecurify.com/2017/10/aws-s3-bucket-discovery.html) + +## Lista delle CWE Mappate + +* [CWE-5 J2EE Misconfiguration: Data Transmission Without Encryption](https://cwe.mitre.org/data/definitions/5.html) +* [CWE-11 ASP.NET Misconfiguration: Creating Debug Binary](https://cwe.mitre.org/data/definitions/11.html) +* [CWE-13 ASP.NET Misconfiguration: Password in Configuration File](https://cwe.mitre.org/data/definitions/13.html) +* [CWE-15 External Control of System or Configuration Setting](https://cwe.mitre.org/data/definitions/15.html) +* [CWE-16 Configuration](https://cwe.mitre.org/data/definitions/16.html) +* [CWE-260 Password in Configuration File](https://cwe.mitre.org/data/definitions/260.html) +* [CWE-315 Cleartext Storage of Sensitive Information in a Cookie](https://cwe.mitre.org/data/definitions/315.html) +* [CWE-489 Active Debug Code](https://cwe.mitre.org/data/definitions/489.html) +* [CWE-526 Exposure of Sensitive Information Through Environmental Variables](https://cwe.mitre.org/data/definitions/526.html) +* [CWE-547 Use of Hard-coded, Security-relevant Constants](https://cwe.mitre.org/data/definitions/547.html) +* [CWE-611 Improper Restriction of XML External Entity Reference](https://cwe.mitre.org/data/definitions/611.html) +* [CWE-614 Sensitive Cookie in HTTPS Session Without 'Secure' Attribute](https://cwe.mitre.org/data/definitions/614.html) +* [CWE-776 Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')](https://cwe.mitre.org/data/definitions/776.html) +* [CWE-942 Permissive Cross-domain Policy with Untrusted Domains](https://cwe.mitre.org/data/definitions/942.html) +* [CWE-1004 Sensitive Cookie Without 'HttpOnly' Flag](https://cwe.mitre.org/data/definitions/1004.html) +* [CWE-1174 ASP.NET Misconfiguration: Improper Model Validation](https://cwe.mitre.org/data/definitions/1174.html) diff --git a/2025/docs/it/A03_2025-Software_Supply_Chain_Failures.md b/2025/docs/it/A03_2025-Software_Supply_Chain_Failures.md new file mode 100644 index 000000000..ffbb900cc --- /dev/null +++ b/2025/docs/it/A03_2025-Software_Supply_Chain_Failures.md @@ -0,0 +1,162 @@ +# A03:2025 Software Supply Chain Failures ![icon](../assets/TOP_10_Icons_Final_Vulnerable_Outdated_Components.png){: style="height:80px;width:80px" align="right"} + + +## Contesto. + +Questa categoria è risultata al primo posto nel sondaggio della community del Top 10, con esattamente il 50% dei rispondenti che la classificava al #1. Dalla sua prima comparsa nel Top 10 del 2013 come "A9 – Using Components with Known Vulnerabilities", il rischio è cresciuto fino a includere tutti i fallimenti della supply chain, non solo quelli che coinvolgono vulnerabilità note. Nonostante questo ambito ampliato, i fallimenti della supply chain continuano a essere difficili da identificare con solo 11 Common Vulnerability and Exposures (CVE) con le CWE correlate. Tuttavia, quando testata e riportata nei dati contribuiti, questa categoria ha il tasso medio di incidenza più alto al 5,19%. Le CWE rilevanti sono *CWE-477: Use of Obsolete Function, CWE-1104: Use of Unmaintained Third Party Components*, CWE-1329: *Reliance on Component That is Not Updateable*, e *CWE-1395: Dependency on Vulnerable Third-Party Component*. + + +## 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 +
6 + 9,56% + 5,72% + 65,42% + 27,47% + 8,17 + 5,23 + 215.248 + 11 +
+ + + +## Descrizione. + +I fallimenti della supply chain del software sono interruzioni o altre compromissioni nel processo di costruzione, 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 basa. + +È probabile che tu sia vulnerabile se: + +* non monitori attentamente le versioni di tutti i componenti che utilizzi (sia lato client che lato server). Ciò include i componenti che utilizzi direttamente e le dipendenze annidate (transitive). +* il software è vulnerabile, non supportato o non aggiornato. Ciò include OS, server web/applicativi, DBMS, applicazioni, API e tutti i componenti, ambienti di runtime e librerie. +* non effettui scansioni regolari per le vulnerabilità e non ti abboni ai bollettini di sicurezza relativi ai componenti che utilizzi. +* non disponi di un processo di gestione delle modifiche o di monitoraggio delle modifiche all'interno della tua supply chain, incluso il monitoraggio di IDE, estensioni e aggiornamenti IDE, modifiche al repository di codice della tua organizzazione, sandbox, repository di immagini e librerie, il modo in cui gli artifact vengono creati e archiviati, ecc. Ogni parte della tua supply chain deve essere documentata, soprattutto le modifiche. +* non hai rafforzato ogni parte della tua supply chain, con particolare attenzione al controllo degli accessi e all'applicazione del minimo privilegio. +* i sistemi della tua supply chain non hanno alcuna separazione dei compiti. Nessuna singola persona dovrebbe poter scrivere codice e promuoverlo fino in produzione senza la supervisione di un'altra persona. +* vengono utilizzati componenti da fonti non attendibili, in qualsiasi parte dello stack tecnologico, o possono impattare gli ambienti di produzione. +* non correggi o aggiorni la piattaforma sottostante, i framework e le dipendenze in modo tempestivo e basato sul rischio. Ciò accade comunemente in ambienti dove le patch sono un'attività mensile o trimestrale sotto controllo delle modifiche, lasciando le organizzazioni esposte per giorni o mesi prima di correggere le vulnerabilità. +* gli sviluppatori software non testano la compatibilità delle librerie aggiornate, aggiornate o patchate. +* non metti in sicurezza le configurazioni di ogni parte del tuo sistema (vedi [A02:2025-Security Misconfiguration](https://owasp.org/Top10/2025/A02_2025-Security_Misconfiguration/)). +* la tua pipeline CI/CD ha una sicurezza più debole rispetto ai sistemi che costruisce e distribuisce, specialmente se è complessa. + + +## Come prevenire. + +Deve essere in atto un processo di gestione delle patch per: + + + +* Generare e gestire centralmente il Software Bill of Materials (SBOM) dell'intero software. +* Monitorare non solo le dipendenze dirette, ma anche le loro dipendenze (transitive), e così via. +* Ridurre la superficie di attacco rimuovendo dipendenze non utilizzate, funzionalità, componenti, file e documentazione non necessari. +* Fare un inventario continuo delle versioni dei componenti sia lato client che lato server (es. framework, librerie) e delle loro dipendenze utilizzando strumenti come OWASP Dependency Track, OWASP Dependency Check, retire.js, ecc. +* Monitorare continuamente fonti come Common Vulnerability and Exposures (CVE), National Vulnerability Database (NVD) e [Open Source Vulnerabilities (OSV)](https://osv.dev/) per le vulnerabilità nei componenti utilizzati. Utilizzare software composition analysis, supply chain del software o strumenti SBOM orientati alla sicurezza per automatizzare il processo. Abbonarsi agli alert per le vulnerabilità di sicurezza relative ai componenti utilizzati. +* Ottenere componenti solo da fonti ufficiali (attendibili) tramite link sicuri. Preferire pacchetti firmati per ridurre la possibilità di includere un componente modificato e malevolo (vedi [A08:2025-Software and Data Integrity Failures](https://owasp.org/Top10/2025/A08_2025-Software_or_Data_Integrity_Failures/)). +* Scegliere deliberatamente quale versione di una dipendenza utilizzare e aggiornare solo quando necessario. +* Monitorare le librerie e i componenti non mantenuti o che non creano patch di sicurezza per le versioni più vecchie. Se le patch non sono possibili, considerare la migrazione a un'alternativa. Se non è possibile, considerare l'implementazione di una virtual patch per monitorare, rilevare o proteggere dal problema scoperto. +* Aggiornare regolarmente CI/CD, IDE e qualsiasi altro strumento di sviluppo. +* Evitare di distribuire aggiornamenti a tutti i sistemi contemporaneamente. Utilizzare rollout graduali o canary deployment per limitare l'esposizione in caso di compromissione di un vendor attendibile. + + +Deve essere in atto un processo di gestione delle modifiche o un sistema di monitoraggio per tracciare le modifiche a: + +* Impostazioni CI/CD (tutti gli strumenti di build e pipeline) +* Repository di codice +* Aree sandbox +* IDE degli sviluppatori +* Strumenti SBOM e artifact creati +* Sistemi di logging e log +* Integrazioni di terze parti, come SaaS +* Repository di artifact +* Container registry + + +Rafforzare i seguenti sistemi, inclusa l'abilitazione di MFA e il blocco degli IAM: + +* Il repository di codice (che include il non inserimento di segreti, la protezione dei branch, i backup) +* Le workstation degli sviluppatori (patch regolari, MFA, monitoraggio e altro) +* Il server di build e CI/CD (separazione dei compiti, controllo degli accessi, build firmate, segreti con scope per ambiente, log a prova di manomissione e altro) +* Gli artifact (garantire l'integrità tramite provenienza, firma e timestamp, promuovere gli artifact piuttosto che ricostruirli per ogni ambiente, garantire che le build siano immutabili) +* L'infrastruttura come codice (gestita come tutto il codice, incluso l'uso di PR e controllo delle versioni) + +Ogni organizzazione deve garantire un piano continuo per il monitoraggio, il triage e l'applicazione di aggiornamenti o modifiche di configurazione per tutta la durata dell'applicazione o del portfolio. + + +## Scenari di attacco di esempio. + +**Scenario #1:** Un vendor attendibile viene compromesso con malware, portando alla compromissione dei tuoi sistemi informatici quando esegui l'aggiornamento. L'esempio più famoso di questo è probabilmente: + + + +* La compromissione di SolarWinds nel 2019 che ha portato alla compromissione di circa 18.000 organizzazioni. [https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack](https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack) + +**Scenario #2:** Un vendor attendibile viene compromesso in modo tale da comportarsi in modo malevolo solo sotto una condizione specifica. + + + +* Il furto di 1,5 miliardi di dollari da Bybit nel 2025 è stato causato da [un attacco alla supply chain nel software del wallet](https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/) che veniva eseguito solo quando il wallet target era in uso. + +**Scenario #3:** Il [supply chain attack `Shai-Hulud`](https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem) nel 2025 è stato il primo worm npm auto-propagante di successo. Gli attacchi hanno seminato versioni malevole di pacchetti popolari, che utilizzavano uno script post-install per raccogliere ed esfiltrare dati sensibili in repository GitHub pubblici. Il malware rilevava anche i token npm nell'ambiente vittima e li utilizzava automaticamente per pubblicare versioni malevole di qualsiasi pacchetto accessibile. Il worm ha raggiunto oltre 500 versioni di pacchetti prima di essere interrotto da npm. Questo attacco alla supply chain era avanzato, a diffusione rapida e dannoso, e prendendo di mira le macchine degli sviluppatori ha dimostrato che gli sviluppatori stessi sono ora obiettivi primari degli attacchi alla supply chain. + +**Scenario #4:** I componenti tipicamente vengono eseguiti con gli stessi privilegi dell'applicazione stessa, quindi le falle in qualsiasi componente possono avere un impatto grave. Tali falle possono essere accidentali (es. errore di codice) o intenzionali (es. una backdoor in un componente). Alcuni esempi di vulnerabilità di componenti sfruttabili scoperte sono: + +* CVE-2017-5638, una vulnerabilità di remote code execution in Struts 2 che consente l'esecuzione di codice arbitrario sul server, è stata imputata a violazioni significative. +* CVE-2021-44228 ("Log4Shell"), una vulnerabilità zero-day di remote code execution in Apache Log4j, è stata imputata a campagne di ransomware, cryptomining e altri attacchi. + + +## Riferimenti + +* [OWASP Application Security Verification Standard: V15 Secure Coding and Architecture](https://owasp.org/www-project-application-security-verification-standard/) +* [OWASP Cheat Sheet Series: Dependency Graph SBOM](https://cheatsheetseries.owasp.org/cheatsheets/Dependency_Graph_SBOM_Cheat_Sheet.html) +* [OWASP Cheat Sheet Series: Vulnerable Dependency Management](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html) +* [OWASP Dependency-Track](https://owasp.org/www-project-dependency-track/) +* [OWASP CycloneDX](https://owasp.org/www-project-cyclonedx/) +* [OWASP Dependency Check (for Java and .NET libraries)](https://owasp.org/www-project-dependency-check/) +* [OWASP Virtual Patching Best Practices](https://owasp.org/www-community/Virtual_Patching_Best_Practices) +* [MITRE Common Vulnerabilities and Exposures (CVE) search](https://www.cve.org) +* [National Vulnerability Database (NVD)](https://nvd.nist.gov) +* [Retire.js for detecting known vulnerable JavaScript libraries](https://retirejs.github.io/retire.js/) +* [GitHub Advisory Database](https://github.com/advisories) + + +## Lista delle CWE Mappate + +* [CWE-447 Use of Obsolete Function](https://cwe.mitre.org/data/definitions/447.html) +* [CWE-1035 2017 Top 10 A9: Using Components with Known Vulnerabilities](https://cwe.mitre.org/data/definitions/1035.html) +* [CWE-1104 Use of Unmaintained Third Party Components](https://cwe.mitre.org/data/definitions/1104.html) +* [CWE-1329 Reliance on Component That is Not Updateable](https://cwe.mitre.org/data/definitions/1329.html) +* [CWE-1357 Reliance on Insufficiently Trustworthy Component](https://cwe.mitre.org/data/definitions/1357.html) +* [CWE-1395 Dependency on Vulnerable Third-Party Component](https://cwe.mitre.org/data/definitions/1395.html) diff --git a/2025/docs/it/A04_2025-Cryptographic_Failures.md b/2025/docs/it/A04_2025-Cryptographic_Failures.md new file mode 100644 index 000000000..28c1649c6 --- /dev/null +++ b/2025/docs/it/A04_2025-Cryptographic_Failures.md @@ -0,0 +1,164 @@ +# A04:2025 Cryptographic Failures ![icon](../assets/TOP_10_Icons_Final_Crypto_Failures.png){: style="height:80px;width:80px" align="right"} + + + +## Contesto. + +Scendendo di due posizioni al #4, questa debolezza si concentra sui fallimenti legati all'assenza di crittografia, a una crittografia insufficientemente forte, alla divulgazione di chiavi crittografiche e agli errori correlati. Tre delle CWE più comuni in questo rischio riguardano l'uso di un generatore di numeri pseudo-casuali debole: *CWE-327 Use of a Broken or Risky Cryptographic Algorithm, CWE-331: Insufficient Entropy*, *CWE-1241: Use of Predictable Algorithm in Random Number Generator*, e *CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)*. + + + +## 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 +
32 + 13,77% + 3,80% + 100,00% + 47,74% + 7,23 + 3,90 + 1.665.348 + 2.185 +
+ + + +## Descrizione. + +In linea generale, tutti i dati in transito devono essere cifrati a livello di [trasporto](https://en.wikipedia.org/wiki/Transport_layer) ([livello OSI](https://en.wikipedia.org/wiki/OSI_model) 4). Gli ostacoli precedenti come le prestazioni della CPU e la gestione di chiavi private/certificati sono ora gestiti da CPU con istruzioni progettate per accelerare la cifratura (es. [supporto AES](https://en.wikipedia.org/wiki/AES_instruction_set)) e dalla semplificazione della gestione di chiavi private e certificati da parte di servizi come [LetsEncrypt.org](https://LetsEncrypt.org), con i principali vendor cloud che forniscono servizi di gestione dei certificati ancora più integrati per le loro specifiche piattaforme. + +Oltre alla protezione del livello di trasporto, è importante determinare quali dati necessitano di cifratura a riposo e quali dati necessitano di cifratura aggiuntiva in transito (al [livello applicativo](https://en.wikipedia.org/wiki/Application_layer), livello OSI 7). Ad esempio, password, numeri di carta di credito, cartelle cliniche, informazioni personali e segreti aziendali richiedono una protezione aggiuntiva, specialmente se tali dati sono soggetti a leggi sulla privacy, es. il Regolamento Generale sulla Protezione dei Dati (GDPR) dell'UE, o normative come il PCI Data Security Standard (PCI DSS). Per tutti questi dati: + + + +* Vengono utilizzati algoritmi o protocolli crittografici vecchi o deboli, sia per default che nel codice meno recente? +* Vengono utilizzate chiavi crittografiche predefinite, vengono generate chiavi crittografiche deboli, le chiavi vengono riutilizzate, o manca una corretta gestione e rotazione delle chiavi? +* Le chiavi crittografiche vengono inserite nei repository di codice sorgente? +* La cifratura non viene applicata, es. mancano direttive o header di sicurezza HTTP (browser)? +* Il certificato del server ricevuto e la catena di fiducia vengono correttamente validati? +* I vettori di inizializzazione vengono ignorati, riutilizzati o non generati in modo sufficientemente sicuro per la modalità di operazione crittografica? Viene utilizzata una modalità operativa non sicura come ECB? Viene utilizzata la cifratura quando sarebbe più appropriata la cifratura autenticata? +* Le password vengono utilizzate come chiavi crittografiche in assenza di una funzione di derivazione delle chiavi basata su password? +* Viene utilizzata la casualità non progettata per soddisfare i requisiti crittografici? Anche se viene scelta la funzione corretta, deve essere seminata dallo sviluppatore, e in caso contrario, lo sviluppatore ha sovrascritto la forte funzionalità di seeding integrata con un seed privo di sufficiente entropia/imprevedibilità? +* Vengono utilizzate funzioni hash deprecate come MD5 o SHA1, o vengono usate funzioni hash non crittografiche quando sono necessarie funzioni hash crittografiche? +* I messaggi di errore crittografici o le informazioni sui canali laterali sono sfruttabili, ad esempio sotto forma di attacchi padding oracle? +* L'algoritmo crittografico può essere declassato o bypassato? + +Vedi i riferimenti ASVS: Cryptography (V11), Secure Communication (V12) e Data Protection (V14). + + +## Come prevenire. + +Fare almeno quanto segue e consultare i riferimenti: + + + +* Classificare ed etichettare i dati elaborati, archiviati o trasmessi da un'applicazione. Identificare quali dati sono sensibili secondo le leggi sulla privacy, i requisiti normativi o le esigenze aziendali. +* Archiviare le chiavi più sensibili in un HSM hardware o cloud. +* Utilizzare implementazioni ben consolidate degli algoritmi crittografici ogni volta che è possibile. +* Non archiviare dati sensibili inutilmente. Eliminarli il prima possibile o utilizzare la tokenizzazione conforme a PCI DSS o anche la troncatura. I dati non conservati non possono essere rubati. +* Assicurarsi di cifrare tutti i dati sensibili a riposo. +* Garantire che algoritmi, protocolli e chiavi standard aggiornati e robusti siano in uso; utilizzare una corretta gestione delle chiavi. +* Cifrare tutti i dati in transito con protocolli >= TLS 1.2 solamente, con cifrari con forward secrecy (FS), eliminare il supporto per i cifrari con cipher block chaining (CBC), supportare algoritmi di cambio chiave quantistici. Per HTTPS, applicare la cifratura utilizzando HTTP Strict Transport Security (HSTS). Verificare tutto con uno strumento. +* Disabilitare la cache per le risposte che contengono dati sensibili. Questo include la cache nel CDN, nel web server e nella cache applicativa (es. Redis). +* Applicare i controlli di sicurezza richiesti in base alla classificazione dei dati. +* Non utilizzare protocolli non cifrati come FTP e STARTTLS. Evitare l'uso di SMTP per trasmettere dati riservati. +* Archiviare le password utilizzando funzioni di hashing adaptive e con salt con un work factor (delay factor), come Argon2, yescrypt, scrypt o PBKDF2-HMAC-SHA-512. Per i sistemi legacy che utilizzano bcrypt, consultare [OWASP Cheat Sheet: Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html). +* I vettori di inizializzazione devono essere scelti in modo appropriato per la modalità di operazione. Ciò potrebbe significare l'uso di un CSPRNG (generatore di numeri pseudo-casuali crittograficamente sicuro). Per le modalità che richiedono un nonce, il vettore di inizializzazione (IV) non necessita di un CSPRNG. In tutti i casi, l'IV non deve mai essere usato due volte per una chiave fissa. +* Utilizzare sempre la cifratura autenticata anziché la sola cifratura. +* Le chiavi devono essere generate crittograficamente in modo casuale e archiviate in memoria come array di byte. Se viene utilizzata una password, deve essere convertita in una chiave tramite una funzione appropriata di derivazione delle chiavi basata su password. +* Garantire che la casualità crittografica venga utilizzata dove appropriato e che non sia stata seminata in modo prevedibile o con bassa entropia. La maggior parte delle API moderne non richiede allo sviluppatore di seminare il CSPRNG per essere sicuro. +* Evitare funzioni crittografiche deprecate, metodi di costruzione a blocchi e schemi di padding, come MD5, SHA1, Cipher Block Chaining Mode (CBC), PKCS numero 1 v1.5. +* Garantire che le impostazioni e le configurazioni soddisfino i requisiti di sicurezza facendole rivedere da specialisti della sicurezza, strumenti progettati a tale scopo, o entrambi. +* È necessario prepararsi ora per la crittografia post-quantistica (PQC), vedi riferimento (ENISA), in modo che i sistemi ad alto rischio siano al sicuro entro la fine del 2030. + + +## Scenari di attacco di esempio. + +**Scenario #1:** Un sito non utilizza o non applica TLS per tutte le pagine o supporta cifratura debole. Un attaccante monitora il traffico di rete (es. su una rete wireless non sicura), fa il downgrade delle connessioni da HTTPS a HTTP, intercetta le richieste e ruba il cookie di sessione dell'utente. L'attaccante poi riproduce questo cookie e dirottà la sessione (autenticata) dell'utente, accedendo o modificando i dati privati dell'utente. In alternativa potrebbe alterare tutti i dati trasportati, es. il destinatario di un bonifico bancario. + +**Scenario #2:** Il database delle password utilizza hash non salati o semplici per archiviare le password di tutti. Una falla di caricamento file consente a un attaccante di recuperare il database delle password. Tutti gli hash non salati possono essere esposti con una rainbow table di hash pre-calcolati. Gli hash generati da funzioni hash semplici o veloci possono essere violati dalle GPU, anche se erano salati. + + +## Riferimenti. + + + +* [OWASP Proactive Controls: C2: Use Cryptography to Protect Data](https://top10proactive.owasp.org/archive/2024/the-top-10/c2-crypto/) +* [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard) +* [OWASP Cheat Sheet: Transport Layer Protection](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html) +* [OWASP Cheat Sheet: User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) +* [OWASP Cheat Sheet: Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) +* [OWASP Cheat Sheet: Cryptographic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html) +* [OWASP Cheat Sheet: HSTS](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) +* [OWASP Testing Guide: Testing for weak cryptography](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/README) +* [ENISA: A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography) +* [NIST Releases First 3 Finalized Post-Quantum Encryption Standards](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards) + + +## Lista delle CWE Mappate + +* [CWE-261 Weak Encoding for Password](https://cwe.mitre.org/data/definitions/261.html) +* [CWE-296 Improper Following of a Certificate's Chain of Trust](https://cwe.mitre.org/data/definitions/296.html) +* [CWE-319 Cleartext Transmission of Sensitive Information](https://cwe.mitre.org/data/definitions/319.html) +* [CWE-320 Key Management Errors (Prohibited)](https://cwe.mitre.org/data/definitions/320.html) +* [CWE-321 Use of Hard-coded Cryptographic Key](https://cwe.mitre.org/data/definitions/321.html) +* [CWE-322 Key Exchange without Entity Authentication](https://cwe.mitre.org/data/definitions/322.html) +* [CWE-323 Reusing a Nonce, Key Pair in Encryption](https://cwe.mitre.org/data/definitions/323.html) +* [CWE-324 Use of a Key Past its Expiration Date](https://cwe.mitre.org/data/definitions/324.html) +* [CWE-325 Missing Required Cryptographic Step](https://cwe.mitre.org/data/definitions/325.html) +* [CWE-326 Inadequate Encryption Strength](https://cwe.mitre.org/data/definitions/326.html) +* [CWE-327 Use of a Broken or Risky Cryptographic Algorithm](https://cwe.mitre.org/data/definitions/327.html) +* [CWE-328 Reversible One-Way Hash](https://cwe.mitre.org/data/definitions/328.html) +* [CWE-329 Not Using a Random IV with CBC Mode](https://cwe.mitre.org/data/definitions/329.html) +* [CWE-330 Use of Insufficiently Random Values](https://cwe.mitre.org/data/definitions/330.html) +* [CWE-331 Insufficient Entropy](https://cwe.mitre.org/data/definitions/331.html) +* [CWE-332 Insufficient Entropy in PRNG](https://cwe.mitre.org/data/definitions/332.html) +* [CWE-334 Small Space of Random Values](https://cwe.mitre.org/data/definitions/334.html) +* [CWE-335 Incorrect Usage of Seeds in Pseudo-Random Number Generator(PRNG)](https://cwe.mitre.org/data/definitions/335.html) +* [CWE-336 Same Seed in Pseudo-Random Number Generator (PRNG)](https://cwe.mitre.org/data/definitions/336.html) +* [CWE-337 Predictable Seed in Pseudo-Random Number Generator (PRNG)](https://cwe.mitre.org/data/definitions/337.html) +* [CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator(PRNG)](https://cwe.mitre.org/data/definitions/338.html) +* [CWE-340 Generation of Predictable Numbers or Identifiers](https://cwe.mitre.org/data/definitions/340.html) +* [CWE-342 Predictable Exact Value from Previous Values](https://cwe.mitre.org/data/definitions/342.html) +* [CWE-347 Improper Verification of Cryptographic Signature](https://cwe.mitre.org/data/definitions/347.html) +* [CWE-523 Unprotected Transport of Credentials](https://cwe.mitre.org/data/definitions/523.html) +* [CWE-757 Selection of Less-Secure Algorithm During Negotiation('Algorithm Downgrade')](https://cwe.mitre.org/data/definitions/757.html) +* [CWE-759 Use of a One-Way Hash without a Salt](https://cwe.mitre.org/data/definitions/759.html) +* [CWE-760 Use of a One-Way Hash with a Predictable Salt](https://cwe.mitre.org/data/definitions/760.html) +* [CWE-780 Use of RSA Algorithm without OAEP](https://cwe.mitre.org/data/definitions/780.html) +* [CWE-916 Use of Password Hash With Insufficient Computational Effort](https://cwe.mitre.org/data/definitions/916.html) +* [CWE-1240 Use of a Cryptographic Primitive with a Risky Implementation](https://cwe.mitre.org/data/definitions/1240.html) +* [CWE-1241 Use of Predictable Algorithm in Random Number Generator](https://cwe.mitre.org/data/definitions/1241.html) diff --git a/2025/docs/it/A05_2025-Injection.md b/2025/docs/it/A05_2025-Injection.md new file mode 100644 index 000000000..c08898bf4 --- /dev/null +++ b/2025/docs/it/A05_2025-Injection.md @@ -0,0 +1,144 @@ +# A05:2025 Injection ![icon](../assets/TOP_10_Icons_Final_Injection.png){: style="height:80px;width:80px" align="right"} + +## Contesto. + +L'Injection scende di due posizioni dal #3 al #5 nella classifica, mantenendo la sua posizione relativa rispetto ad A04:2025-Cryptographic Failures e A06:2025-Insecure Design. L'Injection è una delle categorie più testate, con il 100% delle applicazioni testate per qualche forma di injection. Ha avuto il maggior numero di CVE per qualsiasi categoria, con 37 CWE in questa categoria. L'Injection include Cross-site Scripting (alta frequenza/basso impatto) con oltre 30k CVE e SQL Injection (bassa frequenza/alto impatto) con oltre 14k CVE. Il numero massivo di CVE segnalati per CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') abbassa l'impatto medio ponderato di questa categoria. + + +## 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 +
37 + 13,77% + 3,08% + 100,00% + 42,93% + 7,15 + 4,32 + 1.404.249 + 62.445 +
+ + + +## Descrizione. + +Una vulnerabilità di injection è una falla applicativa che consente all'input non attendibile dell'utente di essere inviato a un interprete (es. un browser, un database, la riga di comando) e fa sì che l'interprete esegua parti di quell'input come comandi. + +Un'applicazione è vulnerabile agli attacchi quando: + +* I dati forniti dall'utente non vengono validati, filtrati o sanificati dall'applicazione. +* Query dinamiche o chiamate non parametrizzate senza escape consapevole del contesto vengono utilizzate direttamente nell'interprete. +* Dati non sanificati vengono utilizzati nei parametri di ricerca dell'object-relational mapping (ORM) per estrarre record aggiuntivi e sensibili. +* Dati potenzialmente ostili vengono direttamente utilizzati o concatenati. L'SQL o il comando contiene la struttura e i dati malevoli in query dinamiche, comandi o stored procedure. + +Alcune delle injection più comuni sono SQL, NoSQL, OS command, Object Relational Mapping (ORM), LDAP e Expression Language (EL) o Object Graph Navigation Library (OGNL) injection. Il concetto è identico tra tutti gli interpreti. Il rilevamento è meglio ottenuto tramite una combinazione di revisione del codice sorgente e testing automatizzato (incluso il fuzzing) di tutti i parametri, header, URL, cookie, dati JSON, SOAP e XML. L'aggiunta di strumenti di testing della sicurezza applicativa statici (SAST), dinamici (DAST) e interattivi (IAST) nella pipeline CI/CD può essere utile per identificare le falle di injection prima della distribuzione in produzione. + +Una classe correlata di vulnerabilità di injection è diventata comune negli LLM. Queste sono discusse separatamente nell'[OWASP LLM Top 10](https://genai.owasp.org/llm-top-10/), specificamente [LLM01:2025 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/). + + +## Come prevenire. + +Il modo migliore per prevenire l'injection richiede di mantenere i dati separati dai comandi e dalle query: + +* L'opzione preferita è utilizzare un'API sicura, che eviti l'uso dell'interprete interamente, fornisca un'interfaccia parametrizzata, o migri verso Object Relational Mapping Tools (ORM). +**Nota:** Anche quando parametrizzate, le stored procedure possono ancora introdurre SQL injection se PL/SQL o T-SQL concatena query e dati o esegue dati ostili con EXECUTE IMMEDIATE o exec(). + +Quando non è possibile separare i dati dai comandi, è possibile ridurre le minacce utilizzando le seguenti tecniche. + +* Utilizzare la validazione degli input positiva lato server. Non si tratta di una difesa completa poiché molte applicazioni richiedono caratteri speciali, come aree di testo o API per applicazioni mobile. +* Per qualsiasi query dinamica residua, eseguire l'escape dei caratteri speciali utilizzando la sintassi di escape specifica per quell'interprete. +**Nota:** Le strutture SQL come i nomi delle tabelle, i nomi delle colonne, ecc. non possono essere sottoposte a escape, quindi i nomi di struttura forniti dall'utente sono pericolosi. Questo è un problema comune nel software di generazione di report. + +**Attenzione:** queste tecniche implicano l'analisi e l'escape di stringhe complesse, rendendole soggette a errori e non robuste a fronte di piccole modifiche al sistema sottostante. + +## Scenari di attacco di esempio. + +**Scenario #1:** Un'applicazione utilizza dati non attendibili nella costruzione della seguente chiamata SQL vulnerabile: + +``` +String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'"; +``` + +Un attaccante modifica il valore del parametro 'id' nel browser inviando: `' OR '1'='1`. Ad esempio: + +``` +http://example.com/app/accountView?id=' OR '1'='1 +``` + +Questo modifica il significato della query per restituire tutti i record dalla tabella degli account. Attacchi più pericolosi potrebbero modificare o eliminare dati o persino invocare stored procedure. + +**Scenario #2:** L'eccessiva fiducia di un'applicazione nei framework può risultare in query ancora vulnerabili. Ad esempio, Hibernate Query Language (HQL): + +``` +Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'"); +``` + +Un attaccante fornisce: `' OR custID IS NOT NULL OR custID='`. Questo bypassa il filtro e restituisce tutti gli account. Sebbene HQL abbia meno funzioni pericolose del SQL grezzo, consente ancora l'accesso non autorizzato ai dati quando l'input dell'utente viene concatenato nelle query. + +**Scenario #3:** Un'applicazione passa direttamente l'input dell'utente a un comando OS: + +``` +String cmd = "nslookup " + request.getParameter("domain"); +Runtime.getRuntime().exec(cmd); +``` + +Un attaccante fornisce `example.com; cat /etc/passwd` per eseguire comandi arbitrari sul server. + +## Riferimenti. + +* [OWASP Proactive Controls: Secure Database Access](https://owasp.org/www-project-proactive-controls/v3/en/c3-secure-database) +* [OWASP ASVS: V5 Input Validation and Encoding](https://owasp.org/www-project-application-security-verification-standard) +* [OWASP Testing Guide: SQL Injection](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection) +* [OWASP Cheat Sheet: Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html) +* [OWASP Cheat Sheet: SQL Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html) +* [OWASP Cheat Sheet: Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) +* [OWASP LLM Top 10: LLM01:2025 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) + + +## Lista delle CWE Mappate + +* [CWE-20 Improper Input Validation](https://cwe.mitre.org/data/definitions/20.html) +* [CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')](https://cwe.mitre.org/data/definitions/74.html) +* [CWE-77 Improper Neutralization of Special Elements used in a Command ('Command Injection')](https://cwe.mitre.org/data/definitions/77.html) +* [CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')](https://cwe.mitre.org/data/definitions/78.html) +* [CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')](https://cwe.mitre.org/data/definitions/79.html) +* [CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')](https://cwe.mitre.org/data/definitions/89.html) +* [CWE-90 Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')](https://cwe.mitre.org/data/definitions/90.html) +* [CWE-94 Improper Control of Generation of Code ('Code Injection')](https://cwe.mitre.org/data/definitions/94.html) +* [CWE-116 Improper Encoding or Escaping of Output](https://cwe.mitre.org/data/definitions/116.html) +* [CWE-564 SQL Injection: Hibernate](https://cwe.mitre.org/data/definitions/564.html) +* [CWE-643 Improper Neutralization of Data within XPath Expressions ('XPath Injection')](https://cwe.mitre.org/data/definitions/643.html) +* [CWE-917 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')](https://cwe.mitre.org/data/definitions/917.html) diff --git a/2025/docs/it/A06_2025-Insecure_Design.md b/2025/docs/it/A06_2025-Insecure_Design.md new file mode 100644 index 000000000..326c73646 --- /dev/null +++ b/2025/docs/it/A06_2025-Insecure_Design.md @@ -0,0 +1,142 @@ +# A06:2025 Insecure Design ![icon](../assets/TOP_10_Icons_Final_Insecure_Design.png){: style="height:80px;width:80px" align="right"} + + +## Contesto. + +L'Insecure Design scende di due posizioni dal #4 al #6 nella classifica mentre **[A02:2025-Security Misconfiguration](A02_2025-Security_Misconfiguration.md)** e **[A03:2025-Software Supply Chain Failures](A03_2025-Software_Supply_Chain_Failures.md)** la superano. Questa categoria è stata introdotta nel 2021 e abbiamo visto miglioramenti evidenti nel settore relativi al threat modeling e una maggiore enfasi sulla progettazione sicura. Questa categoria si concentra sui rischi legati a falle di design e architetturali, con un appello a un maggiore utilizzo del threat modeling, di pattern di design sicuro e di architetture di riferimento. Ciò include falle nella logica di business di un'applicazione, es. la mancanza di definizione di cambiamenti di stato indesiderati o imprevisti all'interno di un'applicazione. Come community, dobbiamo andare oltre lo "shift-left" nello spazio del codice, verso attività pre-codice come la stesura dei requisiti e la progettazione dell'applicazione, che sono critiche per i principi di Secure by Design (es. vedi **[Establish a Modern AppSec Program: Planning and Design Phase](0x03_2025-Establishing_a_Modern_Application_Security_Program.md)**). Le CWE notevoli includono *CWE-256: Unprotected Storage of Credentials, CWE-269 Improper Privilege Management, CWE-434 Unrestricted Upload of File with Dangerous Type, CWE-501: Trust Boundary Violation, e CWE-522: Insufficiently Protected Credentials.* + + +## 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 +
39 + 22,18% + 1,86% + 88,76% + 35,18% + 6,96 + 4,05 + 729.882 + 7.647 +
+ + + +## Descrizione. + +L'Insecure Design è una categoria ampia che rappresenta diverse debolezze, espresse come "progettazione dei controlli mancante o inefficace". L'Insecure Design non è la fonte di tutte le altre categorie di rischio del Top Ten. Si noti che c'è una differenza tra Insecure Design e implementazione non sicura. Distinguiamo tra falle di design e difetti di implementazione per una ragione: hanno cause principali diverse, si verificano in momenti diversi nel processo di sviluppo e hanno rimedi diversi. Un design sicuro può ancora avere 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 all'Insecure Design è la mancanza di profilazione del rischio di business inerente al software o al sistema in fase di sviluppo, e quindi il fallimento nel determinare quale livello di progettazione della sicurezza è richiesto. + +Tre parti fondamentali per avere un design sicuro sono: + +* Raccolta dei Requisiti e Gestione delle Risorse +* Creazione di un Design Sicuro +* Un Secure Development Lifecycle + + +### Requisiti e Gestione delle Risorse + +Raccogliere e negoziare i requisiti di business per un'applicazione con il business, inclusi i requisiti di protezione riguardanti la riservatezza, l'integrità, la disponibilità e l'autenticità di tutti i data asset e la logica di business prevista. Tenere conto di quanto sarà esposta la tua applicazione e se hai bisogno di segregazione dei tenant (oltre a quelle necessarie per il controllo degli accessi). Compilare i requisiti tecnici, inclusi i requisiti di sicurezza funzionali e non funzionali. Pianificare e negoziare il budget coprendo tutto il design, la costruzione, il testing e l'operatività, incluse le attività di sicurezza. + + +### Design Sicuro + +Il design sicuro è una cultura e una metodologia che valuta costantemente le minacce e garantisce che il codice sia progettato e testato in modo robusto per prevenire metodi di attacco noti. Il threat modeling dovrebbe essere integrato nelle sessioni di refinement (o attività simili); cercare i cambiamenti nei flussi di dati e nel controllo degli accessi o in altri controlli di sicurezza. Nello sviluppo delle user story, determinare il flusso corretto e gli stati di fallimento, assicurarsi che siano ben compresi e concordati dalle parti responsabili e interessate. Analizzare le assunzioni e le condizioni per i flussi previsti e di fallimento per garantire che rimangano accurate e desiderabili. Determinare come validare le assunzioni e applicare le condizioni necessarie per i comportamenti corretti. Assicurarsi che i risultati siano documentati nella user story. Imparare dagli errori e offrire incentivi positivi per promuovere i miglioramenti. Il design sicuro non è né un componente aggiuntivo né uno strumento che puoi aggiungere al software. + + +### Secure Development Lifecycle + +Il software sicuro richiede un secure development lifecycle, un pattern di design sicuro, una metodologia "paved road", una libreria di componenti sicuri, strumenti appropriati, threat modeling e post-mortem degli incidenti che vengono utilizzati per migliorare il processo. Contatta i tuoi specialisti della sicurezza all'inizio di un progetto software, durante il progetto e per la manutenzione continuativa del software. Considera di sfruttare l'[OWASP Software Assurance Maturity Model (SAMM)](https://owaspsamm.org/) per aiutare a strutturare i tuoi sforzi di sviluppo software sicuro. + +Spesso l'auto-responsabilità degli sviluppatori è sottovalutata. Favorire una cultura di consapevolezza, responsabilità e mitigazione proattiva dei rischi. Scambi regolari sulla sicurezza (es. durante le sessioni di threat modeling) possono generare una mentalità che include la sicurezza in tutte le decisioni di design importanti. + + +## Come prevenire. + + + +* Stabilire e utilizzare un secure development lifecycle con professionisti AppSec per aiutare a valutare e progettare controlli di sicurezza e privacy +* Stabilire e utilizzare una libreria di pattern di design sicuro o componenti "paved-road" +* Utilizzare il threat modeling per le parti critiche dell'applicazione come autenticazione, controllo degli accessi, logica di business e flussi chiave +* Utilizzare il threat modeling come strumento educativo per generare una mentalità di sicurezza +* Integrare il linguaggio e i controlli di sicurezza nelle user story +* Integrare controlli di plausibilità a ogni livello dell'applicazione (dal frontend al backend) +* Scrivere test unitari e di integrazione per validare che tutti i flussi critici siano resistenti al modello di minaccia. Compilare use-case *e* misuse-case per ogni livello dell'applicazione. +* Segregare i livelli del sistema e della rete a seconda dell'esposizione e delle esigenze di protezione +* Segregare i tenant in modo robusto by design attraverso tutti i livelli + + +## Scenari di attacco di esempio. + +**Scenario #1:** Un flusso di recupero delle credenziali potrebbe includere "domande e risposte", che è vietato da NIST 800-63b, dall'OWASP ASVS e dall'OWASP Top 10. Le domande e risposte non possono essere considerate attendibili come prova di identità, poiché più di una persona può conoscere le risposte. Tale funzionalità dovrebbe essere rimossa e sostituita con un design più sicuro. + +**Scenario #2:** Una catena cinematografica consente sconti per prenotazioni di gruppo e ha un massimo di quindici partecipanti prima di richiedere un deposito. Gli attaccanti potrebbero fare threat modeling di questo flusso e testare se riescono a trovare un vettore di attacco nella logica di business dell'applicazione, es. prenotare seicento posti e tutti i cinema contemporaneamente in poche richieste, causando una massiccia perdita di reddito. + +**Scenario #3:** Il sito di e-commerce di una catena retail non ha protezione contro bot usati da scalper per acquistare schede video di fascia alta da rivendere su siti di aste. Questo crea pubblicità terribile per i produttori di schede video e i proprietari delle catene retail, e risentimenti duraturi con gli appassionati che non riescono a ottenere queste schede a nessun prezzo. Un attento design anti-bot e regole di logica di dominio, come acquisti effettuati entro pochi secondi dalla disponibilità, potrebbero identificare acquisti non autentici e rifiutare tali transazioni. + + +## Riferimenti. + + + +* [OWASP Cheat Sheet: Secure Design Principles](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html) +* [OWASP SAMM: Design | Secure Architecture](https://owaspsamm.org/model/design/secure-architecture/) +* [OWASP SAMM: Design | Threat Assessment](https://owaspsamm.org/model/design/threat-assessment/) +* [NIST – Guidelines on Minimum Standards for Developer Verification of Software](https://www.nist.gov/publications/guidelines-minimum-standards-developer-verification-software) +* [The Threat Modeling Manifesto](https://threatmodelingmanifesto.org/) +* [Awesome Threat Modeling](https://github.com/hysnsec/awesome-threat-modelling) + + +## Lista delle CWE Mappate + +* [CWE-73 External Control of File Name or Path](https://cwe.mitre.org/data/definitions/73.html) +* [CWE-183 Permissive List of Allowed Inputs](https://cwe.mitre.org/data/definitions/183.html) +* [CWE-256 Unprotected Storage of Credentials](https://cwe.mitre.org/data/definitions/256.html) +* [CWE-266 Incorrect Privilege Assignment](https://cwe.mitre.org/data/definitions/266.html) +* [CWE-269 Improper Privilege Management](https://cwe.mitre.org/data/definitions/269.html) +* [CWE-311 Missing Encryption of Sensitive Data](https://cwe.mitre.org/data/definitions/311.html) +* [CWE-312 Cleartext Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/312.html) +* [CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')](https://cwe.mitre.org/data/definitions/362.html) +* [CWE-434 Unrestricted Upload of File with Dangerous Type](https://cwe.mitre.org/data/definitions/434.html) +* [CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')](https://cwe.mitre.org/data/definitions/444.html) +* [CWE-501 Trust Boundary Violation](https://cwe.mitre.org/data/definitions/501.html) +* [CWE-522 Insufficiently Protected Credentials](https://cwe.mitre.org/data/definitions/522.html) +* [CWE-602 Client-Side Enforcement of Server-Side Security](https://cwe.mitre.org/data/definitions/602.html) +* [CWE-642 External Control of Critical State Data](https://cwe.mitre.org/data/definitions/642.html) +* [CWE-657 Violation of Secure Design Principles](https://cwe.mitre.org/data/definitions/657.html) +* [CWE-693 Protection Mechanism Failure](https://cwe.mitre.org/data/definitions/693.html) +* [CWE-799 Improper Control of Interaction Frequency](https://cwe.mitre.org/data/definitions/799.html) +* [CWE-841 Improper Enforcement of Behavioral Workflow](https://cwe.mitre.org/data/definitions/841.html) +* [CWE-1021 Improper Restriction of Rendered UI Layers or Frames](https://cwe.mitre.org/data/definitions/1021.html) +* [CWE-1125 Excessive Attack Surface](https://cwe.mitre.org/data/definitions/1125.html) diff --git a/2025/docs/it/A07_2025-Authentication_Failures.md b/2025/docs/it/A07_2025-Authentication_Failures.md new file mode 100644 index 000000000..7c71bcf14 --- /dev/null +++ b/2025/docs/it/A07_2025-Authentication_Failures.md @@ -0,0 +1,126 @@ +# A07:2025 Authentication Failures ![icon](../assets/TOP_10_Icons_Final_Identification_and_Authentication_Failures.png){: style="height:80px;width:80px" align="right"} + + +## Contesto. + +Authentication Failures mantiene la sua posizione al #7 con una leggera modifica del nome per riflettere più accuratamente le 36 CWE in questa categoria. Nonostante i benefici dei framework standardizzati, questa categoria ha mantenuto il suo rango #7 dal 2021. Tra le CWE degne di nota vi sono *CWE-259 Use of Hard-coded Password*, *CWE-297: Improper Validation of Certificate with Host Mismatch*, *CWE-287: Improper Authentication*, *CWE-384: Session Fixation*, e *CWE-798 Use of Hard-coded Credentials*. + + +## 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 +
36 + 15,80% + 2,92% + 100,00% + 37,14% + 7,69 + 4,44 + 1.120.673 + 7.147 +
+ + + +## Descrizione. + +Quando un attaccante riesce a ingannare un sistema facendogli riconoscere come legittimo un utente non valido o non corretto, questa vulnerabilità è presente. Potrebbero esserci debolezze di autenticazione se l'applicazione: + +* Permette attacchi automatizzati come il credential stuffing, dove l'attaccante dispone di un elenco violato di username e password validi. Più recentemente questo tipo di attacco è stato esteso a includere attacchi ibridi di credential stuffing (noti anche come password spray attack), dove l'attaccante utilizza variazioni o incrementi delle credenziali trafugate per ottenere l'accesso, ad esempio provando Password1!, Password2!, Password3! e così via. +* Permette attacchi a forza bruta o altri attacchi automatizzati con script che non vengono bloccati rapidamente. +* Permette password predefinite, deboli o ben note, come "Password1" o username "admin" con password "admin". +* Consente agli utenti di creare nuovi account con credenziali già note come violate. +* Consente l'uso di processi di recupero credenziali e di password dimenticate deboli o inefficaci, come le "risposte alle domande di sicurezza", che non possono essere rese sicure. +* Utilizza store di dati di password in chiaro, cifrate o con hashing debole (vedi [A04:2025-Cryptographic Failures](https://owasp.org/Top10/2025/A04_2025-Cryptographic_Failures/)). +* Ha un'autenticazione a più fattori assente o inefficace. +* Consente l'uso di fallback deboli o inefficaci se l'autenticazione a più fattori non è disponibile. +* Espone l'identificatore di sessione nell'URL, in un campo nascosto o in un'altra posizione non sicura accessibile al client. +* Riutilizza lo stesso identificatore di sessione dopo un login riuscito. +* Non invalida correttamente le sessioni utente o i token di autenticazione (principalmente token di single sign-on (SSO)) durante il logout o dopo un periodo di inattività. +* Non verifica correttamente l'ambito e il pubblico previsto delle credenziali fornite. + +## Come prevenire. + +* Dove possibile, implementare e applicare l'uso dell'autenticazione a più fattori per prevenire attacchi automatizzati di credential stuffing, forza bruta e riutilizzo di credenziali rubate. +* Dove possibile, incoraggiare e abilitare l'uso di password manager, per aiutare gli utenti a fare scelte migliori. +* Non distribuire o deployare con credenziali predefinite, in particolare per gli utenti amministratori. +* Implementare controlli sulle password deboli, come testare le password nuove o modificate rispetto all'elenco delle 10.000 password peggiori. +* Durante la creazione di nuovi account e i cambi di password, validare rispetto agli elenchi di credenziali note come violate (es. usando [haveibeenpwned.com](https://haveibeenpwned.com)). +* Allineare le policy di lunghezza, complessità e rotazione delle password con le [linee guida NIST 800-63b nella sezione 5.1.1](https://pages.nist.gov/800-63-3/sp800-63b.html) per Memorized Secrets o altre policy di password moderne basate su evidenze. +* Non forzare le persone a ruotare le password a meno che non si sospetti una violazione. Se si sospetta una violazione, forzare immediatamente il reset delle password. +* Garantire che i percorsi di registrazione, recupero credenziali e API siano rafforzati contro gli attacchi di account enumeration utilizzando gli stessi messaggi per tutti gli esiti ("Username o password non validi."). +* Limitare o ritardare progressivamente i tentativi di login falliti, ma fare attenzione a non creare uno scenario di denial of service. Registrare tutti i fallimenti e inviare alert agli amministratori quando vengono rilevati o sospettati attacchi di credential stuffing, forza bruta o altri attacchi. +* Utilizzare un session manager integrato, sicuro e lato server che generi un nuovo ID di sessione casuale con alta entropia dopo il login. Gli identificatori di sessione non devono essere nell'URL, devono essere archiviati in modo sicuro in un cookie sicuro e invalidati dopo il logout, il timeout di inattività e il timeout assoluto. +* Idealmente, utilizzare un sistema pre-costruito e ben collaudato per gestire autenticazione, identità e gestione delle sessioni. Trasferire questo rischio ogni volta che è possibile acquistando e utilizzando un sistema rafforzato e ben testato. +* Verificare l'uso previsto delle credenziali fornite, es. per i JWT validare i claim `aud`, `iss` e gli scope. + + +## Scenari di attacco di esempio. + +**Scenario #1:** Il credential stuffing, l'uso di elenchi di combinazioni note di username e password, è ora un attacco molto comune. Più recentemente gli attaccanti hanno trovato il modo di 'incrementare' o altrimenti adattare le password, in base al comportamento umano comune. Ad esempio, cambiando 'Winter2025' in 'Winter2026', o 'ILoveMyDog6' in 'ILoveMyDog7' o 'ILoveMyDog5'. Questo adattamento dei tentativi di password è chiamato attacco ibrido di credential stuffing o password spray attack, e può essere ancora più efficace della versione tradizionale. Se un'applicazione non implementa difese contro le minacce automatizzate (forza bruta, script o bot) o il credential stuffing, l'applicazione può essere usata come oracolo di password per determinare se le credenziali sono valide e ottenere accesso non autorizzato. + +**Scenario #2:** La maggior parte degli attacchi di autenticazione riusciti si verifica a causa del continuo utilizzo delle password come unico fattore di autenticazione. Una volta considerate best practice, i requisiti di rotazione e complessità delle password incoraggiano gli utenti sia a riutilizzare le password che a usare password deboli. Si raccomanda alle organizzazioni di interrompere queste pratiche secondo NIST 800-63 e di applicare l'uso dell'autenticazione a più fattori su tutti i sistemi importanti. + +**Scenario #3:** I timeout delle sessioni dell'applicazione non sono implementati correttamente. Un utente utilizza un computer pubblico per accedere a un'applicazione e invece di selezionare "logout", chiude semplicemente la scheda del browser e se ne va. Un altro esempio è se una sessione Single Sign On (SSO) non può essere chiusa da un Single Logout (SLO). Cioè, un singolo login ti autentica, ad esempio, al tuo lettore di posta, al tuo sistema di documenti e al tuo sistema di chat. Ma il logout avviene solo per il sistema corrente. Se un attaccante usa lo stesso browser dopo che la vittima pensa di essersi disconnessa con successo, ma con l'utente ancora autenticato ad alcune delle applicazioni, può accedere all'account della vittima. + +## Riferimenti. + +* [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html) +* [OWASP Secure Coding Practices](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/01-introduction/05-introduction) + + +## Lista delle CWE Mappate + +* [CWE-258 Empty Password in Configuration File](https://cwe.mitre.org/data/definitions/258.html) +* [CWE-259 Use of Hard-coded Password](https://cwe.mitre.org/data/definitions/259.html) +* [CWE-287 Improper Authentication](https://cwe.mitre.org/data/definitions/287.html) +* [CWE-288 Authentication Bypass Using an Alternate Path or Channel](https://cwe.mitre.org/data/definitions/288.html) +* [CWE-290 Authentication Bypass by Spoofing](https://cwe.mitre.org/data/definitions/290.html) +* [CWE-295 Improper Certificate Validation](https://cwe.mitre.org/data/definitions/295.html) +* [CWE-297 Improper Validation of Certificate with Host Mismatch](https://cwe.mitre.org/data/definitions/297.html) +* [CWE-304 Missing Critical Step in Authentication](https://cwe.mitre.org/data/definitions/304.html) +* [CWE-306 Missing Authentication for Critical Function](https://cwe.mitre.org/data/definitions/306.html) +* [CWE-307 Improper Restriction of Excessive Authentication Attempts](https://cwe.mitre.org/data/definitions/307.html) +* [CWE-308 Use of Single-factor Authentication](https://cwe.mitre.org/data/definitions/308.html) +* [CWE-384 Session Fixation](https://cwe.mitre.org/data/definitions/384.html) +* [CWE-521 Weak Password Requirements](https://cwe.mitre.org/data/definitions/521.html) +* [CWE-613 Insufficient Session Expiration](https://cwe.mitre.org/data/definitions/613.html) +* [CWE-620 Unverified Password Change](https://cwe.mitre.org/data/definitions/620.html) +* [CWE-640 Weak Password Recovery Mechanism for Forgotten Password](https://cwe.mitre.org/data/definitions/640.html) +* [CWE-798 Use of Hard-coded Credentials](https://cwe.mitre.org/data/definitions/798.html) +* [CWE-1390 Weak Authentication](https://cwe.mitre.org/data/definitions/1390.html) +* [CWE-1391 Use of Weak Credentials](https://cwe.mitre.org/data/definitions/1391.html) +* [CWE-1392 Use of Default Credentials](https://cwe.mitre.org/data/definitions/1392.html) +* [CWE-1393 Use of Default Password](https://cwe.mitre.org/data/definitions/1393.html) diff --git a/2025/docs/it/A08_2025-Software_or_Data_Integrity_Failures.md b/2025/docs/it/A08_2025-Software_or_Data_Integrity_Failures.md new file mode 100644 index 000000000..c4c4071cd --- /dev/null +++ b/2025/docs/it/A08_2025-Software_or_Data_Integrity_Failures.md @@ -0,0 +1,107 @@ +# A08:2025 Software or Data Integrity Failures ![icon](../assets/TOP_10_Icons_Final_Software_and_Data_Integrity_Failures.png){: style="height:80px;width:80px" align="right"} + +## Contesto. + +Software or Data Integrity Failures continua all'#8, con una leggera modifica chiarificatrice del nome da "Software *and* Data Integrity Failures". Questa categoria si concentra sul fallimento nel mantenimento dei confini di fiducia e nella verifica dell'integrità di software, codice e artefatti dati a un livello inferiore rispetto ai Software Supply Chain Failures. Questa categoria si concentra sulle assunzioni relative agli aggiornamenti software e ai dati critici, senza verificarne l'integrità. Le CWE notevoli includono *CWE-829: Inclusion of Functionality from Untrusted Control Sphere*, *CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes*, e *CWE-502: Deserialization of Untrusted Data*. + + +## 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 +
14 + 8,98% + 2,75% + 78,52% + 45,49% + 7,11 + 4,79 + 501.327 + 3.331 +
+ + + +## Descrizione. + +I fallimenti di integrità del software e dei dati riguardano codice e infrastruttura che non proteggono da codice o dati non validi o non attendibili trattati come attendibili e validi. Un esempio è dove un'applicazione si basa su plugin, librerie o moduli da fonti non attendibili, repository e content delivery network (CDN). Una pipeline CI/CD non sicura priva di controlli di integrità del software in consumo e fornitura può introdurre la possibilità di accesso non autorizzato, codice non sicuro o malevolo, o compromissione del sistema. Un altro esempio è una CI/CD che estrae codice o artefatti da luoghi non attendibili e/o non li verifica prima dell'uso (controllando la firma o un meccanismo simile). Infine, molte applicazioni ora includono funzionalità di aggiornamento automatico, dove gli aggiornamenti vengono scaricati senza una verifica dell'integrità sufficiente e applicati all'applicazione precedentemente attendibile. Gli attaccanti potrebbero potenzialmente caricare i propri aggiornamenti da distribuire ed eseguire su tutte le installazioni. Un altro esempio è dove oggetti o dati sono codificati o serializzati in una struttura che un attaccante può vedere e modificare, rendendoli vulnerabili alla deserializzazione non sicura. + + +## Come prevenire. + + + +* Utilizzare firme digitali o meccanismi simili per verificare che il software o i dati provengano dalla fonte prevista e non siano stati alterati. +* Garantire che librerie e dipendenze, come npm o Maven, consumino solo repository attendibili. Se si ha un profilo di rischio più elevato, considerare l'hosting di un repository interno noto-buono e verificato. +* Garantire che ci sia un processo di revisione per le modifiche al codice e alla configurazione per minimizzare la possibilità che codice o configurazione malevoli vengano introdotti nella pipeline software. +* Garantire che la pipeline CI/CD abbia un'adeguata segregazione, configurazione e controllo degli accessi per garantire l'integrità del codice che scorre attraverso i processi di build e deploy. +* Garantire che dati serializzati non firmati o non cifrati non vengano ricevuti da client non attendibili e successivamente utilizzati senza qualche forma di controllo dell'integrità o firma digitale per rilevare manomissioni o replay dei dati serializzati. + + +## Scenari di attacco di esempio. + +**Scenario #1 Inclusione di funzionalità web da una fonte non attendibile:** Un'azienda utilizza un provider di servizi esterno per fornire funzionalità di supporto. Per comodità, ha un mapping DNS per `myCompany.SupportProvider.com` verso `support.myCompany.com`. Ciò significa che tutti i cookie, inclusi i cookie di autenticazione, impostati sul dominio `myCompany.com` verranno ora inviati al provider di supporto. Chiunque abbia accesso all'infrastruttura del provider di supporto può rubare i cookie di tutti gli utenti che hanno visitato `support.myCompany.com` ed eseguire un attacco di session hijacking. + +**Scenario #2 Aggiornamento senza firma:** Molti router domestici, set-top box, firmware di dispositivi e altri non verificano gli aggiornamenti tramite firmware firmato. Il firmware non firmato è un obiettivo crescente per gli attaccanti e si prevede che peggiorerà ulteriormente. Questa è una preoccupazione importante poiché molte volte non esiste alcun meccanismo per rimediare se non correggere in una versione futura e attendere che le versioni precedenti vengano dismesse. + +**Scenario #3 Utilizzo di pacchetti da una fonte non attendibile:** Uno sviluppatore ha difficoltà a trovare la versione aggiornata di un pacchetto che sta cercando, quindi lo scarica non dal gestore di pacchetti regolare e attendibile, ma da un sito web online. Il pacchetto non è firmato, quindi non c'è opportunità di garantire l'integrità. Il pacchetto include codice malevolo. + +**Scenario #4 Deserializzazione non sicura:** Un'applicazione React chiama una serie di microservizi Spring Boot. Essendo programmatori funzionali, hanno cercato di garantire che il loro codice sia immutabile. La soluzione a cui sono arrivati è serializzare lo stato dell'utente e passarlo avanti e indietro con ogni richiesta. Un attaccante nota la firma dell'oggetto Java "rO0" (in base64) e utilizza il [Java Deserialization Scanner](https://github.com/federicodotta/Java-Deserialization-Scanner) per ottenere l'esecuzione di codice remoto sul server applicativo. + +## Riferimenti. + +* [OWASP Cheat Sheet: Software Supply Chain Security](https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html) +* [OWASP Cheat Sheet: Infrastructure as Code](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) +* [OWASP Cheat Sheet: Deserialization](https://wiki.owasp.org/index.php/Deserialization_Cheat_Sheet) +* [SAFECode Software Integrity Controls](https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf) +* [A 'Worst Nightmare' Cyberattack: The Untold Story Of The SolarWinds Hack](https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack) +* [CodeCov Bash Uploader Compromise](https://about.codecov.io/security-update) + + +## Lista delle CWE Mappate + +* [CWE-345 Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html) +* [CWE-353 Missing Support for Integrity Check](https://cwe.mitre.org/data/definitions/353.html) +* [CWE-426 Untrusted Search Path](https://cwe.mitre.org/data/definitions/426.html) +* [CWE-427 Uncontrolled Search Path Element](https://cwe.mitre.org/data/definitions/427.html) +* [CWE-494 Download of Code Without Integrity Check](https://cwe.mitre.org/data/definitions/494.html) +* [CWE-502 Deserialization of Untrusted Data](https://cwe.mitre.org/data/definitions/502.html) +* [CWE-506 Embedded Malicious Code](https://cwe.mitre.org/data/definitions/506.html) +* [CWE-509 Replicating Malicious Code (Virus or Worm)](https://cwe.mitre.org/data/definitions/509.html) +* [CWE-565 Reliance on Cookies without Validation and Integrity Checking](https://cwe.mitre.org/data/definitions/565.html) +* [CWE-784 Reliance on Cookies without Validation and Integrity Checking in a Security Decision](https://cwe.mitre.org/data/definitions/784.html) +* [CWE-829 Inclusion of Functionality from Untrusted Control Sphere](https://cwe.mitre.org/data/definitions/829.html) +* [CWE-830 Inclusion of Web Functionality from an Untrusted Source](https://cwe.mitre.org/data/definitions/830.html) +* [CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes](https://cwe.mitre.org/data/definitions/915.html) +* [CWE-926 Improper Export of Android Application Components](https://cwe.mitre.org/data/definitions/926.html) diff --git a/2025/docs/it/A09_2025-Security_Logging_and_Alerting_Failures.md b/2025/docs/it/A09_2025-Security_Logging_and_Alerting_Failures.md new file mode 100644 index 000000000..ca5b15c14 --- /dev/null +++ b/2025/docs/it/A09_2025-Security_Logging_and_Alerting_Failures.md @@ -0,0 +1,123 @@ +# A09:2025 Security Logging & Alerting Failures ![icon](../assets/TOP_10_Icons_Final_Security_Logging_and_Monitoring_Failures.png){: style="height:80px;width:80px" align="right"} + + +## Contesto. + +Security Logging & Alerting Failures mantiene la sua posizione al #9. Questa categoria ha una leggera modifica del nome per enfatizzare la funzione di alerting necessaria per indurre azioni sugli eventi di logging rilevanti. Questa categoria sarà sempre sottorappresentata nei dati e per la terza volta è stata votata in una posizione nella lista dai partecipanti al sondaggio della community. Questa categoria è incredibilmente difficile da testare e ha una rappresentazione minima nei dati CVE/CVSS (solo 723 CVE); ma può essere molto impattante per la visibilità, l'alerting degli incidenti e la forensica. Questa categoria include problemi con la *corretta gestione dell'encoding dell'output nei file di log (CWE-117), l'inserimento di dati sensibili nei file di log (CWE-532) e il logging insufficiente (CWE-778).* + + +## 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 +
5 + 11,33% + 3,91% + 85,96% + 46,48% + 7,19 + 2,65 + 260.288 + 723 +
+ + + +## Descrizione. + +Senza logging e monitoraggio, gli attacchi e le violazioni non possono essere rilevati, e senza alerting è molto difficile rispondere in modo rapido ed efficace durante un incidente di sicurezza. Un logging insufficiente, un monitoraggio continuo, il rilevamento e l'alerting per avviare risposte attive si verificano ogni volta che: + + +* Gli eventi verificabili, come i login, i login falliti e le transazioni di alto valore, non vengono registrati o vengono registrati in modo incoerente (ad esempio, vengono registrati solo i login riusciti, ma non i tentativi falliti). +* Gli avvisi e gli errori generano messaggi di log assenti, inadeguati o poco chiari. +* L'integrità dei log non è adeguatamente protetta dalla manomissione. +* I log delle applicazioni e delle API non vengono monitorati per attività sospette. +* I log vengono archiviati solo localmente e non vengono adeguatamente sottoposti a backup. +* Soglie di alerting appropriate e processi di escalation delle risposte non sono in atto o efficaci. Gli alert non vengono ricevuti o esaminati entro un tempo ragionevole. +* I penetration test e le scansioni degli strumenti di dynamic application security testing (DAST) (come Burp o ZAP) non attivano alert. +* L'applicazione non è in grado di rilevare, escalare o avvisare per attacchi attivi in tempo reale o quasi in tempo reale. +* Sei vulnerabile alla fuga di informazioni sensibili rendendo visibili gli eventi di logging e alerting a un utente o a un attaccante (vedi [A01:2025-Broken Access Control](A01_2025-Broken_Access_Control.md)), o registrando informazioni sensibili che non dovrebbero essere registrate (come PII o PHI). +* Sei vulnerabile a injection o attacchi ai sistemi di logging o monitoraggio se i dati dei log non sono correttamente codificati. +* L'applicazione manca o gestisce male gli errori e altre condizioni eccezionali, in modo tale che il sistema non sia consapevole che si è verificato un errore e quindi non sia in grado di registrare che c'è stato un problema. +* Mancano o sono obsoleti adeguati 'use case' per l'emissione di alert per riconoscere una situazione speciale. +* Troppi alert falsi positivi rendono impossibile distinguere gli alert importanti da quelli non importanti, con il risultato che vengono riconosciuti troppo tardi o per niente (sovraccarico fisico del team SOC). +* Gli alert rilevati non possono essere elaborati correttamente perché il playbook per il caso d'uso è incompleto, obsoleto o mancante. + + +## Come prevenire. + +Gli sviluppatori dovrebbero implementare alcuni o tutti i seguenti controlli, a seconda del rischio dell'applicazione: + + +* Garantire che tutti i fallimenti di login, controllo degli accessi e validazione degli input lato server possano essere registrati con un contesto utente sufficiente per identificare account sospetti o malevoli e conservati per un tempo sufficiente a consentire un'analisi forense differita. +* Garantire che ogni parte dell'app che contiene un controllo di sicurezza venga registrata, indipendentemente dal fatto che abbia successo o fallisca. +* Garantire che i log vengano generati in un formato che le soluzioni di gestione dei log possano consumare facilmente. +* Garantire che i dati dei log siano codificati correttamente per prevenire injection o attacchi ai sistemi di logging o monitoraggio. +* Garantire che tutte le transazioni abbiano una traccia di audit con controlli di integrità per prevenire manomissioni o cancellazioni, come tabelle di database append-only o simili. +* Garantire che tutte le transazioni che generano un errore vengano annullate e ricominciare. Fallire sempre in modo chiuso. +* Se la tua applicazione o i suoi utenti si comportano in modo sospetto, emettere un alert. Creare linee guida per gli sviluppatori su questo argomento in modo che possano programmare in base a questo o acquistare un sistema per questo. +* I team DevSecOps e di sicurezza dovrebbero stabilire use case efficaci di monitoraggio e alerting inclusi playbook in modo che le attività sospette vengano rilevate e gestite rapidamente dal team del Security Operations Center (SOC). +* Aggiungere 'honeytoken' come trappole per gli attaccanti nella tua applicazione, ad esempio nel database, nei dati, come identità utente reale e/o tecnica. Poiché non vengono utilizzati nel normale business, qualsiasi accesso genera dati di logging che possono essere segnalati con quasi nessun falso positivo. +* L'analisi comportamentale e il supporto AI potrebbero essere opzionalmente una tecnica aggiuntiva per supportare bassi tassi di falsi positivi per gli alert. +* Stabilire o adottare un piano di risposta agli incidenti e di recupero, come NIST 800-61r2 o successivo. Insegnare agli sviluppatori software come appaiono gli attacchi e gli incidenti alle applicazioni, in modo che possano segnalarli. + +Esistono prodotti commerciali e open-source per la protezione delle applicazioni come l'OWASP ModSecurity Core Rule Set, e software open-source di correlazione dei log, come lo stack Elasticsearch, Logstash, Kibana (ELK), che includono dashboard personalizzate e alerting che potrebbero aiutarti a combattere questi problemi. Esistono anche strumenti di osservabilità commerciali che possono aiutarti a rispondere o bloccare gli attacchi in tempo quasi reale. + + +## Scenari di attacco di esempio. + +**Scenario #1:** L'operatore del sito web di un fornitore di piani sanitari per bambini non ha potuto rilevare una violazione a causa della mancanza di monitoraggio e logging. Una parte esterna ha informato il fornitore del piano sanitario che un attaccante aveva acceduto e modificato migliaia di cartelle sanitarie sensibili di oltre 3,5 milioni di bambini. Una revisione post-incidente ha rilevato che gli sviluppatori del sito web non avevano affrontato vulnerabilità significative. Poiché non esisteva alcun logging o monitoraggio del sistema, la violazione dei dati potrebbe essere stata in corso dal 2013, un periodo di oltre sette anni. + +**Scenario #2:** Una importante compagnia aerea indiana ha subito una violazione dei dati che coinvolgeva oltre dieci anni di dati personali di milioni di passeggeri, inclusi dati di passaporto e carte di credito. La violazione dei dati si è verificata presso un provider di cloud hosting di terze parti, che ha notificato la compagnia aerea della violazione dopo qualche tempo. + +**Scenario #3:** Una importante compagnia aerea europea ha subito una violazione segnalabile al GDPR. La violazione è stata causata da vulnerabilità di sicurezza dell'applicazione di pagamento sfruttate dagli attaccanti, che hanno raccolto oltre 400.000 record di pagamento dei clienti. La compagnia aerea è stata multata di 20 milioni di sterline dall'autorità di regolamentazione della privacy. + + +## Riferimenti. + +- [OWASP Proactive Controls: C9: Implement Logging and Monitoring](https://top10proactive.owasp.org/archive/2024/the-top-10/c9-security-logging-and-monitoring/) +- [OWASP Application Security Verification Standard: V16 Security Logging and Error Handling](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x25-V16-Security-Logging-and-Error-Handling.md) +- [OWASP Cheat Sheet: Application Logging Vocabulary](https://cheatsheetseries.owasp.org/cheatsheets/Application_Logging_Vocabulary_Cheat_Sheet.html) +- [OWASP Cheat Sheet: Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) +- [Data Integrity: Recovering from Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-11/final) +- [Real world example of such failures in Snowflake Breach](https://www.huntress.com/threat-library/data-breach/snowflake-data-breach) + + +## Lista delle CWE Mappate + +* [CWE-117 Improper Output Neutralization for Logs](https://cwe.mitre.org/data/definitions/117.html) +* [CWE-221 Information Loss of Omission](https://cwe.mitre.org/data/definitions/221.html) +* [CWE-223 Omission of Security-relevant Information](https://cwe.mitre.org/data/definitions/223.html) +* [CWE-532 Insertion of Sensitive Information into Log File](https://cwe.mitre.org/data/definitions/532.html) +* [CWE-778 Insufficient Logging](https://cwe.mitre.org/data/definitions/778.html) diff --git a/2025/docs/it/A10_2025-Mishandling_of_Exceptional_Conditions.md b/2025/docs/it/A10_2025-Mishandling_of_Exceptional_Conditions.md new file mode 100644 index 000000000..0c0075c4b --- /dev/null +++ b/2025/docs/it/A10_2025-Mishandling_of_Exceptional_Conditions.md @@ -0,0 +1,134 @@ +# A10:2025 Mishandling of Exceptional Conditions ![icon](../assets/TOP_10_Icons_Final_Mishandling_of_Exceptional_Conditions.png){: style="height:80px;width:80px" align="right"} + + +## Contesto. + +La gestione impropria delle condizioni eccezionali è una nuova categoria per il 2025. Questa categoria contiene 24 CWE e si concentra sulla gestione impropria degli errori, errori logici, failing open e altri scenari correlati derivanti da condizioni anomale che i sistemi possono incontrare. Questa categoria include alcuni CWE precedentemente associati a scarsa qualità del codice. Per noi era troppo generico; a nostro avviso, questa categoria più specifica fornisce indicazioni migliori. + +CWE notevoli inclusi in questa categoria: *CWE-209 Generation of Error Message Containing Sensitive Information, CWE-234 Failure to Handle Missing Parameter, CWE-274 Improper Handling of Insufficient Privileges, CWE-476 NULL Pointer Dereference,* e *CWE-636 Not Failing Securely ('Failing Open')*. + + +## Tabella dei punteggi. + + + + + + + + + + + + + + + + + + + + + + + + + +
CWE Mappati + Tasso di Incidenza Massimo + Tasso di Incidenza Medio + Copertura Massima + Copertura Media + Exploit Ponderato Medio + Impatto Ponderato Medio + Occorrenze Totali + CVE Totali +
24 + 20,67% + 2,95% + 100,00% + 37,95% + 7,11 + 3,81 + 769.581 + 3.416 +
+ + + +## Descrizione. + +La gestione impropria 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 imprevisti e talvolta vulnerabilità. Questo può coinvolgere uno o più dei seguenti 3 fallimenti: l'applicazione non previene una situazione insolita, non la identifica mentre si sta verificando e/o risponde in modo inadeguato o non risponde affatto alla situazione in seguito. + +Le condizioni eccezionali possono essere causate da validazione dell'input mancante, scarsa o incompleta, o gestione degli errori tardiva ad alto livello invece che nelle funzioni dove si verificano, o stati ambientali imprevisti come problemi di memoria, privilegi o rete, gestione incoerente delle eccezioni, o eccezioni non gestite del tutto, che permettono al sistema di cadere in uno stato sconosciuto e imprevedibile. Ogni volta che un'applicazione non è sicura della sua prossima istruzione, una condizione eccezionale è stata gestita in modo improprio. Errori ed eccezioni difficili da trovare possono minacciare la sicurezza dell'intera applicazione per molto tempo. + +Molte diverse vulnerabilità di sicurezza possono verificarsi quando gestiamo male le condizioni eccezionali, come bug logici, overflow, race condition, transazioni fraudolente, o problemi con memoria, stato, risorse, timing, autenticazione e autorizzazione. Questi tipi di vulnerabilità possono influenzare negativamente la riservatezza, la disponibilità e/o l'integrità di un sistema o dei suoi dati. Gli attaccanti manipolano la gestione degli errori difettosa di un'applicazione per colpire questa vulnerabilità. + + +## Come prevenire. + +Per gestire correttamente una condizione eccezionale dobbiamo pianificare tali situazioni (aspettarsi il peggio). Dobbiamo "catturare" ogni possibile errore di sistema direttamente nel punto in cui si verifica e poi gestirlo (il che significa fare qualcosa di significativo per risolvere il problema e assicurarci di riprenderci dalla questione). Come parte della gestione, dovremmo includere la generazione di un errore (per informare l'utente in modo comprensibile), la registrazione dell'evento, nonché l'emissione di un alert se riteniamo che sia giustificato. Dovremmo anche avere un gestore globale delle eccezioni nel caso in cui ci sia qualcosa che abbiamo mancato. Idealmente, avremmo anche strumenti o funzionalità di monitoraggio e/o osservabilità che vigilano su errori ripetuti o pattern che indicano un attacco in corso, in grado di emettere una risposta, una difesa o un blocco di qualche tipo. Questo può aiutarci a bloccare e rispondere a script e bot che si concentrano sulle nostre debolezze nella gestione degli errori. + +Catturare e gestire le condizioni eccezionali garantisce che l'infrastruttura sottostante dei nostri programmi non sia lasciata a gestire situazioni imprevedibili. Se siamo nel mezzo di una transazione di qualsiasi tipo, è estremamente importante eseguire il rollback di ogni parte della transazione e ricominciare (noto anche come failing closed). Tentare di recuperare una transazione a metà è spesso il punto in cui creiamo errori irrecuperabili. + +Quando possibile, aggiungere rate limiting, quote di risorse, throttling e altri limiti ovunque sia possibile, per prevenire le condizioni eccezionali in primo luogo. Nulla nell'informatica dovrebbe essere illimitato, poiché questo porta a mancanza di resilienza applicativa, denial of service, attacchi a forza bruta riusciti e bollette cloud straordinarie. Considerare se errori ripetuti identici, al di sopra di un certo tasso, debbano essere emessi solo come statistiche che mostrano con quale frequenza si sono verificati e in quale arco temporale. Queste informazioni dovrebbero essere aggiunte al messaggio originale in modo da non interferire con il logging e il monitoraggio automatizzati, vedere [A09:2025 Security Logging & Alerting Failures](A09_2025-Security_Logging_and_Alerting_Failures.md). + +Oltre a questo, vorremmo includere una validazione rigorosa dell'input (con sanificazione o escaping per caratteri potenzialmente pericolosi che dobbiamo accettare), e gestione degli errori *centralizzata*, logging, monitoraggio e alerting, e un gestore globale delle eccezioni. Un'applicazione non dovrebbe avere più funzioni per la gestione delle condizioni eccezionali, dovrebbe essere eseguita in un unico posto, allo stesso modo ogni volta. Dovremmo anche creare requisiti di sicurezza del progetto per tutti i consigli in questa sezione, eseguire attività di threat modeling e/o revisione del design sicuro nella fase di progettazione dei nostri progetti, eseguire code review o analisi statica, nonché eseguire test di stress, prestazioni e penetration testing del sistema finale. + +Se possibile, l'intera organizzazione dovrebbe gestire le condizioni eccezionali allo stesso modo, poiché rende più facile rivedere e verificare il codice per errori in questo importante controllo di sicurezza. + + +## Scenari di attacco di esempio. + +**Scenario #1:** L'esaurimento delle risorse dovuto alla gestione impropria delle condizioni eccezionali (Denial of Service) potrebbe essere causato se l'applicazione cattura le eccezioni quando i file vengono caricati, ma non rilascia correttamente le risorse dopo. Ogni nuova eccezione lascia risorse bloccate o altrimenti non disponibili, finché tutte le risorse non sono esaurite. + +**Scenario #2:** L'esposizione di dati sensibili tramite la gestione impropria degli errori del database che rivela l'errore di sistema completo all'utente. L'attaccante continua a forzare errori al fine di utilizzare le informazioni di sistema sensibili per creare un attacco SQL injection migliore. I dati sensibili nei messaggi di errore all'utente sono ricognizione. + +**Scenario #3:** La corruzione dello stato nelle transazioni finanziarie potrebbe essere causata da un attaccante che interrompe una transazione multi-step tramite interruzioni di rete. Immaginate che l'ordine della transazione fosse: addebitare l'account utente, accreditare l'account di destinazione, registrare la transazione. Se il sistema non esegue correttamente il rollback dell'intera transazione (failing closed) quando si verifica un errore a metà, l'attaccante potrebbe potenzialmente prosciugare l'account dell'utente, o possibilmente una race condition che consente all'attaccante di inviare denaro alla destinazione più volte. + + +## Riferimenti. + +OWASP MASVS‑RESILIENCE + +- [OWASP Cheat Sheet: Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) + +- [OWASP Cheat Sheet: Error Handling](https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html) + +- [OWASP Application Security Verification Standard (ASVS): V16.5 Error Handling](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x25-V16-Security-Logging-and-Error-Handling.md#v165-error-handling) + +- [OWASP Testing Guide: 4.8.1 Testing for Error Handling](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling) + +* [Best practices for exceptions (Microsoft, .Net)](https://learn.microsoft.com/en-us/dotnet/standard/exceptions/best-practices-for-exceptions) + +* [Clean Code and the Art of Exception Handling (Toptal)](https://www.toptal.com/developers/abap/clean-code-and-the-art-of-exception-handling) + +* [General error handling rules (Google for Developers)](https://developers.google.com/tech-writing/error-messages/error-handling) + +* [Example of real-world mishandling of an exceptional condition](https://www.firstreference.com/blog/human-error-and-internal-control-failures-cause-us62m-fine/) + +## Lista dei CWE Mappati +* [CWE-209 Generation of Error Message Containing Sensitive Information](https://cwe.mitre.org/data/definitions/209.html) +* [CWE-215 Insertion of Sensitive Information Into Debugging Code](https://cwe.mitre.org/data/definitions/215.html) +* [CWE-234 Failure to Handle Missing Parameter](https://cwe.mitre.org/data/definitions/234.html) +* [CWE-235 Improper Handling of Extra Parameters](https://cwe.mitre.org/data/definitions/235.html) +* [CWE-248 Uncaught Exception](https://cwe.mitre.org/data/definitions/248.html) +* [CWE-252 Unchecked Return Value](https://cwe.mitre.org/data/definitions/252.html) +* [CWE-274 Improper Handling of Insufficient Privileges](https://cwe.mitre.org/data/definitions/274.html) +* [CWE-280 Improper Handling of Insufficient Permissions or Privileges](https://cwe.mitre.org/data/definitions/280.html) +* [CWE-369 Divide By Zero](https://cwe.mitre.org/data/definitions/369.html) +* [CWE-390 Detection of Error Condition Without Action](https://cwe.mitre.org/data/definitions/390.html) +* [CWE-391 Unchecked Error Condition](https://cwe.mitre.org/data/definitions/391.html) +* [CWE-394 Unexpected Status Code or Return Value](https://cwe.mitre.org/data/definitions/394.html) +* [CWE-396 Declaration of Catch for Generic Exception](https://cwe.mitre.org/data/definitions/396.html) +* [CWE-397 Declaration of Throws for Generic Exception](https://cwe.mitre.org/data/definitions/397.html) +* [CWE-460 Improper Cleanup on Thrown Exception](https://cwe.mitre.org/data/definitions/460.html) +* [CWE-476 NULL Pointer Dereference](https://cwe.mitre.org/data/definitions/476.html) +* [CWE-478 Missing Default Case in Multiple Condition Expression](https://cwe.mitre.org/data/definitions/478.html) +* [CWE-484 Omitted Break Statement in Switch](https://cwe.mitre.org/data/definitions/484.html) +* [CWE-550 Server-generated Error Message Containing Sensitive Information](https://cwe.mitre.org/data/definitions/550.html) +* [CWE-636 Not Failing Securely ('Failing Open')](https://cwe.mitre.org/data/definitions/636.html) +* [CWE-703 Improper Check or Handling of Exceptional Conditions](https://cwe.mitre.org/data/definitions/703.html) +* [CWE-754 Improper Check for Unusual or Exceptional Conditions](https://cwe.mitre.org/data/definitions/754.html) +* [CWE-755 Improper Handling of Exceptional Conditions](https://cwe.mitre.org/data/definitions/755.html) +* [CWE-756 Missing Custom Error Page](https://cwe.mitre.org/data/definitions/756.html) diff --git a/2025/docs/it/X01_2025-Next_Steps.md b/2025/docs/it/X01_2025-Next_Steps.md new file mode 100644 index 000000000..fc4c0dec8 --- /dev/null +++ b/2025/docs/it/X01_2025-Next_Steps.md @@ -0,0 +1,49 @@ +# X01:2025 Prossimi Passi + +Il progetto OWASP Top 10 si concentra sull'identificazione dei rischi più gravi per un'ampia gamma di organizzazioni. Tuttavia, ogni organizzazione è unica e lo è anche il suo profilo di rischio. Incoraggiamo ogni organizzazione a utilizzare l'OWASP Top 10 come punto di partenza, non come standard definitivo. + +## Prossimi Passi per gli Architetti del Software e gli Sviluppatori + +Sia che si stia sviluppando una nuova applicazione o si stia mantenendo una esistente, considerate i seguenti passi per migliorare la sicurezza: + +**Adottare un ciclo di vita di sviluppo software sicuro (SSDLC).** Aggiungere attività di sicurezza in ogni fase, dalla raccolta dei requisiti al deployment e alle operazioni. Consultare [OWASP SAMM](https://owaspsamm.org/) per una guida su come strutturare questi sforzi. + +**Utilizzare framework e librerie sicure.** Sfruttare i framework moderni che includono controlli di sicurezza built-in. Consultare le [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/) per indicazioni specifiche per linguaggio e framework. + +**Eseguire la modellazione delle minacce.** Identificare i rischi specifici per la propria applicazione e affrontarli proattivamente nella progettazione. Vedere [OWASP Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html). + +**Integrare i test di sicurezza nella pipeline CI/CD.** Utilizzare strumenti di analisi statica (SAST), analisi dinamica (DAST) e analisi della composizione del software (SCA) per rilevare le vulnerabilità precocemente. + +**Formare i team di sviluppo.** Garantire che gli sviluppatori comprendano i rischi dell'OWASP Top 10 e come evitarli. Considerare programmi di security champion, gamification e formazione pratica tramite strumenti come [OWASP WebGoat](https://owasp.org/www-project-webgoat/) o [OWASP Juice Shop](https://owasp.org/www-project-juice-shop/). + +## Prossimi Passi per i Tester della Sicurezza + +**Andare oltre l'OWASP Top 10.** L'OWASP Top 10 è un insieme minimo. Consultare l'[OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/) per una copertura più completa. + +**Combinare metodi di test manuali e automatizzati.** Gli strumenti automatizzati trovano problemi noti in modo efficiente, ma i tester esperti trovano problemi logici e di business che gli strumenti mancano. + +**Documentare e comunicare i risultati in modo efficace.** Fornire passaggi di riproduzione chiari, valutazioni dell'impatto e indicazioni per la remediation per aiutare i team a risolvere i problemi rapidamente. + +**Seguire standard consolidati.** Considerare di utilizzare l'[OWASP Testing Guide](https://owasp.org/www-project-web-security-testing-guide/) come metodologia di test completa. + +## Prossimi Passi per le Organizzazioni + +**Stabilire un programma di sicurezza applicativa.** Non limitarsi a reagire alle vulnerabilità — costruire processi sistematici per prevenirle. Vedere la sezione [Stabilire un Programma Moderno di Sicurezza Applicativa](0x03_2025-Establishing_a_Modern_Application_Security_Program.md) per indicazioni. + +**Misurare e migliorare nel tempo.** Tracciare le metriche di sicurezza, le tendenze delle vulnerabilità e il tempo di remediation. Utilizzare i dati per guidare le decisioni di investimento. + +**Aggiornare regolarmente le valutazioni del rischio.** Il panorama delle minacce cambia, e anche i profili di rischio delle applicazioni. Rivalutare periodicamente le priorità. + +**Coinvolgere la leadership.** La sicurezza delle applicazioni richiede supporto organizzativo. Comunicare i rischi e i progressi ai decision maker in termini di impatto sul business. + +## Risorse OWASP + +* [OWASP Top 10](https://owasp.org/www-project-top-ten/) +* [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/) +* [OWASP Testing Guide](https://owasp.org/www-project-web-security-testing-guide/) +* [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/) +* [OWASP Software Assurance Maturity Model (SAMM)](https://owaspsamm.org/) +* [OWASP Dependency-Track](https://owasp.org/www-project-dependency-track/) +* [OWASP WebGoat](https://owasp.org/www-project-webgoat/) +* [OWASP Juice Shop](https://owasp.org/www-project-juice-shop/) +* [OWASP Security Champions Guide](https://securitychampions.owasp.org/) diff --git a/2025/docs/it/index.md b/2025/docs/it/index.md new file mode 100644 index 000000000..72b3ca181 --- /dev/null +++ b/2025/docs/it/index.md @@ -0,0 +1,40 @@ +# OWASP Top 10:2025 + +Benvenuto nella versione OWASP Top 10:2025. + +L'OWASP Top 10 è un documento di riferimento per la sensibilizzazione di sviluppatori e professionisti della sicurezza delle applicazioni web. Rappresenta un ampio consenso sui rischi di sicurezza più critici per le applicazioni web. + +## Informazioni su questa versione + +Questa è la versione **2025** dell'OWASP Top 10. Questa versione include aggiornamenti basati sui dati più recenti e sulle ultime tendenze in materia di sicurezza. + +## Pagina principale del progetto +La [pagina principale del progetto](https://github.com/OWASP/www-project-top-ten) contiene informazioni sulle versioni precedenti e metadati su questo progetto. + +## Per iniziare + +Inizia dall'[Introduzione](0x00_2025-Introduction.md) per scoprire le novità della versione 2025. + +## Navigazione + +- [Introduzione](0x00_2025-Introduction.md) +- [Informazioni su OWASP](0x01_2025-About_OWASP.md) +- [Cosa sono i Rischi di Sicurezza delle Applicazioni?](0x02_2025-What_are_Application_Security_Risks.md) +- [Stabilire un Programma Moderno di Sicurezza Applicativa](0x03_2025-Establishing_a_Modern_Application_Security_Program.md) + +### Lista Top 10:2025 + +1. [A01:2025 - Broken Access Control](A01_2025-Broken_Access_Control.md) +2. [A02:2025 - Security Misconfiguration](A02_2025-Security_Misconfiguration.md) +3. [A03:2025 - Software Supply Chain Failures](A03_2025-Software_Supply_Chain_Failures.md) +4. [A04:2025 - Cryptographic Failures](A04_2025-Cryptographic_Failures.md) +5. [A05:2025 - Injection](A05_2025-Injection.md) +6. [A06:2025 - Insecure Design](A06_2025-Insecure_Design.md) +7. [A07:2025 - Authentication Failures](A07_2025-Authentication_Failures.md) +8. [A08:2025 - Software or Data Integrity Failures](A08_2025-Software_or_Data_Integrity_Failures.md) +9. [A09:2025 - Security Logging and Alerting Failures](A09_2025-Security_Logging_and_Alerting_Failures.md) +10. [A10:2025 - Mishandling of Exceptional Conditions](A10_2025-Mishandling_of_Exceptional_Conditions.md) + +--- + +**Nota:** Le traduzioni verranno aggiunte man mano che saranno disponibili. diff --git a/2025/mkdocs.yml b/2025/mkdocs.yml index 35bee0cc0..74b0cc0cf 100644 --- a/2025/mkdocs.yml +++ b/2025/mkdocs.yml @@ -48,6 +48,27 @@ plugins: default: true name: en - English build: true + - locale: it + name: it - Italiano + build: true + nav_translations: + Home: Home + Introduction: Introduzione + About OWASP: Informazioni su OWASP + What are Application Security Risks?: Cosa sono i Rischi di Sicurezza delle Applicazioni? + Establishing a Modern Application Security Program: Sviluppare un Moderno Programma di Sicurezza Applicativa + Top 10:2025 List: Lista Top 10:2025 + A01 Broken Access Control: A01 Broken Access Control + A02 Security Misconfiguration: A02 Security Misconfiguration + A03 Software Supply Chain Failures: A03 Software Supply Chain Failures + A04 Cryptographic Failures: A04 Cryptographic Failures + A05 Injection: A05 Injection + A06 Insecure Design: A06 Insecure Design + A07 Authentication Failures: A07 Authentication Failures + A08 Software or Data Integrity Failures: A08 Software or Data Integrity Failures + A09 Security Logging and Alerting Failures: A09 Security Logging and Alerting Failures + A10 Mishandling of Exceptional Conditions: A10 Mishandling of Exceptional Conditions + Next Steps: Prossimi Passi nav_translations: SAMPLE: @@ -69,6 +90,7 @@ plugins: A09 Security Logging and Monitoring Failures: A09 - Unzureichendes Logging und Sicherheitsmonitoring A10 Server Side Request Forgery (SSRF): A10 - Server-Side Request Forgery (SSRF) Next Steps: Nächste Schritte + - macros: # needs to be the last plugin to export the final osib-YAML file for all languages module_name: '../osib/osib_macro' include_dir: '../osib/include' @@ -82,6 +104,9 @@ extra: # - name: de - Deutsch # link: ./de/ # lang: de + - name: it - Italiano + link: ./it/ + lang: it osib: document: osib.owasp.top10 version: 2025-0-1