Quali sono le implicazioni per la sicurezza di avere un account utente fittizio che rappresenta utenti non autenticati?

Question

Quali sono le implicazioni per la sicurezza di avere un account utente fittizio che rappresenta utenti non autenticati?

#1 da (2 voti)

3

Nella mia applicazione web, gli utenti sono assegnati a gruppi e i gruppi hanno le autorizzazioni sugli oggetti. L'applicazione espone alcuni oggetti a utenti pubblici non autenticati (ad esempio persone che visitano casualmente il sito Web).

Ho pensato di avere un attributo oggetto di "visibile al pubblico" che concede agli utenti non autenticati l'accesso.

Ho anche pensato di creare un gruppo di nome Pubblico e di concedere le autorizzazioni di quel gruppo come qualsiasi altro gruppo, quindi trattare automaticamente l'utente non autenticato come utente "fittizio" membro di quel gruppo.

Quest'ultimo aspetto sembra più semplice dal punto di vista dell'interfaccia (sia API che UI) per la gestione delle autorizzazioni. Ma il concetto di gruppo pubblico è speciale come un leggero odore di design. Mi mancano i principi di sicurezza che renderebbero questo indesiderabile?

authentication rbac user-management

posta jl6 08.03.2016 - 21:57

fonte

1 risposta

Leggi altre domande sui tag authentication rbac user-management

Fare in modo che SSH avvisi il monitoraggio del MITM Distribuzione del token dell'API dell'applicazione

score 2 · Answer 1

Sembra che i seguenti buoni principi di sicurezza stabiliscano impostazioni predefinite sicure, cercando di mantenerlo semplice e assicurando che gli ospiti abbiano privilegi minimi.

Penso che entrambe le opzioni siano valide e dovrebbero essere lasciate a te, il programmatore. Qualunque cosa tu pensi sia più semplice e più facile da gestire a lungo termine è probabilmente la scelta giusta.

Se un oggetto visibile a pubblico sarà facile da gestire i diritti di accesso su qualsiasi contenuto desideri, usalo, purché fornisca anche funzionalità semplici per cambiare ciò che è visibile in futuro .

Personalmente preferirei creare un gruppo di autorizzazioni per gli ospiti e assegnarli a quel gruppo di default perché è quello che tutti sono abituati a gestire. Permetterebbe anche a qualcuno di gestire le autorizzazioni di tutti gli ospiti nello stesso modo in cui si gestiscono le autorizzazioni per tutti gli altri. Ricorda, mantieni la sicurezza semplice.

Attack surface area and simplicity go hand in hand. Certain software engineering fads prefer overly complex approaches to what would otherwise be relatively straightforward and simple code. Developers should avoid the use of double negatives and complex architectures when a simpler approach would be faster and simpler.

Ulteriori informazioni sui principi di sicurezza qui - owasp.org