Sento spesso discutere di sicurezza, adducendo come esempio la visualizzazione da parte di un utente di un documento che non gli è concesso, semplicemente variando il valore di un campo ID che è passato attraverso la querystring.
Spesso la soluzione a questo problema è l'utilizzo di un campo GUID, che in genere è più difficile da modificare. Di sicuro più che una soluzione è solo una pezza aggiunta alle funzionalità dell'applicazione.
Molto più senso ha, invece, fare in modo che per ogni singolo accesso ad una risorsa, dove sia necessario, venga controllato nella stored procedure (o nella logica dell'applicazione) che l'utente abbia i giusti permessi per visualizzare quell'informazione.
Troppo spesso, infatti, viene dato per scontato che l'utente sia un amico, mentre in realtà la storia ci insegna che ogni singola richiesta che proviene dall'esterno deve essere vagliata con estrema precisione.
Non sarebbe carino, tanto per fare un esempio, che un utente semplicemente modificando l'ID nella querystring fosse in grado, come per magia, di vedere un documento sanitario (o qualunque altra cosa di riservato) di un'altra persona.
Quasi sempre la sicurezza, almeno a livello applicativo, parte davvero da piccole e semplici accortezze.
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
- Perché é importante insegnare ai bambini la programmazione: cosa possiamo fare noi?, l'11 dicembre 2013 alle 16:03
- modern.IE: sfatiamo qualche mito su IE10, il 3 maggio 2013 alle 17:46
- Installare gli emulatori per iPhone e iPad in Visual Studio 2012, il 12 ottobre 2012 alle 15:26
- L'importanza di applicare un SALT alle password: il caso di Linkedin, il 7 giugno 2012 alle 15:05
- Silverlight non morirà presto, il 3 novembre 2010 alle 19:38
- Il ruolo di Silverlight con HTML 5, il 2 settembre 2010 alle 09:17