Owasp Capitolo 7: le best practices per difendersi dalle falle di sicurezza su identificazione e autenticazione
Al settimo posto, perde il posto sul podio la precedentemente nota Broken Authentication. Questa particolare falla di sicurezza riguarda tutte quelle situazioni in cui è imperativo controllare l’identità dell’utente.
Un’applicazione risulterà vulnerabile in termini di identificazione e autenticazione se si dovessero verificare uno o più dei seguenti scenari:
- Permettere attacchi automatizzati alle password e username come il credential stuffing, dove l’attaccante ha una lista di username e password valide
- Permettere attacchi di brute force o altri tipi di attacchi automatizzati
- Consentire password di default, deboli, o estremamente note , come ad esempio “Password1” o “admin/admin”
- Utilizzare sistemi di recupero credenziali deboli o inefficaci, come ad esempio le domande basate su fatti conosciuti (che non possono essere intrinsecamente sicure)
- Immagazzinare e gestire le password in chiaro, o utilizzando sistemi di hashing deboli
- Non implementare la MFA
- Esporre un identificativo di sessione nell’URL della risorsa
- Riutilizzare l’identificatore di sessione dopo un login avvenuto con successo
- Non invalidare gli ID di sessione. Dopo un logout o periodo di inattività, il sistema non invalida gli ID di sessione o i tokens (principalmente i token SSO), rendendoli riutilizzabili da un attaccante.
Come difendersi?
- Ove possibile implementare la MFA per scongiurare attacchi automatizzati
- Non inviare o mettere in produzione l’applicativo con password di default, in particolar modo per gli utenti amministratori
Implementare dei controlli sulla complessità delle password, come ad esempio le verificare delle password con la top 10.000 delle password più usate - Allineare la gestione delle password con le linee guida NIST 800-63b, alla sezione 5.1.1
- Assicurarsi che la registrazione nuovo utente, recupero credenziali e i percorsi di eventuali API, siano messi in sicurezza contro attacchi di enumerazione utenti, usando gli stessi messaggi per tutti i risultati
- Limitare o ritardare in maniera progressiva i tentativi falliti di login, facendo attenzione a non creare degli scenari di denial of service
- Registrare ogni tentativo fallito e allertare gli amministratori se vengono rilevati attacchi di brute force o credential stuffing
- Utilizzare un session manager integrato a livello di server che genera un session ID casuale nuovo dopo ogni accesso
- L’identificatore di sessione non dovrebbe essere esposto nell’URL, dovrebbe essere immagazzinato in maniera sicura, e invalidato al logout dell’utente, dopo un certo periodo di inattività o con un timer assoluto.
