Lo scenario è il seguente:
- Un'applicazione ha un'interfaccia web attraverso la quale è possibile configurare i dati. I dati da considerare per questa domanda sono Utenti con una relazione molti-a-molti con Gruppi.
- Ogni gruppo ha uno o più utenti amministratori.
- È possibile accedere a più utenti amministratori di diversi gruppi contemporaneamente.
Considera il seguente caso d'uso:
- Un utente amministratore accede all'interfaccia web e sceglie di visualizzare un elenco di utenti nel proprio gruppo.
- L'utente amministratore seleziona un utente da modificare (ad esempio, modifica dei privilegi).
- L'utente amministratore viene reindirizzato a una pagina di modifica per un singolo utente con l'ID utente normale in un campo nascosto nella pagina di modifica.
- L'utente amministratore immette un nuovo privilegio nel modulo e invia il modulo.
- L'applicazione web aggiorna i normali privilegi dell'utente nel database.
- Questo aspetto dell'applicazione Web non richiede l'ottimizzazione delle prestazioni, le operazioni nell'ordine di pochi secondi sono accettabili.
È ingenuo credere che il normale ID utente non possa essere modificato sul lato client, consentendo così a Red Admin User di Red Group di cambiare i privilegi di un normale User of Blue Group (di cui l'utente Red Admin NON è un membro).
Cosa si può fare sul lato server per proteggere l'integrità dell'ID dell'utente normale che si sta modificando?
Ai fini di questa domanda, supponiamo che l'utente amministratore rosso sia stato autenticato correttamente e sia autorizzato a visualizzare la pagina di modifica di un normale utente del gruppo rosso. Sono preoccupato qui con l'utente amministratore rosso che modifica maliziosamente l'ID utente nascosto di un normale utente del gruppo rosso per modificare le proprietà degli utenti di altri gruppi.
In particolare, questo sistema è sviluppato utilizzando Java EE in esecuzione su un server Glassfish.
Ho preso in considerazione le seguenti soluzioni:
- Incorpora un checksum crittografico che incorpora l'ID utente come campo nascosto nel modulo di modifica. Un hash MD5 o simile sarebbe inappropriato in quanto l'utente amministratore rosso avrebbe solo bisogno di calcolare il nuovo hash. L'hash dovrebbe essere derivato da qualche segreto sul lato server. Ovviamente il segreto dovrebbe essere imprevedibile e protetto.
- Attualmente il sistema utilizza un bean di sessione stateless per trasportare l'ID del normale utente da modificare dall'elenco degli utenti del gruppo rosso alla pagina di modifica dell'utente. Potrei cambiare il bean di sessione per essere un bean stateful manterrebbe lo User ID da modificare all'interno del server ma sto considerando altre alternative.
Quali altre opzioni dovrei prendere in considerazione per combattere questa particolare minaccia? Soggetti come l'autenticazione dell'utente e la trasmissione sicura non rientrano nell'ambito di questa domanda.