Quali sono gli svantaggi dell'archiviazione del ruolo utente incluso l'admin in una variabile di sessione?

1

Nei miei progetti raccolgo sempre ruoli dal DB e li memorizzo in una variabile di sessione, quindi per controllare se un utente ha accesso alle pagine di amministrazione, controllo solo la sessione.
Consideriamo che uso un hosting privato quali sono gli svantaggi di questo approccio?

    
posta ALH 03.05.2012 - 14:13
fonte

2 risposte

2

Diciamo che un utente non amministratore modifica il proprio cookie di sessione e modifica admin=false in admin=true . È un problema, qualsiasi utente può ignorare banalmente tutti i tuoi controlli di accesso?

Dovresti dare ad ogni utente un token di sessione come 3f235219b2cca1842b4ae2dd9ec4a1a8570f2edf che è archiviato nel tuo database con una vita. Verifica che il token esista per tempo costante confrontando l'intera stringa e se l'utente con un token esiste e non è scaduto, verifichi se l'utente ha o meno il privilegio.

Probabilmente vorrai che sia un HTTP solo (non modificabile da javascript) e un cookie sicuro (impostato solo tramite https per impedire il MITM).

EDIT: http è un protocollo stateless. Significa che ogni richiesta http proveniente dal tuo server ricomincia da capo; il server Web non è a conoscenza se hai effettuato l'accesso a questa pagina per la prima volta o se stai effettuando una visita di più pagine sul sito. Il modo basilare per creare una sessione è di avere qualche variabile identificativa che viene restituita al server web ad ogni richiesta; dire attraverso una variabile GET / POST nascosta, un URL modificato o più tipicamente un cookie. Un cookie può essere impostato in una risposta HTTP da un server web come:

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: user_role=guest
...

e poi quando effettui la tua prossima richiesta al webserver:

GET /index.html HTTP/1.1
Host: www.example.org
Cookie: user_role=guest
...

Si noti che poiché l'utente ha il pieno controllo del proprio browser Web, non si può davvero fidarsi delle variabili che stanno inviando. Ad esempio, potrebbero cambiare user_role=admin . Quindi la soluzione è quella di memorizzare le informazioni sull'utente sul lato server. Quindi un utente si autentica con il server, poi gli dai un token (una stringa casuale lunga fSFrKtJXAnjo9wacE3XNMy ) e memorizza sul lato server che token = fSFrKtJXAnjo9wacE3XNMy è legato a qualcuno con user=guest (e qualsiasi altra cosa di cui hai bisogno per sapere del loro stato di sessione). Volete i cookie solo http, quindi è più difficile per gli attacchi in stile XSS rubare i cookie di sessione e proteggere in modo che gli intercettatori non possano ascoltarli banalmente.

    
risposta data 03.05.2012 - 14:23
fonte
-1

Un utente non autorizzato deve essere fermato molto prima che venga effettuata una chiamata per popolare i dettagli della sessione. Dovresti autenticare e autorizzare l'utente in AuthenticateRequest & Gli eventi AuthorizeRequest che vengono attivati prima dell'evento AcquireRequestState. Quindi, se l'utente non è autorizzato a visualizzare una risorsa, il resto degli eventi non si verificherà e quindi possiamo evitare il carico su DB o altre risorse.

Il ciclo di vita è descritto nella sezione Note della classe HttpApplication in MSDN

    
risposta data 03.05.2012 - 14:35
fonte

Leggi altre domande sui tag