Vraag 403 Verboden versus 401 Ongeautoriseerde HTTP-responsen


Voor een webpagina die bestaat, maar waarvoor een gebruiker die niet over voldoende rechten beschikt ((ze zijn niet aangemeld of behoren niet tot de juiste gebruikersgroep), wat is de juiste HTTP-reactie die moet worden weergegeven? 401? 403? Iets anders? Wat ik tot nu toe over heb gelezen, is niet erg duidelijk over het verschil tussen beide. Welke use-cases zijn geschikt voor elk antwoord?


1896
2017-07-21 07:21


oorsprong


antwoorden:


Een duidelijke verklaring van Daniel Irvine:

Er is een probleem met 401 Onbevoegd, de HTTP-statuscode voor authenticatiefouten. En dat is het maar: het is voor authenticatie, geen autorisatie.   Als een 401-antwoord wordt ontvangen, zegt de server dat u dat niet bent   geverifieerd - ofwel helemaal niet geverifieerd of geverifieerd   onjuist, maar geef alsjeblieft opnieuw op en probeer het opnieuw. "Om je te helpen,   het bevat altijd een WWW-Authenticate kop die beschrijft hoe   om te authenticeren.

Dit is een reactie die doorgaans wordt geretourneerd door uw webserver, niet door uw internet   toepassing.

Het is ook iets heel tijdelijk; de server vraagt ​​je om te proberen   nog een keer.

Dus, voor toestemming gebruik ik de 403 verboden respons. Haar   permanent, het is gekoppeld aan mijn applicatielogica en het is concreter   antwoord dan een 401.

Het ontvangen van een antwoord van 403 is de server die zegt: "Het spijt me. ik weet   wie je bent - ik geloof wie je zegt dat je bent - maar je hebt het gewoon niet   toestemming voor toegang tot deze bron. Misschien als je het systeem vraagt   beheerder, je krijgt toestemming. Maar doe alsjeblieft niet de moeite   ik weer tot je hachelijke situatie verandert. "

Samenvattend, a 401 Onbevoegd antwoord moet worden gebruikt voor ontbrekend   of slechte authenticatie, en a 403 verboden antwoord moet worden gebruikt   achteraf, wanneer de gebruiker is geverifieerd maar niet bevoegd is om dit te doen   voer de gevraagde bewerking uit op de gegeven bron.

Een ander mooi picturaal formaat van hoe http-statuscodes moeten worden gebruikt.


2828
2017-08-04 06:24



Zien RFC2616:

401 Onbevoegd:

Als het verzoek al autorisatiegegevens bevatte, geeft het 401-antwoord aan dat de autorisatie is geweigerd voor die inloggegevens.

403 verboden:

De server heeft het verzoek begrepen, maar weigert hieraan te voldoen.

Bijwerken

Uit uw use-case blijkt dat de gebruiker niet is geverifieerd. Ik zou 401 teruggeven.


Bewerk: RFC2616 is verouderd, zie RFC7231 en RFC7235.


336
2017-07-21 07:28



Iets wat de andere antwoorden missen, is dat moet worden begrepen dat authenticatie en autorisatie in de context van RFC 2616 ALLEEN verwijst naar het HTTP-authenticatieprotocol van RFC 2617. Authenticatie door schema's buiten RFC2617 worden niet ondersteund in HTTP-statuscodes en worden niet beschouwd als bij het beslissen of 401 of 403 te gebruiken ..

Kort en bondig

Onbevoegd geeft aan dat de client niet RFC2617 is geverifieerd en dat de server het authenticatieproces start. Verboden geeft aan dat de client is geverifieerd met RFC2617 en geen autorisatie heeft of dat de server RFC2617 niet ondersteunt voor de gevraagde bron.

Dit betekent dat als u uw eigen roll-your-own login-proces hebt en nooit HTTP-verificatie gebruikt, 403 altijd de juiste reactie is en 401 nooit mag worden gebruikt.

Gedetailleerd en diepgaand

Van RFC2616

10.4.2 401 Niet geautoriseerd

Het verzoek vereist gebruikersauthenticatie. Het antwoord MOET een WWW-authentificatiekoptekstveld bevatten (sectie 14.47) met een uitdaging die van toepassing is op de gevraagde bron. De client MAG het verzoek herhalen met een geschikt veld Autorisatiekop (sectie 14.8).

en

10.4.4 403 Verboden   De server heeft het verzoek begrepen, maar weigert hieraan te voldoen. Autorisatie zal niet helpen en het verzoek MOET NIET worden herhaald.

Het eerste ding om in gedachten te houden is dat "Authenticatie" en "Autorisatie" in de context van dit document specifiek verwijzen naar de HTTP-authenticatieprotocollen van RFC 2617. Ze verwijzen niet naar roll-your-own authenticatieprotocollen die u mogelijk hebt gemaakt met inlogpagina's, enz. Ik zal "login" gebruiken om te verwijzen naar authenticatie en autorisatie door andere methoden dan RFC2617

Het echte verschil is dus niet wat het probleem is of zelfs als er een oplossing is. Het verschil is wat de server verwacht dat de klant vervolgens zal doen.

401 geeft aan dat de resource niet kan worden verstrekt, maar de server REQUESTING dat de client zich aanmeldt via HTTP-verificatie en antwoordkoppen heeft verzonden om het proces te starten. Mogelijk zijn er autorisaties die toegang tot de bron mogelijk maken, mogelijk zijn er geen, maar laten we het eens proberen en zien wat er gebeurt.

403 geeft aan dat de resource niet kan worden geleverd en dat er voor de huidige gebruiker geen manier is om dit via RFC2617 op te lossen en heeft geen zin om te proberen. Dit kan zijn omdat bekend is dat geen verificatieniveau voldoende is (bijvoorbeeld vanwege een IP-blacklist), maar mogelijk omdat de gebruiker al is geverifieerd en geen autoriteit heeft. Het RFC2617-model is one-user, one-referentials, dus het geval waarin de gebruiker mogelijk een tweede reeks inloggegevens heeft die kunnen worden geautoriseerd, kan worden genegeerd. Het suggereert noch impliceert dat een of andere inlogpagina of ander niet-RFC2617-authenticatieprotocol al dan niet kan helpen - dat is buiten de RFC2616-normen en -definitie.


Bewerk: RFC2616 is verouderd, zie RFC7231 en RFC7235.


254
2018-02-05 17:14



Volgens RFC 2616 (HTTP / 1.1) 403 wordt verzonden wanneer:

De server heeft het verzoek begrepen, maar weigert hieraan te voldoen. Autorisatie zal niet helpen en het verzoek MOET NIET worden herhaald. Als de verzoekmethode niet HEAD was en de server openbaar wil maken waarom aan het verzoek niet is voldaan, MOET het de reden voor de weigering in de entiteit beschrijven. Als de server deze informatie niet beschikbaar wil maken voor de client, kan in plaats daarvan de statuscode 404 (Niet gevonden) worden gebruikt

Met andere woorden, als de client via authenticatie toegang krijgt tot de bron, moet 401 worden verzonden.


94
2017-07-21 07:26



TL; DR-versie

    GET-bron, bestaat?
    | |
    | |
    v v
NEE: 404 JA: is geverifieerd?
             | |
             | |
             v v
           NEE: 401 JA: Heeft u toegang tot de bron?
           (of: 404) | |
           of 301 | |
           omleiden v v
           inloggen NO: 403 OK 200, 301, ...

Cheques worden meestal in deze volgorde uitgevoerd:

  • 401 indien niet ingelogd of sessie verlopen
  • 403 als de gebruiker geen machtiging heeft voor toegang tot de bron
  • 404 als bron niet bestaat

ONGEAUTORISEERDE: Statuscode (401) die aangeeft dat het verzoek vereist authenticatie. Gebruiker / agent onbekend door de server. Kan herhalen met andere inloggegevens. OPMERKING: Dit is verwarrend omdat dit de naam 'niet-geverifieerd' had in plaats van 'ongeautoriseerd'.

VERBODEN: Statuscode (403) om aan te geven dat de server het verzoek heeft begrepen maar heeft geweigerd dit te vervullen. Gebruiker / agent bekend bij de server maar wel onvoldoende inloggegevens. Herhalingsverzoek werkt niet.

NIET GEVONDEN: Statuscode (404) die aangeeft dat de gevraagde bron niet beschikbaar is. Gebruiker / agent bekend, maar de server zal niets over de bron onthullen, doet alsof het niet bestaat. Herhalen werkt niet. Dit is een speciaal gebruik van 404 (Github doet het bijvoorbeeld).


46
2018-02-23 11:00



Als verificatie als een andere gebruiker toegang zou verlenen tot de gevraagde bron, moeten 401 ongeautoriseerde gebruikers worden teruggestuurd. 403 Verboden wordt meestal gebruikt wanneer de toegang tot de bron voor iedereen verboden is of beperkt tot een bepaald netwerk of alleen via SSL toegestaan ​​is, wat ook geldt zolang het geen verband houdt met authenticatie.

Van RFC 7235 (Hypertext Transfer Protocol (HTTP / 1.1): verificatie):

3.1. 401 Onbevoegd

De 401 (niet-geautoriseerde) statuscode geeft aan dat het verzoek heeft   niet toegepast omdat het geen geldige authenticatiereferenties heeft   voor de doelbron. De oorsprongserver MOET een bericht verzenden   WWW-Authenticate header field (Section 4.4) bevat minstens één   uitdaging die van toepassing is op de doelresource. Als het verzoek   inclusief authenticatiereferenties en vervolgens het 401-antwoord   geeft aan dat daarvoor toestemming is geweigerd   geloofsbrieven. De klant KAN het verzoek herhalen met een nieuwe of   vervangen Autorisatiekop veld (Paragraaf 4.1). Als de 401   antwoord bevat dezelfde uitdaging als de eerdere reactie, en de   user-agent heeft toen al een keer geprobeerd authenticatie uit te voeren   de user-agent MOET de bijgevoegde weergave presenteren aan de   gebruiker, omdat deze meestal relevante diagnostische informatie bevat.

En dit komt van RFC 2616:

10.4.4 403 Verboden

De server heeft het verzoek begrepen, maar weigert hieraan te voldoen.
Autorisatie helpt niet en het verzoek MOET NIET worden herhaald.
  Als de aanvraagmethode niet HEAD was en de server wenst te maken
  publiek waarom het verzoek niet is voldaan, moet het de   reden voor de weigering in de entiteit. Als de server dat niet wil   deze informatie beschikbaar stellen aan de klant, de statuscode 404
  (Niet gevonden) kan in plaats daarvan worden gebruikt.

Bewerken: RFC 7231 (Hypertext Transfer Protocol (HTTP / 1.1): Semantics and Content) wijzigt de betekenis van 403:

6.5.3. 403 verboden

De 403 (Verboden) statuscode geeft aan dat de server   begrepen het verzoek maar weigert het te autoriseren. Een server die   wil openbaar maken waarom het verzoek is verboden   beschrijf die reden in de responspayload (indien aanwezig).

Als er verificatiereferenties zijn opgegeven in de aanvraag, moet de
  server beschouwt ze als onvoldoende om toegang te verlenen. De cliënt
  ZOU het verzoek NIET automatisch met hetzelfde moeten herhalen
  geloofsbrieven. De klant KAN het verzoek herhalen met nieuw of anders   geloofsbrieven. Een verzoek kan echter om redenen worden verboden
  niet gerelateerd aan de inloggegevens.

Een oorsprongsserver die het huidige bestaan ​​van a wil "verbergen"
  verboden doelbron KAN in plaats daarvan reageren met een statuscode van
  404 Niet Gevonden).

Dus een 403 kan nu alles betekenen. Het verstrekken van nieuwe referenties kan helpen ... of misschien niet.


37
2018-02-27 09:44



Dit is een oudere vraag, maar een optie die nooit echt ter sprake kwam, was om een ​​404 terug te sturen. Vanuit een beveiligingsperspectief lijdt het hoogst gestemde antwoord aan een potentieel informatie lekkage kwetsbaarheid. Stel dat de beveiligde webpagina in kwestie een systeembeheerderpagina is, of misschien vaker een record in een systeem waartoe de gebruiker geen toegang heeft. Idealiter zou je niet willen dat een kwaadwillende gebruiker zelfs weet dat daar een pagina / record staat, laat staan ​​dat ze geen toegang hebben. Wanneer ik zoiets bouw, zal ik proberen om niet-authentiek / ongeautoriseerde verzoeken op te nemen in een intern logboek, maar een 404 terugsturen.

OWASP heeft er een paar meer informatie over hoe een aanvaller dit soort informatie zou kunnen gebruiken als onderdeel van een aanval.


20
2017-12-25 09:09



Deze vraag werd enige tijd geleden gesteld, maar het denken van mensen gaat verder.

Paragraaf 6.5.3 in dit concept (geschreven door Fielding en Reschke) geeft statuscode 403 een enigszins andere betekenis aan de gedocumenteerde in RFC 2616.

Het geeft weer wat er gebeurt in authenticatie- en autorisatieschema's die worden gebruikt door een aantal populaire webservers en frameworks.

Ik heb het beetje benadrukt dat volgens mij het meest opvallend is.

6.5.3. 403 verboden

De 403 (Verboden) statuscode geeft aan dat de server het verzoek heeft begrepen maar weigert het te autoriseren. Een server die openbaar wil maken waarom het verzoek is verboden, kan die reden in de responspayload (indien aanwezig) beschrijven.

Als er verificatiereferenties zijn opgegeven in de aanvraag, beschouwt de server ze als onvoldoende om toegang te verlenen. De klant MOET de aanvraag NIET herhalen met dezelfde inloggegevens. De client KAN het verzoek herhalen met nieuwe of andere inloggegevens.  Een verzoek kan echter worden verboden om redenen die geen verband houden met de inloggegevens.

Een oorsprongserver die het huidige bestaan ​​van een verboden doelbron wil "verbergen" KAN in plaats daarvan antwoorden met een statuscode van 404 (Niet gevonden).

Welke conventie u ook gebruikt, het belangrijkste is om uniformiteit te bieden voor uw site / API.


19
2018-05-22 10:54