Domanda 403 Forbidden vs 401 Risposte HTTP non autorizzate


Per una pagina Web esistente, ma per la quale un utente che non dispone di privilegi sufficienti (non ha effettuato l'accesso o non appartiene al gruppo di utenti appropriato), qual è la risposta HTTP appropriata da servire? 401? 403? Qualcos'altro? Quello che ho letto su ciascuno finora non è molto chiaro sulla differenza tra i due. Quali casi d'uso sono appropriati per ciascuna risposta?


1894
2017-07-21 07:21


origine


risposte:


Una chiara spiegazione da Daniel Irvine:

C'è un problema con 401 non autorizzato, il codice di stato HTTP per errori di autenticazione. E basta: è per l'autenticazione, non per l'autorizzazione.   Ricevere una risposta 401 è il server che ti dice "non lo sei   autenticato, non autenticato o autenticato   in modo errato, ma per favore riautenticare e riprovare. "Per aiutarti,   includerà sempre a WWW-Authenticate intestazione che descrive come   per autenticare.

Questa è una risposta generalmente restituita dal tuo server web, non dal tuo web   applicazione.

È anche qualcosa di molto temporaneo; il server ti sta chiedendo di provare   ancora.

Quindi, per l'autorizzazione uso il 403 Proibito risposta. Suo   permanente, è legato alla mia logica applicativa, ed è più concreto   risposta di un 401.

Ricevere una risposta 403 è il server che ti dice: "Mi dispiace. lo so   chi sei, io credo a chi dici di essere, ma tu semplicemente non hai   permesso di accedere a questa risorsa. Forse se chiedi al sistema   amministratore bene, avrai il permesso. Ma per favore non disturbarti   ancora una volta finché la tua situazione non cambierà. "

In breve, a 401 non autorizzato la risposta dovrebbe essere usata per mancare   o cattiva autenticazione e a 403 Proibito la risposta dovrebbe essere usata   in seguito, quando l'utente è autenticato ma non autorizzato   eseguire l'operazione richiesta sulla risorsa specificata.

Un altro bel formato pittorico di come dovrebbero essere usati i codici di stato http


2826
2017-08-04 06:24



Vedere RFC2616:

401 non autorizzato:

Se la richiesta includeva già le credenziali di autorizzazione, la risposta 401 indica che l'autorizzazione è stata rifiutata per tali credenziali.

403 Proibito:

Il server ha compreso la richiesta, ma si rifiuta di soddisfarla.

Aggiornare

Dal tuo caso d'uso, sembra che l'utente non sia autenticato. Vorrei restituire 401.


Modificare: RFC2616 è obsoleto, vedi RFC7231 e RFC7235.


336
2017-07-21 07:28



Mancano le altre risposte è che deve essere compreso che l'autenticazione e l'autorizzazione nel contesto di RFC 2616 si riferisce SOLO al protocollo di autenticazione HTTP di RFC 2617. L'autenticazione da schemi esterni a RFC2617 non sono supportate nei codici di stato HTTP e non sono considerate al momento di decidere se utilizzare 401 o 403 ..

Breve e conciso

Non autorizzato indica che il client non è autenticato da RFC2617 e che il server sta avviando il processo di autenticazione. Forbidden indica che il client è autenticato RFC2617 e non ha autorizzazione o che il server non supporta RFC2617 per la risorsa richiesta.

Ciò significa che se si dispone del proprio processo di login roll-your-own e non si utilizza mai l'autenticazione HTTP, 403 è sempre la risposta corretta e 401 non dovrebbe mai essere utilizzato.

Dettagliato e approfondito

Da RFC2616

10.4.2 401 Non autorizzato

La richiesta richiede l'autenticazione dell'utente. La risposta DEVE includere un campo di intestazione Autenticato WWW (sezione 14.47) contenente una sfida applicabile alla risorsa richiesta. Il cliente PU MAY ripetere la richiesta con un campo di intestazione Autorizzazione adatto (sezione 14.8).

e

10.4.4 403 Proibito   Il server ha compreso la richiesta, ma si rifiuta di soddisfarla. L'autorizzazione non aiuterà e la richiesta NON DEVE essere ripetuta.

La prima cosa da tenere a mente è che "Autenticazione" e "Autorizzazione" nel contesto di questo documento si riferiscono specificamente ai protocolli di autenticazione HTTP di RFC 2617. Non si riferiscono a protocolli di autenticazione roll-your-own che potresti aver creato utilizzando le pagine di accesso, ecc. Userò "login" per fare riferimento all'autenticazione e all'autorizzazione con metodi diversi da RFC2617

Quindi la vera differenza non è quale sia il problema o anche se esiste una soluzione. La differenza è ciò che il server si aspetta che il client faccia dopo.

401 indica che la risorsa non può essere fornita, ma il server RICHIEDE che il client esegua l'accesso tramite l'autenticazione HTTP e abbia inviato intestazioni di risposta per avviare il processo. Forse ci sono autorizzazioni che permetteranno l'accesso alla risorsa, forse non ci sono, ma proviamo a dare un'occhiata e vediamo cosa succede.

403 indica che la risorsa non può essere fornita e che, per l'utente corrente, non c'è modo di risolverlo tramite RFC2617 e senza tentare. Ciò può essere dovuto al fatto che è noto che nessun livello di autenticazione è sufficiente (ad esempio a causa di una lista nera IP), ma potrebbe essere dovuto al fatto che l'utente è già autenticato e non ha autorità. Il modello RFC2617 è di tipo one-user e one-credential, quindi il caso in cui l'utente possa disporre di un secondo set di credenziali che potrebbero essere autorizzate potrebbe essere ignorato. Non suggerisce né implica che una qualche pagina di login o un altro protocollo di autenticazione non RFC2617 possa o non possa essere d'aiuto - che è al di fuori degli standard e della definizione dell'RFC2616.


Modificare: RFC2616 è obsoleto, vedi RFC7231 e RFC7235.


254
2018-02-05 17:14



Secondo RFC 2616 (HTTP / 1.1) 403 viene inviato quando:

Il server ha compreso la richiesta, ma si rifiuta di soddisfarla. L'autorizzazione non aiuterà e la richiesta NON DEVE essere ripetuta. Se il metodo di richiesta non era HEAD e il server desidera rendere pubblico perché la richiesta non è stata soddisfatta, DOVREBBE descrivere il motivo del rifiuto nell'entità. Se il server non desidera rendere queste informazioni disponibili al client, è possibile utilizzare il codice di stato 404 (non trovato)

In altre parole, se il client PU CAN ottenere l'accesso alla risorsa mediante l'autenticazione, è necessario inviare 401.


94
2017-07-21 07:26



TL, versione DR

    Ottieni risorse, esiste?
    | |
    | |
    v v
NO: 404 SÌ: è autenticato?
             | |
             | |
             v v
           NO: 401 SÌ: può accedere alla risorsa?
           (o: 404) | |
           o 301 | |
           reindirizzamento v v
           per effettuare il login NO: 403 OK 200, 301, ...

I controlli vengono solitamente eseguiti in questo ordine:

  • 401 se non registrato o sessione scaduta
  • 403 se l'utente non ha il permesso di accedere alla risorsa
  • 404 se la risorsa non esiste

NON AUTORIZZATO: Codice di stato (401) che indica che la richiesta richiede autenticazione. Utente / agente sconosciuto dal server. Può ripetere con altre credenziali. NOTA: Ciò è fonte di confusione in quanto avrebbe dovuto essere denominato "non autenticato" anziché "non autorizzato".

PROIBITO: Codice di stato (403) che indica che il server ha compreso la richiesta ma si è rifiutato di soddisfarla. Utente / agente conosciuto dal server ma ha credenziali insufficienti. La ripetizione della richiesta non funzionerà.

NON TROVATO: Codice di stato (404) che indica che la risorsa richiesta non è disponibile. Utente / agente noto ma il server non rivelerà nulla sulla risorsa, fa come se non esistesse. La ripetizione non funzionerà. Questo è un uso speciale di 404 (github lo fa per esempio).


45
2018-02-23 11:00



Se l'autenticazione come un altro utente concederebbe l'accesso alla risorsa richiesta, dovrebbe essere restituito 401 Non autorizzato. 403 Forbidden viene utilizzato principalmente quando l'accesso alla risorsa è vietato a tutti o limitato a una determinata rete o consentito solo su SSL, indipendentemente dal fatto che non sia correlato all'autenticazione.

Da RFC 7235 (Hypertext Transfer Protocol (HTTP / 1.1): autenticazione):

3.1. 401 non autorizzato

Il codice di stato 401 (Non autorizzato) indica che la richiesta ha   non è stato applicato perché non ha credenziali di autenticazione valide   per la risorsa di destinazione. Il server di origine DEVE inviare a   Campo di intestazione dell'autenticazione WWW (sezione 4.4) contenente almeno uno   sfida applicabile alla risorsa target. Se la richiesta   incluse le credenziali di autenticazione, quindi la risposta 401   indica che l'autorizzazione è stata rifiutata per quelli   credenziali. Il cliente PU MAY ripetere la richiesta con un nuovo o   sostituito campo di intestazione di autorizzazione (sezione 4.1). Se il 401   la risposta contiene la stessa sfida della risposta precedente e il   l'agente utente ha già tentato l'autenticazione almeno una volta, quindi   l'agente utente DOVREBBE presentare la rappresentazione allegata al   utente, poiché di solito contiene informazioni diagnostiche pertinenti.

E questo è da RFC 2616:

10.4.4 403 Proibito

Il server ha compreso la richiesta, ma si rifiuta di soddisfarla.
L'autorizzazione non aiuterà e la richiesta NON DEVE essere ripetuta.
  Se il metodo di richiesta non era HEAD e il server desidera effettuare
  pubblico perché la richiesta non è stata soddisfatta, DOVREBBE descrivere il   motivo del rifiuto nell'entità. Se il server non lo desidera   rendere queste informazioni disponibili al client, il codice di stato 404
  (Non trovato) può essere usato invece.

Modifica: RFC 7231 (Hypertext Transfer Protocol (HTTP / 1.1): semantica e contenuto) modifica il significato di 403:

6.5.3. 403 Proibito

Il codice di stato 403 (Proibito) indica che il server   capito la richiesta ma si rifiuta di autorizzarlo. Un server che   desidera rendere pubblico il motivo per cui la richiesta è stata vietata   descrivere questo motivo nel carico utile della risposta (se presente).

Se le credenziali di autenticazione sono state fornite nella richiesta, il
  il server li considera insufficienti per garantire l'accesso. Il cliente
  NON DOVREBBE ripetere automaticamente la richiesta con lo stesso
  credenziali. Il cliente PU MAY ripetere la richiesta con nuovi o diversi   credenziali. Tuttavia, una richiesta potrebbe essere vietata per motivi
  estraneo alle credenziali.

Un server di origine che desidera "nascondere" l'esistenza corrente di a
  la risorsa bersaglio proibita può invece rispondere con un codice di stato di
  404 non trovato).

Quindi, un 403 potrebbe significare ora qualsiasi cosa. Fornire nuove credenziali potrebbe aiutare ... o potrebbe non farlo.


37
2018-02-27 09:44



Questa è una domanda più vecchia, ma una opzione che non è mai stata veramente sollevata è stata quella di restituire un 404. Dal punto di vista della sicurezza, la risposta più votata soffre di un potenziale vulnerabilità di fuga di informazioni. Supponiamo, ad esempio, che la pagina Web protetta in questione sia una pagina di amministrazione del sistema o, più comunemente, un record in un sistema a cui l'utente non ha accesso. Idealmente non vorresti che un utente malintenzionato sapesse che c'è una pagina o un record lì, figuriamoci che non hanno accesso. Quando creerò qualcosa di simile, cercherò di registrare richieste non autenticate / non autorizzate in un registro interno, ma restituirò un 404.

OWASP ne ha alcuni maggiori informazioni su come un utente malintenzionato potrebbe utilizzare questo tipo di informazioni come parte di un attacco.


20
2017-12-25 09:09



Questa domanda è stata posta qualche tempo fa, ma il modo di pensare delle persone va avanti.

Sezione 6.5.3 in questo progetto (creato da Fielding e Reschke) il codice di stato 403 ha un significato leggermente diverso da quello documentato in RFC 2616.

Riflette ciò che accade negli schemi di autenticazione e autorizzazione utilizzati da numerosi server Web e framework popolari.

Ho sottolineato il bit che ritengo più saliente.

6.5.3. 403 Proibito

Il codice di stato 403 (Proibito) indica che il server ha compreso la richiesta ma si rifiuta di autorizzarlo. Un server che desidera rendere pubblico il motivo per cui la richiesta è stata vietata può descriverne il motivo nel carico di risposta (se presente).

Se nella richiesta sono state fornite credenziali di autenticazione, il server le considera insufficienti per concedere l'accesso. Il cliente NON DOVREBBE ripetere la richiesta con le stesse credenziali. Il cliente PU MAY ripetere la richiesta con credenziali nuove o diverse.  Tuttavia, una richiesta potrebbe essere vietata per ragioni estranee alle credenziali.

Un server di origine che desideri "nascondere" l'esistenza corrente di una risorsa bersaglio proibita può invece rispondere con un codice di stato 404 (non trovato).

Qualunque sia la convenzione che usi, l'importante è fornire uniformità sul tuo sito / API.


19
2018-05-22 10:54



TL; DR

  • 401: un rifiuto che ha a che fare con l'autenticazione
  • 403: un rifiuto che NON ha NIENTE da fare con l'autenticazione

Esempi pratici

Se apache  richiede l'autenticazione (attraverso .htaccess), e tu colpisci Cancel, risponderà con a 401 Authorization Required

Se nginx trova un file, ma non ha diritti di accesso (utente / gruppo) per leggerlo / accedervi, risponderà con 403 Forbidden

RFC (2616 sezione 10)

401 Non autorizzato (10.4.2)

Significato 1: Hai bisogno di autenticarti

La richiesta richiede l'autenticazione dell'utente. ...

Significato 2: Autenticazione insufficiente

... Se la richiesta includeva già le credenziali di autorizzazione, la risposta 401 indica che l'autorizzazione è stata rifiutata per tali credenziali. ...

403 Proibito (10.4.4)

Senso: Non correlato all'autenticazione

... L'autorizzazione non aiuterà ...

Più dettagli:

  • Il server ha compreso la richiesta, ma si rifiuta di soddisfarla.

  • DOVREBBE descrivere il motivo del rifiuto nell'entità

  • È possibile utilizzare invece il codice di stato 404 (non trovato)

    (Se il server vuole mantenere queste informazioni dal client)


9
2018-02-25 09:03



non sono registrati o non appartengono al gruppo utenti appropriato

Hai dichiarato due casi diversi; ogni caso dovrebbe avere una risposta diversa:

  1. Se non hanno effettuato il login, dovresti tornare 401 non autorizzato
  2. Se sono collegati ma non appartengono al gruppo utenti appropriato, è necessario tornare 403 Proibito

7
2017-10-01 14:34