L’espressione security-by-design viene utilizzata dalla comunità di sviluppatori per denotare l’idea che, oltre alle esigenze funzionali di un software, la sicurezza debba essere presa in considerazione durante la progettazione e lo sviluppo del codice.

Negli ultimi decenni, quest’area d’indagine ha visto grandi progressi grazie soprattutto al continuo incremento degli attacchi informatici a danno delle infrastrutture web-based e cloud-based.

Purtroppo, la tendenza di molti sviluppatori di web app è quella di progettare software senza considerare con la massima serietà la componente sicurezza.

InSecure Design

Se stiamo costruendo una casa ma le sue fondamenta risultano instabili o fallate, l’intera infrastruttura risulterà esposta a rischi importanti. Allo stesso modo, se un’applicazione presenta un’architettura software fragile, sarà inevitabilmente esposta ad alcuni attacchi informatici.

InSecure Design (o progettazione insicura) è un termine che si riferisce alla pratica di sviluppare applicazioni, software o sistemi senza considerare adeguatamente le questioni di sicurezza fin dall’inizio del processo di sviluppo.

  1. Che cos’è l’InSecure Design?
  2. Quali sono le vulnerabilità di progettazione non sicura?
  3. L’impatto delle vulnerabilità InSecure design
  4. Come evitare le vulnerabilità nella progettazione non sicura?

Che cos’è l’InSecure Design?

La vulnerabilità di Insecure Design in sicurezza informatica viene definita come una macro categoria che include tutte le problematiche legate alla progettazione inefficace o mancante dei controlli di sicurezza in un’infrastruttura web-based. L’organizzazione OWASP nella sua OWASP Top 10 – versione 2021 inserisce la vulnerabilità InSecure Design al quarto posto e addirittura, l’organizzazione pone l’accento sulla distinzione tra difetti di progettazione software e difetti di implementazione per un motivo: hanno cause e rimedi diversi.

Se si parla di design insicuro di un’applicazione web certamente si fa riferimento ad un’infrastruttura di per sé costruita su basi non solide: le vulnerabilità sono insite nel codice sorgente, ragion per cui anche le più sicure implementazioni si inserirebbero all’interno di un contesto fallato. Mentre se parliamo di difetti di implementazione software, parliamo di una struttura di base di per sé sicura ma che viene aggiornata con pezzi di codice che comportano la comparsa di vulnerabilità nel lungo termine. La progettazione insicura di un software o di implementazione in ogni caso, comportano una serie di pericoli che sono provocati dal trascurare gli standard di sicurezza informatica minimi. Ad ogni modo, la presenza di vulnerabilità di InSecure Design costituisce un problema non da poco considerato che le minacce informatiche sono in continua evoluzione e risolvere queste problematiche significa riprogettare logiche e funzionamenti del software.

Casi esempio di vulnerabilità di InSecure Design

  • Mancanza di autenticazione e autorizzazione: se un’applicazione che non richiede l’autenticazione degli utenti o che consente a chiunque di accedere alle informazioni riservate è un esempio di progettazione insicura.
  • Mancanza di crittografia: un’applicazione che non utilizza la crittografia per proteggere i dati sensibili (ad esempio le informazioni personali degli utenti) può essere vulnerabile ad attacchi di tipo man in the middle o ad altri attacchi informatici.
  • Utilizzo di parametri di input non validati: un’applicazione che accetta input dall’utente senza validazione può essere vulnerabile ad attacchi di tipo injection come SQL injection o JavaScript injection.
  • Mancanza di gestione degli errori: un’applicazione che non gestisce correttamente gli errori può rivelare informazioni sensibili agli utenti o ai potenziali attaccanti.
  • Assenza di limitazioni di rate: un’applicazione che non limita il numero di richieste che un singolo utente può inviare in un determinato periodo di tempo può essere vulnerabile a attacchi di tipo brute force o di denial of service.
  • Mancanza di protezione contro le vulnerabilità note: un’applicazione che utilizza librerie o componenti noti per essere vulnerabili può essere vulnerabile a attacchi noti.
  • Mancanza di test di sicurezza: un’applicazione che non viene sottoposta a test di sicurezza regolari può essere vulnerabile a attacchi che potrebbero essere stati scoperti e corretti in precedenza.

Questi sono solo alcuni degli esempi comuni di vulnerabilità di InSecure Design. È importante notare che questi problemi possono essere evitati attraverso la progettazione e lo sviluppo di applicazioni con attenzione alla sicurezza fin dall’inizio del processo.

Tipologie di vulnerabilità InSecure Design

Le vulnerabilità di InSecure Design si possono verificare in molte forme e possono includere:

Archiviazione delle credenziali non adeguatamente protetta

Durante le fasi di sviluppo di una web-app, i team spesso ignorano le pratiche di controllo degli accessi, provocando la comparsa di falle di sicurezza.
Di conseguenza, in questo caso facciamo riferimento a:

  1. mancata gestione delle password
  2. archiviazione delle credenziali utente in testo non cifrato
  3. archiviazione credenziali esposte nei file di configurazione o nella RAM.

Purtroppo, queste configurazioni consentono agli aggressori di capire le credenziali di account amministratore e ottenere l’accesso non autorizzato ad aree protette dei software. Resta inteso che una pratica di questa tipologia provoca rischi enormi per la sicurezza della web-app ma anche per la stessa organizzazione il relativo know-how.

Trust Boundary Violations

si verifica quando un programma confonde il limite tra ciò che è attendibile e ciò che non lo è.
In altre parole, il software grazie ad un errore di codifica combina dati attendibili e non attendibili nella stessa struttura dati. In questo modo, lo stesso programmatore si fiderà erroneamente di dati non convalidati.

Costituisce uno degli errori più gravi poiché gli sviluppatori non riescono più a distinguere tra fonti affidabili e non affidabili, . Inoltre, se l’applicazione non dispone di un meccanismo di convalida dell’input rigorosamente installato, il back-end dell’applicazione potrebbe consentire la trasmissione pericolosa di dati oltre il confine di trust.

Generazione di messaggi di errore con informazioni sensibili

Indicata anche come CVE-209, parliamo di una cattiva configurazione di una web-app, la quale genera messaggi di errore che includono informazioni riservate su ambiente, utenti o dati associati. Questo succede poiché la maggior parte delle web app sono progettate per rilevare errori e fornire messaggi diagnostici che informano lo l’utente di ciò che è accaduto.
Questi messaggi di errore nel caso in cui contengano informazioni dettagliate e riservate come

  • l’ID utente
  • password
  • ambiente di sviluppo del programma
  • dettagli tecnici sulla tipologia dell’errore

costituiscono una vulnerabilità dell’applicazione. Le informazioni possono essere riprese dall’attaccante e sfruttate per condurre attacchi mirati come il directory traversal attack e gli attacchi SQL injection. Il messaggio di errore potrebbe rivelare la query, esporne la logica e forse anche password o altre informazioni riservate utilizzate.

Isolamento o compartimentazione inadeguati

Il software che contiene questa vulnerabilità solitamente non è in grado di separare adeguatamente i vari diritti, privilegi e autorizzazioni di accesso.

Manutenzione software insufficiente

La mancanza di aggiornamenti regolari dell’applicazione, nonché l’assenza di test di sicurezza possono rendere l’applicazione vulnerabile ad attacchi noti.

L’impatto delle vulnerabilità InSecure design

Le conseguenze degli attacchi variano in base all’entità dell’attacco, ai dati esposti e alla durata dell’attacco prima che venga rilevato.
Alcune conseguenze della presenza di una vulnerabilità di InSecure design possono essere:

  • Violazione del sistema e accesso ai dati
  • Iniezione codice malevolo
  • Lo spoofing di un server con numerose richieste comporta un attacco DDos.
  • Elevazione dei privilegi per account compromessi.

Come evitare le vulnerabilità di InsecureDesign?

A prescindere dalla tipologia di vulnerabilità di InSecure Design ci sia a bordo di un software web-based, se non viene corretta preventivamente può causare la compromissione dell’intero software.
Ecco alcune metodologie che consigliamo al fine di mettere in sicurezza le vostre applicazioni web-based:

Creare un ciclo di vita di architettura del software sicuro

I team di sviluppo dovrebbero utilizzare un approccio progettuale fattuale e modelli di progettazione software sicuri. Per ridurre il rischio per la sicurezza delle applicazioni, ogni membro del team dovrebbe avere accesso a servizi di sicurezza, librerie di componenti comprovate e modelli di minacce. I team di sicurezza dovrebbero essere inclusi nel ciclo di vita di un software al fine di testare in maniera continua i flussi (possibilmente attraverso l’implementazione di un Web Vulnerability Assessment).