Protezione dei campi dei moduli nascosti

4

Lo scenario è il seguente:

  1. 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.
  2. Ogni gruppo ha uno o più utenti amministratori.
  3. È possibile accedere a più utenti amministratori di diversi gruppi contemporaneamente.

Considera il seguente caso d'uso:

  1. Un utente amministratore accede all'interfaccia web e sceglie di visualizzare un elenco di utenti nel proprio gruppo.
  2. L'utente amministratore seleziona un utente da modificare (ad esempio, modifica dei privilegi).
  3. 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.
  4. L'utente amministratore immette un nuovo privilegio nel modulo e invia il modulo.
  5. L'applicazione web aggiorna i normali privilegi dell'utente nel database.
  6. 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:

  1. 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.
  2. 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.

    
posta user3337410 17.06.2014 - 01:09
fonte

2 risposte

18

Penso che tu stia lavorando alla fine sbagliata. Il server deve semplicemente verificare se l'amministratore è autorizzato a modificare l'utente subito prima dell'aggiornamento . Indipendentemente dal fatto che l'amministratore abbia modificato il modulo è irrilevante e comunque non può essere controllato. Il punto è che accetti le modifiche solo se l'utente è autorizzato a eseguirle, proprio come ovunque nella tua applicazione.

Cercando di proteggere i parametri manca il punto. È anche molto difficile e porterà a tutti i tipi di problemi. Ad esempio, supponiamo che un amministratore del gruppo Red inizi a modificare l'utente A che è effettivamente un membro di questo gruppo in questo momento. L'amministratore non tocca affatto il modulo, ma aspetta. Nel frattempo, l'utente A è passato al gruppo Blue, quindi l'amministratore non dovrebbe essere in grado di modificare questo utente. Tuttavia, probabilmente lascerai che lo facciano basandosi sull'obvervation che il modulo non è stato alterato.

    
risposta data 17.06.2014 - 01:51
fonte
0

Concordare con Fleche, fare sicurezza attraverso l'oscurità non è mai una buona idea. Assicurati semplicemente che quando un utente sta facendo una determinata azione, che sia autorizzato a fare quell'azione sulle risorse richieste.

In questo modo, un amministratore malintenzionato può provare tutto ciò che vuole, può solo modificare i dati sulla squadra a cui è autorizzato.

    
risposta data 17.06.2014 - 07:17
fonte

Leggi altre domande sui tag