Chiunque abbia una cellula cerebrale sa che l'uso di un utente che non è root / dbo / etc aggiunge molto alla sicurezza e quanto può essere efficace l'attacco SQL injection. Mi chiedo se l'idea di fare un passo avanti sia una buona idea.
L'idea di base è semplice. Per le azioni di tipo guest (visualizzazione) utilizzare un utente 'guest' nel database che dispone solo delle autorizzazioni per select cose. Per le azioni di tipo utente (aggiunta / modifica), avere un utente 'utente', che ha solo le autorizzazioni per eseguire insert e update query. Inoltre, includi anche un terzo utente con azioni simili a "admin", per delete abilità.
NB: questo è stato semplificato per coprire solo le abilità CRUD di base
Pro:
- Sicurezza aggiunta in teoria attraverso i limiti di autorizzazione.
- Forza la sicurezza del CMS per prevenire attacchi di rappresentazione / riproduzione.
Contro:
- Codice complicato all'interno di un CMS (che è ciò a cui sto pensando di utilizzare questa funzione in).
- Forza la sicurezza del CMS (che non sarà sempre raggiungibile)
La mia domanda è questa:
C'è un vantaggio in termini di sicurezza nel separare ruoli e permessi in questo modo, e se è così, i vantaggi di fare questo giustificano un codice più complicato per forzare un utente a cambiare azione?
Per esempio, diciamo che il controllo per vedere se cambio utenti è solo un'istruzione if, e se tale affermazione fallisce, allora l'utente non è autorizzato a fare qualsiasi azione comunque, quindi l'opzione non lo fa t accadono in primo luogo.