In questo articolo ci dedicheremo all'approfondimento di un aspetto molto importante che riguarda le impostazioni di sicurezza introdotte con ASP.NET Core: le Data Protection APIs, ovvero le interfacce che determinano il funzionamento delle chiavi di sicurezza utilizzate all'interno della nostra applicazione.
Come probabilmente già molti sviluppatori sapranno, le applicazioni ASP.NET Core utilizzano infatti un set di chiavi di sicurezza per effettuare molteplici attività di encrypt, decrypt e convalida dei vari token che vengono rilasciate dai vari middleware di autorizzazione e autenticazione: bearer token, cookie di sessione, antiforgery, token che identificano le richieste di cambio password dell'utente, etc.; ciascuno di questi token viene generato automaticamente dall'applicazione utilizzando un set di chiavi di sicurezza univoco, così da minimizzare i rischi che un attacker possa dotarsi degli strumenti necessari per poter generare token "validi".
Per impostazione predefinita, queste chiavi di sicurezza vengono generate in memoria nel momento in cui l'applicazione viene avviata. Si tratta di una strategia indubbiamente molto efficace per prevenire gli attacchi malevoli di cui sopra, ma è certamente poco pratico per la gestione ordinaria della maggior parte delle applicazioni: in questo modo, infatti, ogni volta che la app viene riavviata saranno generate delle nuove chiavi di sicurezza, rendendo impossibile effettuare il decrypt o l'identificazione dei contenuti crittografati precedentemente rilasciati: in termini pratici questo significa che, ad esempio, tutti i cookie crittografati rilasciati fino a quel momento (tra cui i cookie di sessione, i cookie "ricordati di me" etc) saranno considerati invalidi, costringendo gli utenti a inserire nuovamente le credenziali. Questo tipo di inconvenienti possono essere trascurabili quando la nostra web application viene lanciata nell'environment di sviluppo (Development) o in un ambiente di Staging, ma potrebbero risultare molto fastidiosi per la nostra user base quando la nostra app viene pubblicata su un server di Produzione.
Per ovviare a questo problema, è possibile configurare un behavior diverso da quello predefinito utilizzando l'apposito metodo services.AddDataProtection() all'interno del file Startup.cs. (o Program.cs, per le app sviluppate a partire da .NET 6).
Nell'esempio seguente viene chiesto all'applicazione di generare le chiavi su un'apposita cartella /App_Keys/ (presente su FileSystem) e rigenerate ogni 90 giorni:
|
1 2 3 4 5 |
services.AddDataProtection() .SetApplicationName("myApp") .SetDefaultKeyLifetime(TimeSpan.FromDays(90)) .PersistKeysToFileSystem(new DirectoryInfo("/App_Keys/")); } |
Affinché il codice di cui sopra funzioni, è necessario svolgere le seguenti operazioni sulla macchina server:
- Creare la cartella /App_Keys/ all'interno del folder di pubblicazione.
- Impostare i permessi di scrittura per l'utente IIS_IUSRS (o dell' utente relativo all'Application Pool utilizzata).
In assenza di questa cartella o dei permessi di scrittura l'applicazione in produzione darà errore, in quanto non riuscirà a memorizzare le chiavi di sicurezza su disco.
Ovviamente l'ipotesi di persistere le chiavi di sicurezza su FileSystem è solo una delle possibili alternative: le Data Protection APIs consentono di implementare soluzioni di memorizzazione anche più sicure ed efficaci, come ad esempio mediante l'utilizzo di Azure Key Vault o altri Key Storage Providers, ovvero servizi che consentono la memorizzazione sicura delle credenziali.
Per maggiori informazioni, consigliamo di consultare la guida alla configurazione dei Key Storage Providers su Microsoft Docs.
