“Crea sicurezza sin dall’inizio” per gli sviluppatori di app

Di John Schuch

Questo articolo è stato originariamente pubblicato nel numero di dicembre di (In) Secure Magazine: “ Non lasciare che l’educazione alla sicurezza e la consapevolezza prendano posto”

La maggior parte degli sviluppatori di applicazioni conosce la direttiva “Costruisci la sicurezza fin dall’inizio”. L’hanno ascoltata e letta numerose volte durante i dibattiti sulla sicurezza delle applicazioni. Tuttavia, non ci sono molte informazioni su cosa significhi effettivamente. A parte la mancanza di informazioni su cosa si intenda esattamente con il termine sicurezza, vi è anche una mancanza di informazioni su quando NON è specificamente una buona idea inserirle dall’inizio.

Questo articolo tenterà di chiarire questo argomento esponendo gli aspetti della sicurezza che devono essere coperti dagli sviluppatori di applicazioni e specificando in quale momento del ciclo di vita dell’applicazione dovrebbero verificarsi.

Gestione delle identità e controllo degli accessi

Una delle prime attività su cui iniziare a lavorare è la progettazione dell’integrazione con il sistema di gestione delle identità. Se stai sviluppando un’applicazione utilizzata esclusivamente dai dipendenti della tua azienda, molto probabilmente ti integrerai con il sistema di gestione delle identità già utilizzato dalla tua azienda. In tal caso, è necessario determinare i ruoli dei vari utenti dell’applicazione.

L’applicazione può avere solo un ruolo (utente) che semplificherebbe sicuramente la tua vita. Molto probabilmente, ci saranno ruoli diversi per utenti diversi, dando loro accesso a diverse parti dell’applicazione. Dovrai comprendere i ruoli gestiti dal tuo sistema di gestione delle identità, in modo da poter sapere se è possibile utilizzare ruoli esistenti o se è necessario crearne di nuovi.

Dovrai quindi integrarlo con il tuo sistema di controllo degli accessi. Ruoli diversi avranno capacità diverse nell’applicazione e il sistema di controllo degli accessi deve essere impostato per far rispettare tali regole. Un’altra interazione con il sistema di gestione delle identità che deve essere compreso è la creazione e la cancellazione degli utenti.

In alcune applicazioni, entrambe le azioni vengono eseguite completamente al di fuori dell’applicazione. La maggior parte delle applicazioni interne è così. La creazione e la cancellazione degli utenti è gestita da flussi di lavoro nel sistema di gestione delle identità e l’applicazione non svolge alcun ruolo in tale processo.

D’altra parte, le applicazioni la cui popolazione di utenti è composta dalla popolazione generale di Internet devono avere un metodo per creare ed eliminare utenti. In questi casi, molte organizzazioni scelgono di delegare la gestione delle identità a terzi come Facebook o Google. Se gestito rigorosamente secondo i protocolli di terze parti, questa può essere una soluzione valida dal punto di vista della sicurezza, sebbene trascini alcuni problemi aziendali che potrebbero essere o meno accettabili per le parti interessate. Si noti che una soluzione come questa non risponde alla necessità di controllo degli accessi o gestione delle sessioni.

Gestione della sessione

Il tuo sistema di controllo degli accessi gestirà le sessioni per te, ma è tua responsabilità determinare come vuoi gestire le sessioni degli utenti in caso di guasto del server. L’implementazione varierà a seconda del sistema di controllo degli accessi e del contenitore Web, ma sarà comunque necessario trovare una soluzione che implementa il giusto equilibrio tra convenienza dell’utente (in) e una soluzione di failover possibilmente costosa.

Crittografia e gestione dei dati

Ogni pezzo di dati che passa attraverso il tuo sistema deve essere identificato e devi determinare quale livello di protezione richiede i dati. Questo viene fatto attraverso un processo di classificazione dei dati. Presumo che tu non stia gestendo i dati delle carte di credito, poiché ciò richiede tecniche di protezione più avanzate che esulano dallo scopo di questo articolo.

Una volta completata la classificazione dei dati, saprai quali dei dati che stai gestendo richiedono la crittografia durante il transito e a riposo.

Ogni pezzo di dati che richiede la crittografia dovrà essere crittografato attraverso l’intero sistema, non solo dal browser ai server frontend. Ciò richiederà l’utilizzo di un protocollo di trasmissione crittografato quando i dati vengono trasferiti tra i server e l’utilizzo della crittografia ogni volta che i dati vengono archiviati. Fare questo all’inizio di un progetto è importante in modo da poter coinvolgere il tuo DevOps o il team di supporto del data center. Saranno quelli che implementeranno la crittografia del livello di trasporto, la gestione dei certificati e la gestione delle chiavi. Alcune delle cose che devono essere configurate potrebbero richiedere del tempo, quindi è fondamentale coinvolgerle presto.

Archiviazione chiave

Se intendi implementare la crittografia nella tua applicazione, il tuo prossimo e assolutamente più importante compito sarà determinare la tua strategia per l’archiviazione sicura delle chiavi. Se il tuo ambiente supporta già la crittografia, molto probabilmente sarai in grado di utilizzare il meccanismo di archiviazione delle chiavi esistente. In caso contrario, dovrai crearne uno. Mentre ci sono sistemi di gestione delle chiavi che è possibile acquistare, è anche possibile “arrotolare” il proprio.

Se scegli quest’ultima opzione, dovresti almeno seguire queste linee guida:

1. Non conservare le chiavi con i dati che proteggono.

2. Creare un percorso sicuro per memorizzare le chiavi.

Rotazione chiave

Un’altra parte fondamentale della gestione delle chiavi è avere un metodo per ruotare le chiavi. Innanzitutto dovrai determinare un periodo di scadenza appropriato (tutte le chiavi hanno date di scadenza). Scegli quello appropriato per la tua organizzazione e i dati che stai proteggendo. Quindi, determinare il processo che verrà utilizzato per ruotare le chiavi.

Idealmente, vuoi un processo che sia completamente innocuo per la tua applicazione. Ciò è particolarmente vero se si sta sviluppando un’applicazione che non avrà tempi di inattività. Non vorrai mettere offline il tuo sito Web ad alto traffico solo per ruotare le chiavi.

Architettura dell’applicazione

Questo argomento potrebbe utilizzare un intero libro, ma i punti chiave da tenere a mente quando si progetta il sistema è che:

1. Tutte le connessioni in entrata al server devono essere considerate potenzialmente ostili, anche se hanno una sessione valida.

2. Tutti gli ambienti client sono completamente insicuri a tutti i livelli.

3. Tutte le reti esterne al perimetro della rete privata sono completamente insicure. Il codice sul lato server deve essere scritto come se fosse sotto attacco da un codice ostile in sessione autenticato e il codice sul lato client deve presumere che ogni byte di codice proveniente da ogni risposta del server possa essere esaminato e sovvertito da hacker esperti .

La registrazione verrà descritta più avanti in questo articolo, ma durante questa fase di progettazione assicurarsi di essere in grado di tracciare le transazioni end-to-end attraverso il sistema. Questo ti aiuterà a identificare quando un utente malintenzionato ha capito come iniettare una transazione in un punto a valle del punto in cui una transazione deve essere avviata.

A questo punto, abbiamo coperto tutti gli elementi relativi alla sicurezza che devono essere costruiti in anticipo. Gli elementi rimanenti sono cose che possono attendere fino a dopo nel progetto. In alcuni casi, non possono essere avviati fino a quando il progetto non è ben avviato e in altri casi si tratta di attività che devono essere svolte continuamente durante l’intero ciclo di vita dell’applicazione.

Scansione vulnerabilità

Non eseguirai la scansione delle vulnerabilità in anticipo, ma dovrai avviare la scansione dopo aver eseguito il codice. Non vuoi aspettare fino a quando non sei pronto per passare alla produzione per avviare la scansione. Potresti essere sopraffatto dal numero di vulnerabilità. Se inizi a scansionare il tuo codice all’inizio del progetto, sarai in grado di mantenere il numero di vulnerabilità che devono essere riparate a un livello gestibile.

Potresti anche scoprire alcune cattive abitudini di alcuni sviluppatori che possono essere corretti o alcune vulnerabilità nella tua piattaforma o nelle librerie che devono essere patchate.

Librerie esterne

Qual è la tua strategia per verificare che le librerie esterne che hai scaricato da Internet non siano “cattive”? Gli esperti di sicurezza sono divisi sul vero rischio di attacchi di iniezione tra build, ma è ancora necessario un modo per determinare che le librerie esterne non contengono codice dannoso. Sul lato server, ciò significa generalmente fare affidamento su librerie ampiamente utilizzate e controllare da vicino le fonti e le versioni delle librerie.

Per le dipendenze basate sul browser, questo dovrebbe essere meno un problema perché tutto il codice lato client dovrebbe essere considerato potenzialmente compromesso.

Registrazione

Assicurati di non scrivere alcuna informazione sensibile nei tuoi registri. Non vuoi che i tuoi file di registro siano un modo semplice per gli aggressori di ottenere questi dati.

Potresti essere tentato di continuare a fornire la possibilità di registrare informazioni riservate a livello di debug, in quanto ciò può tornare utile quando hai a che fare con un incidente in produzione. Ma devi avere una strategia per cancellare i dati sensibili dai registri.

Disponibilità

Non c’è molto che puoi fare per difenderti da un attacco denial of service a livello di applicazione. Tuttavia, puoi fare qualche sforzo per trovare modi per impedire agli aggressori di sprecare risorse. Ad esempio, è possibile utilizzare un CAPTCHA per impedire la creazione di account illegali o pensare a modi per impedire agli aggressori di inviare richieste semplici che consumano connessioni al database o altre risorse.

Le attività relative alla sicurezza che devono essere completate durante lo sviluppo dell’applicazione sono state elencate sopra. La tua applicazione potrebbe non aver bisogno di tutti, ma a seconda di ciò di cui hai bisogno, ora sai quali attività devono essere eseguite in anticipo.

Hai altre domande sulla sicurezza dei dati? Non esitate a contattarci o lasciare un commento qui sotto. Per saperne di più in futuro, non dimenticare di seguirci su Twitter facendo clic di seguito: