Va bene avere un livello di validazione prima del livello di controllo di accesso

Dipende se conoscere la validità di qualche input per un'attività che non ti è permesso fare è una perdita di sicurezza. Se lo è, dovresti davvero farlo al contrario.

L'unica risposta sicura a un utente non autorizzato è "accesso negato". Se a volte la risposta è "richiesta errata" e altre volte "accesso negato", si inviano informazioni a un utente non autorizzato.

Ad esempio, è possibile avere un controllo nella convalida dell'attività "elimina documento" che il documento denominato esiste. Qualcuno senza permessi sarebbe in grado di discernere se qualcosa esiste tentando di cancellarlo e confrontando quale errore riceva. Un aggressore particolarmente determinato può enumerare tutti i nomi dei documenti (con una certa lunghezza), per vedere quale esiste.

Bene, ci sono più tipi di convalida:

1. Controllo della sanità di base economico, che verifica che la richiesta non sia ovviamente malformata.

   Questo è tipicamente almeno parzialmente duplicato lato client, per evitare inutili round-trip.

   In ogni caso, dovrebbe essere fatto prima di accedere al controllo degli accessi per rendere le cose più facili e meno soggette a errori, in quanto non rischia alcuna perdita di informazioni.

2. Convalida più costosa che ancora non dipende da dati dell'applicazione protetti.

   Se c'è una tale extra-convalida, potrebbe essere dopo il controllo dell'accesso per non evitare perdite di dati, ma per ostacolare gli attacchi DOS.
   A volte semplicemente l'esecuzione della richiesta fa parte di quella convalida implicitamente a costo ridotto o nullo, quindi potrebbe non essere disponibile qui.

   Se tutta la convalida del primo passo è duplicata, potrebbe avere senso duplicare anche parti di questo lato client.

3. Convalida aggiuntiva a seconda dei dati dell'applicazione protetti.

   Farlo prima che il controllo degli accessi rischi ovviamente perdite di informazioni. Quindi, prima fai il controllo degli accessi.

Ci deve essere alcuni validazione prima del controllo degli accessi. Supponiamo che l'API di SO abbia un endpoint "modifica risposta", quindi se l'utente può modificare una determinata risposta può dipendere dalla risposta (sotto una certa reputazione, un utente può modificare solo le proprie risposte). Quindi il parametro "ID risposta" che è ben formato deve essere verificato prima che entri in gioco il livello di controllo di accesso; forse anche la risposta esiste.

OTOH, come menzionano Caleth e Greg, mettendo una convalida più ampia prima che il controllo dell'accesso sia un potenziale rischio per la sicurezza.

Quindi le regole rigide sono

1. Non devi divulgare alcuna informazione attraverso la convalida che l'utente non dovrebbe essere altrimenti in grado di scoprire.
2. È necessario convalidare i dati prima che il controllo degli accessi possa utilizzarli nella misura in cui è necessario il controllo degli accessi.

Seguire entrambe queste regole può significare che devi avere qualche convalida prima e alcune dopo il controllo degli accessi.

Oltre alla possibile frustrazione derivante dal ricevere un input di convalida "accesso negato" dopo ; ricorda anche che il livello Validation , a meno che non sia molto semplice, può sempre avere bisogno di informazioni dal Controller . Tenendo questo a mente, credo che posizionare Validazione dietro Controllo accesso , più vicino a Controller abbia più senso.

Dipende da cosa intendi per livello di validazione - se con ciò intendi semplicemente controllare la sintassi della richiesta, è sicuro e devi comunque fare qualcosa. Se la tua "validazione" utilizza qualsiasi informazione a cui un utente non privilegiato non ha accesso, non è più sicura.

Dovresti sicuramente avere un verificatore di integrità prima di tentare il controllo degli accessi, ma dovresti fare attenzione a comunicare molto chiaramente a tutti i manutentori (attuali e futuri) che questa parte non utilizzare le informazioni privilegiate; Qualsiasi controllo di questo tipo dovrebbe essere eseguito in una fase di convalida separata dopo l'autenticazione .

Come controllo di integrità per il correttore di integrità, non dovrebbe in realtà avere alcuna dipendenza da codice su alcuna parte del codice più in basso nella pipeline e dovrebbe essere separabile nel proprio pacchetto che dovrebbe essere pubblicamente pubblicabile senza problemi (se non possibile questioni legali). Se non puoi farlo, il tuo "livello di validazione" sta facendo troppo (o la tua base di codice è un disastro).

No. Non è ok.

Se hai un bug nel tuo livello di validazione, potrebbe ignorare il livello di sicurezza.

È un errore comune considerare la sicurezza come parte dei requisiti aziendali. "Solo gli utenti con il ruolo di vendita, dovrebbero essere in grado di vedere le cifre trimestrali" sembra una regola aziendale.

Ma se vuoi essere sicuro, devi leggere una regola come "solo gli utenti nel ruolo di vendita, dovrebbero essere in grado di eseguire il codice su questo endpoint" Hai assicurato che il tuo server restituisca sempre "accesso negato" prima arriva a qualsiasi tipo di codice che hai scritto o file sul server.