Indice dei contenuti
Quando si parla di sicurezza di una web app, spesso si sente dire: âGli utenti fanno login, quindi lâaccesso è protettoâ. Ma autenticazione e autorizzazione non sono la stessa cosa. Confonderle può lasciare aperta una porta anche in unâapplicazione che usa password robuste e una schermata di login ben fatta.
La domanda da porsi è doppia: chi è lâutente? E, una volta identificato, che cosa è autorizzato a fare? La prima riguarda lâautenticazione, la seconda lâautorizzazione.
Autenticazione: chi sei? đ¤
Lâautenticazione verifica lâidentitĂ dellâutente. Può avvenire tramite password, passkey, autenticazione federata o altri meccanismi. Una web app deve gestire anche sessioni, scadenze, recupero dellâaccount e procedure di logout.
Alcuni controlli utili da considerare:
- password memorizzate con una funzione di hashing adatta, mai in chiaro;
- procedure di recupero account progettate per non diventare una scorciatoia per gli attaccanti;
- cookie di sessione configurati con attributi di sicurezza adeguati;
- protezione contro tentativi automatizzati di accesso;
- autenticazione a piĂš fattori per account sensibili, quando appropriato.
Un login riuscito dice chi è lâutente secondo lâapplicazione. Non dimostra ancora che possa leggere o modificare qualsiasi dato.
Autorizzazione: che cosa puoi fare? đŚ
Lâautorizzazione stabilisce quali risorse e operazioni sono consentite a un utente autenticato. Per esempio: un cliente può vedere i propri ordini, un operatore può gestire gli ordini assegnati e un amministratore può configurare il sistema.
Un errore comune è affidarsi soltanto a controlli nellâinterfaccia. Nascondere un pulsante non impedisce a qualcuno di inviare direttamente una richiesta allâendpoint. Le verifiche devono essere eseguite anche sul server, ogni volta che si accede a una risorsa o si compie unâazione protetta.
Il classico problema degli IDOR đľď¸
Immagina un indirizzo come /ordini/1842. Se lâapplicazione mostra lâordine dopo aver verificato soltanto che lâutente abbia effettuato il login, un utente potrebbe provare a cambiare il numero e accedere a un ordine che appartiene a qualcun altro.
Il problema non è che lâidentificativo sia facile da indovinare. Anche un identificativo difficile da prevedere non sostituisce il controllo dei permessi. Il server deve verificare che la risorsa richiesta appartenga allâutente o che il suo ruolo consenta quellâaccesso.
In pseudocodice, lâidea è semplice:
ordine = recuperaOrdine(id)
if ordine.proprietarioId != utente.id and not utente.puoGestireOrdini:
restituisciErroreAccessoNegato()La logica concreta cambia da progetto a progetto, ma la regola resta: non fidarti dellâID fornito dal browser; controlla sempre lâautorizzazione sul server.
Ruoli e permessi: evita il âtutti adminâ đ§Š
Un sistema di ruoli può aiutare a organizzare i permessi, ma va progettato in base alle reali esigenze. Creare un ruolo âadminâ per risolvere ogni problema è rapido, ma spesso concede piĂš potere del necessario.
Per ogni funzione, chiediti:
- quali utenti devono poterla usare?
- su quali dati possono operare?
- possono solo leggere o anche modificare?
- ci sono operazioni che richiedono una conferma aggiuntiva?
- il permesso viene controllato in ogni endpoint interessato?
Ă utile applicare il principio del privilegio minimo: concedere soltanto i permessi necessari al ruolo e allâattivitĂ , evitando accessi amministrativi permanenti quando non servono.
Come verificare i controlli đ§Ş
La documentazione OWASP Web Security Testing Guide include aree dedicate alla gestione delle identitĂ , allâautenticazione e ai controlli di autorizzazione. Può essere un riferimento strutturato per organizzare i test di unâapplicazione web.
Per una verifica iniziale, puoi creare account di prova con ruoli diversi e controllare che:
- un utente non autenticato non acceda alle funzioni protette;
- un utente standard non possa eseguire operazioni riservate agli amministratori;
- un utente non possa leggere i dati di un altro modificando URL o parametri;
- le API applichino gli stessi controlli dellâinterfaccia web;
- gli errori non rivelino dettagli interni o dati di altri account.
Fai questi test soltanto su sistemi di tua proprietĂ o per cui hai unâautorizzazione esplicita. Lâanalisi di sicurezza deve avere un perimetro chiaro, non trasformarsi in una scansione improvvisata di siti altrui.
Non dimenticare i test automatici đ¤
I test automatici possono proteggere le regole di accesso da regressioni future. Per esempio, una suite di test può verificare che un utente con ruolo âclienteâ riceva un errore quando tenta di consultare la risorsa di un altro cliente.
Conviene testare sia gli accessi consentiti sia quelli negati. Un test che dimostra che un amministratore può gestire una risorsa non basta: bisogna verificare anche che un utente senza quel permesso venga bloccato.
Una checklist prima di pubblicare â
- Le password e le sessioni sono gestite in modo sicuro?
- Ogni endpoint protetto verifica lâidentitĂ e i permessi richiesti?
- La proprietĂ delle risorse viene controllata sul server?
- I ruoli hanno soltanto i privilegi necessari?
- Le API sono testate separatamente dallâinterfaccia?
- Esistono test per gli accessi non autorizzati?
Un login non è un lasciapassare universale đŻ
Autenticazione e autorizzazione collaborano, ma risolvono problemi diversi. Sapere chi è lâutente è il primo passo; decidere quali dati e operazioni può raggiungere è il controllo che evita molte esposizioni accidentali.
Quando progetti una web app, pensa ai permessi fin dallâinizio e verifica i controlli direttamente sul server. Ă meno spettacolare di una nuova animazione nella dashboard, ma protegge ciò che per gli utenti conta davvero: i loro dati đ