Pytanie 403 Forbidden vs 401 Nieautoryzowane odpowiedzi HTTP


W przypadku istniejącej strony internetowej, dla której użytkownik, który nie ma wystarczających uprawnień (nie jest zalogowany lub nie należy do właściwej grupy użytkowników), jaka jest właściwa odpowiedź HTTP do wyświetlenia? 401? 403? Coś innego? To, co do tej pory czytałem, nie jest zbyt jasne na temat różnicy między nimi dwoma. Jakie przypadki użycia są odpowiednie dla każdej odpowiedzi?


1905
2017-07-21 07:21


pochodzenie


401 "Nieautoryzowane" powinno być 401 "Nieukierunkowane", problem rozwiązany! - Christophe Roussy
Łał. Poniższe odpowiedzi są absurdalnie na całej mapie. Wygląda na to, że poprawna odpowiedź jest niezdefiniowana dla uwierzytelniania innego niż HTTP. - Joe Lapp
Nie pamiętam, ile razy ja i moi koledzy wróciliśmy do stackoverflow na to pytanie. Być może standardy HTTP powinny rozważyć modyfikację nazw lub opisów dla 401 i 403. - neurite
W rzeczywistości otrzymuję inną wersję tego błędu. jak "os_authType" był "any" i wysłano nieprawidłowy plik cookie ". Tak więc nie jest w stanie zrozumieć, jak to rozwiązać. Wyszukiwarka Google ma dużo czasu, ale ma powody, ale nie otrzymała rozwiązania. - Sandeep Anand
@Qwerty nie, nowy RFC7231 przestaje być RFC2616. 403 ma teraz inne znaczenie. - fishbone


Odpowiedzi:


Wyjaśnienie z Daniel Irvine:

Wystąpił problem z 401 Nieautoryzowane, kod statusu HTTP dla błędów uwierzytelniania. I to tylko to: służy do uwierzytelniania, a nie autoryzacji.   Otrzymanie odpowiedzi 401 to serwer, który mówi: "nie jesteś   uwierzytelniony - albo nie jest w ogóle uwierzytelniony, albo uwierzytelniony   niepoprawnie - ale proszę ponownie uwierzytelnij i spróbuj ponownie. "Aby pomóc Ci,   zawsze będzie zawierać Uwierzytelnianie WWW nagłówek opisujący sposób   uwierzytelnić.

Jest to odpowiedź generalnie zwracana przez serwer WWW, a nie przez sieć   podanie.

To także coś bardzo tymczasowego; serwer prosi o wypróbowanie   jeszcze raz.

Tak więc, do autoryzacji używam 403 Zabronione odpowiedź. Jego   stały, jest związany z moją logiką aplikacji i jest bardziej konkretny   odpowiedź niż 401.

Otrzymanie odpowiedzi 403 to serwer, który mówi: "Przykro mi. wiem   kim jesteś - wierzę w to, kim mówisz, ale po prostu nie masz   pozwolenie na dostęp do tego zasobu. Może, jeśli zapytasz system   ładnie administrator, dostaniesz pozwolenie. Ale proszę, nie zawracaj sobie głowy   mnie znowu, dopóki nie zmieni się twoja sytuacja.

Podsumowując, a 401 Nieautoryzowane Odpowiedź powinna być użyta jako brakująca   lub złe uwierzytelnianie, a 403 Zabronione odpowiedź powinna zostać wykorzystana   potem, gdy użytkownik jest uwierzytelniony, ale nie jest do tego upoważniony   wykonać żądaną operację na danym zasobie.

Inne ładny obrazkowy format w jaki sposób powinny być używane kody statusu HTTP.


2844
2017-08-04 06:24



Domyślny komunikat IIS 403 to "Jest to ogólny błąd 403 i oznacza, że ​​uwierzytelniony użytkownik nie ma uprawnień do wyświetlania strony", co wydaje się być zgodne. - Ben Challenor
@JPReddy Twoja odpowiedź jest poprawna. Oczekuję jednak, że 401 zostanie nazwane "Nieuwierzytelnione", a 403 - "Nieautoryzowane". Bardzo mylące jest to, że 401, który ma związek z uwierzytelnieniem, ma format tekstu towarzyszącego "Nieautoryzowany" ... chyba że nie jestem dobry po angielsku (co jest całkiem możliwe). - p.matsinopoulos
@ZaidMasud, zgodnie z RFC ta interpretacja nie jest poprawna. Odpowiedź Cumbayah miała rację. 401 oznacza "brakuje właściwej autoryzacji". Oznacza to "jeśli chcesz, możesz spróbować się uwierzytelnić". Tak więc zarówno klient, który nie uwierzytelnił się poprawnie, jak i klient poprawnie uwierzytelniony, który nie uzyskał autoryzacji, otrzyma 401. 403 oznacza "Nie odpowiem na to, kimkolwiek jesteś". RFC wyraźnie stwierdza, że ​​"autoryzacja nie pomoże" w przypadku 403. - Davide R.
401 to Błąd autoryzacji, 403 to Błąd autoryzacji. Proste. - Shahriyar Imanov
Zrezygnowałeś "Cóż, to mój pogląd na ten temat :)" podczas kopiowania ze swojego wpisu na blogu i niestety jego opinia jest błędna. Jak stwierdzili inni, 403 oznacza, że ​​nie możesz uzyskać dostępu do zasobu bez względu na to, kim jesteś uwierzytelniony. Zazwyczaj używam tego kodu statusu dla zasobów zablokowanych przez zakresy adresów IP lub pliki w moim webroot, że nie chcę bezpośredniego dostępu do nich (to znaczy, skrypt musi im służyć). - Kyle


Widzieć RFC2616:

401 Nieautoryzowane:

Jeśli żądanie zawiera już poświadczenia autoryzacji, odpowiedź 401 wskazuje, że autoryzacja została odrzucona dla tych poświadczeń.

403 Zabronione:

Serwer zrozumiał żądanie, ale odmawia jego spełnienia.

Aktualizacja

Z przypadku użycia okazuje się, że użytkownik nie jest uwierzytelniony. Chciałbym zwrócić 401.


Edytować: RFC2616 jest przestarzały, patrz RFC7231 i RFC7235.


336
2017-07-21 07:28



Dzięki, to pomogło mi to wyjaśnić. Używam obu - 401 dla nieuwierzytelnionych użytkowników, 403 dla uwierzytelnionych użytkowników z niewystarczającymi uprawnieniami. - VirtuosiMedia
Nie spadłem, ale uważam, że ta odpowiedź jest dość myląca. 403 zabronione jest bardziej odpowiednie w treściach, które nigdy nie będą wyświetlane (np. Pliki .config w asp.net). jego albo to, albo 404. imho, nie byłoby właściwe zwracanie 403 za coś, do czego można uzyskać dostęp, ale po prostu nie masz odpowiednich referencji. moim rozwiązaniem byłoby podanie komunikatu odmowy dostępu z możliwością zmiany danych uwierzytelniających. to lub 401. - Mel
"Odpowiedź MUSI zawierać pole nagłówka Uwierzytelnianie WWW (sekcja 14.47) zawierające wyzwanie dotyczące żądanego zasobu." Wydaje się, że jeśli nie chcesz używać uwierzytelniania w stylu HTTP, kod odpowiedzi 401 nie jest właściwy. - Brilliand
Wrócę Billiand tutaj. Oświadczenie brzmi "Jeśli wniosek zawiera już poświadczenia autoryzacji". Oznacza to, że jest to odpowiedź z żądania, które dostarczyło referencję (np. Odpowiedź z próby uwierzytelnienia RFC2617). Zasadniczo pozwala to serwerowi powiedzieć: "Złe konto / hasło, spróbuj ponownie". W postawionym pytaniu użytkownik jest prawdopodobnie uwierzytelniony, ale nie autoryzowany. 401 nigdy nie jest właściwą odpowiedzią na te okoliczności. - ldrut
Brilliand ma rację, 401 jest odpowiedni tylko do uwierzytelniania HTTP. - Juampi


Brakuje innych odpowiedzi, należy zrozumieć, że uwierzytelnianie i autoryzacja w kontekście RFC 2616 odnosi się TYLKO do protokołu uwierzytelniania HTTP RFC 2617. Uwierzytelnianie przez schematy spoza RFC2617 nie jest obsługiwane w kodach statusu HTTP i nie są uznawane przy podejmowaniu decyzji, czy użyć 401 lub 403 ..

Brief i Terse

Nieautoryzowany oznacza, że ​​klient nie jest uwierzytelniony RFC2617, a serwer inicjuje proces uwierzytelniania. Zabronione wskazuje, że klient jest uwierzytelniony RFC2617 i nie ma autoryzacji lub że serwer nie obsługuje RFC2617 dla żądanego zasobu.

Oznacza to, że jeśli masz własny proces logowania przy użyciu funkcji roll-it-own i nigdy nie korzystasz z uwierzytelniania HTTP, 403 zawsze jest właściwą odpowiedzią, a 401 nigdy nie powinno być używane.

Szczegółowe i dogłębne

Z RFC2616

10.4.2 401 Nieautoryzowane

Żądanie wymaga uwierzytelnienia użytkownika. Odpowiedź MUSI zawierać pole nagłówka WWW-Authenticate (sekcja 14.47) zawierające wyzwanie dotyczące żądanego zasobu. Klient MOŻE powtórzyć żądanie z odpowiednim nagłówkiem Authorization (rozdział 14.8).

i

10.4.4 403 Zabronione   Serwer zrozumiał żądanie, ale odmawia jego spełnienia. Autoryzacja nie pomoże, a ŻĄDANIE NIE POWINNO się powtarzać.

Pierwszą rzeczą, o której należy pamiętać, jest to, że "Uwierzytelnianie" i "Autoryzacja" w kontekście tego dokumentu odnoszą się w szczególności do protokołów uwierzytelniania HTTP z RFC 2617. Nie dotyczą one żadnych protokołów uwierzytelniania roll-your-own, które mógłbyś utworzyć za pomocą stron logowania itd. Będę używał "login" w odniesieniu do uwierzytelniania i autoryzacji metodami innymi niż RFC2617

Tak więc prawdziwa różnica nie jest tym, czym jest problem, a nawet jeśli istnieje rozwiązanie. Różnica polega na tym, czego serwer oczekuje od klienta.

401 wskazuje, że zasób nie może zostać dostarczony, ale serwer żąda, aby klient logował się za pomocą uwierzytelniania HTTP i wysłał nagłówki odpowiedzi w celu zainicjowania procesu. Możliwe, że istnieją autoryzacje, które pozwolą na dostęp do zasobu, być może nie istnieją, ale spróbujmy i zobaczmy, co się stanie.

403 wskazuje, że zasób nie może zostać dostarczony i dla bieżącego użytkownika nie ma możliwości rozwiązania tego problemu przez RFC2617 i nie ma sensu próbować. Może to być spowodowane tym, że wiadomo, że żaden poziom uwierzytelnienia nie jest wystarczający (na przykład z powodu czarnej listy adresów IP), ale może to być spowodowane tym, że użytkownik jest już uwierzytelniony i nie ma uprawnień. Model RFC2617 jest jedno-użytkownika, jedno-poświadczeń, więc przypadek, w którym użytkownik może mieć drugi zestaw poświadczeń, które mogą być autoryzowane może być ignorowane. Nie sugeruje ani nie sugeruje, że jakaś strona logowania lub inny protokół uwierzytelniania inny niż RFC2617 może lub nie może pomóc - to jest poza standardami i definicją RFC2616.


Edytować: RFC2616 jest przestarzały, patrz RFC7231 i RFC7235.


254
2018-02-05 17:14



IMHO, to zdecydowanie najlepsza i najdokładniejsza odpowiedź. - Juampi
Co więc powinniśmy zrobić, gdy użytkownik zażąda strony wymagającej uwierzytelnienia innego niż http? Wysłać kod statusu 403? - marcovtwout
To jest odpowiedź, która odpowiedziała na moje pytania dotyczące rozróżnienia. - Patrick
Jest to ważne: "jeśli masz swój własny proces logowania i nigdy nie korzystasz z uwierzytelniania HTTP, 403 zawsze jest właściwą odpowiedzią, a 401 nigdy nie powinno być używane." - ggg
Czy RFC7235 nie zapewnia "rzutu własnego" lub alternatywnych wyzwań auth? Dlaczego przepływ logowania w mojej aplikacji nie stanowi wyzwania w postaci WWW-Authenticate nagłówek? Nawet jeśli przeglądarka go nie obsługuje, moja aplikacja React może ... - jchook


Według RFC 2616 (HTTP / 1.1) 403 jest wysyłany, gdy:

Serwer zrozumiał żądanie, ale odmawia jego spełnienia. Autoryzacja nie pomoże, a ŻĄDANIE NIE POWINNO się powtarzać. Jeżeli metoda żądania nie była HEAD i serwer chciałby podać do publicznej wiadomości, dlaczego żądanie nie zostało spełnione, POWINIEN opisać powód odmowy w jednostce. Jeśli serwer nie chce udostępnić tych informacji klientowi, można zamiast tego użyć kodu statusu 404 (Nie znaleziono)

Innymi słowy, jeśli klient MOŻE uzyskać dostęp do zasobu przez uwierzytelnienie, należy wysłać 401.


95
2017-07-21 07:26



A jeśli nie jest jasne, czy mogą uzyskać dostęp, czy nie? Załóżmy, że mam 3 poziomy użytkowników - Publiczny, Członkowie i Członkowie Premium. Załóżmy, że strona jest przeznaczona wyłącznie dla członków Premium. Użytkownik publiczny jest w zasadzie nieuwierzytelniony i mógłby być zalogowanym albo na Członku, albo Członku Premium. Dla użytkownika z poziomu członka 403 wydaje się odpowiednie. Dla Członków Premium, 401. Jak jednak służysz publiczności? - VirtuosiMedia
imho, to jest najdokładniejsza odpowiedź. zależy to od aplikacji, ale ogólnie, jeśli uwierzytelniony użytkownik nie ma wystarczających uprawnień do zasobu, możesz chcieć zapewnić sposób zmiany danych uwierzytelniających lub wysłać 401. Myślę, że 403 najlepiej nadaje się do treści, które nigdy nie są wyświetlane. W asp.net będzie to oznaczać pliki web.config pliki * .resx itp., Ponieważ bez względu na to, który użytkownik się zaloguje, pliki te NIGDY nie zostaną wyświetlone, więc nie ma sensu próbować ponownie. - Mel
Ta odpowiedź zasługuje na więcej awansów. Zgadzam się z @Mel. - Camilo Martin
+1, ale niepewna +1. Logicznym wnioskiem jest to, że 403 nigdy nie powinno być zwracane, ponieważ albo 401, albo 404 byłoby absolutnie lepszą odpowiedzią. - CurtainDog
@Mel Myślę, że plik, do którego klient nie powinien uzyskać dostępu, powinien być 404. Jest to plik, który jest wewnętrzny dla systemu; na zewnątrz nie powinien nawet wiedzieć, że istnieje. Zwracając 403, powiadamiasz klienta, że ​​istnieje, i nie musisz podawać tej informacji hakerom. Specyfikacja dla 403 mówi An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found). - Juan Mendes


Wersja TL; DR

    GET zasobu, istnieje?
    | |
    | |
    v v
NIE: 404 TAK: Czy jest uwierzytelniony?
             | |
             | |
             v v
           NIE: 401 TAK: Czy można uzyskać dostęp do zasobu?
           (lub: 404) | |
           lub 301 | |
           przekieruj v v
           zaloguj się NIE: 403 OK 200, 301, ...

Czeki są zwykle wykonywane w następującej kolejności:

  • 401 jeśli nie jest zalogowany lub sesja wygasła
  • 403, jeśli użytkownik nie ma uprawnień dostępu do zasobu
  • 404 jeśli zasób nie istnieje

NIEAUTORYZOWANY: Kod statusu (401) wskazujący, że żądanie jest wymagane poświadczenie. Użytkownik / agent nieznany przez serwer. Można powtórzyć z innymi danymi uwierzytelniającymi. UWAGA: To jest mylące, ponieważ powinno to być nazwane "nieuwierzytelnione" zamiast "nieautoryzowane".

ZABRONIONY: Kod statusu (403) wskazujący, że serwer zrozumiał żądanie, ale odmówił jego spełnienia. Użytkownik / agent znany przez serwer, ale ma niewystarczające dane uwierzytelniające. Powtarzające się żądanie nie zadziała.

NIE ZNALEZIONO: Kod statusu (404) wskazujący, że żądany zasób nie jest dostępny. Użytkownik / agent znany, ale serwer nie ujawni niczego na temat zasobu, robi tak, jakby go nie było. Powtarzanie nie działa. Jest to specjalne użycie 404 (github robi to na przykład).


46
2018-02-23 11:00



github.com/for-GET/http-decision-diagram - Christophe Roussy
Na przykład zalogowałem się i mogę uzyskać dostęp do strony, ale nie mam dla mnie włączonej uprawnień. Który kod statusu powróci? - barteloma
@ bookmarker Zaloguj się nazywa się uwierzytelnianie, co jest pierwszym krokiem. Więc jeśli nie masz pozwolenia po zalogowaniu, otrzymasz 403 zabronione (niewystarczające dane uwierzytelniające oznaczają, że nie masz wystarczających uprawnień). - Christophe Roussy
Jasne i proste wyjaśnienie. Właśnie to czego potrzebuje. - Estevez


Jeśli uwierzytelnienie jako inny użytkownik umożliwi dostęp do żądanego zasobu, należy zwrócić 401 Nieautoryzowane. 403 Zabroniony jest najczęściej używany, gdy dostęp do zasobu jest zabroniony dla wszystkich lub ograniczony do danej sieci lub dozwolony tylko przez SSL, o ile nie jest związany z uwierzytelnianiem.

Z RFC 7235 (Hypertext Transfer Protocol (HTTP / 1.1): Authentication):

3.1. 401 Nieautoryzowane

Kod stanu 401 (nieautoryzowany) wskazuje, że żądanie ma   nie został zastosowany, ponieważ nie ma prawidłowych poświadczeń uwierzytelniających   dla zasobu docelowego. Serwer źródłowy MUSI wysłać   Pole nagłówka WWW-Authenticate (sekcja 4.4) zawierające co najmniej jeden   wyzwanie mające zastosowanie do zasobu docelowego. Jeśli prośba   zawierał referencje uwierzytelniające, a następnie odpowiedź 401   wskazuje, że odmówiono im zezwolenia   kwalifikacje. Klient MOŻE powtórzyć żądanie z nowym lub   zastąpiono pole nagłówka autoryzacji (sekcja 4.1). Jeśli 401   odpowiedź zawiera to samo wyzwanie co poprzednia odpowiedź, a   agent użytkownika próbował już raz uwierzytelnienia, co najmniej raz   agent użytkownika POWINIEN przedstawić dołączoną reprezentację do   użytkownika, ponieważ zwykle zawiera odpowiednie informacje diagnostyczne.

A to z RFC 2616:

10.4.4 403 Zabronione

Serwer zrozumiał żądanie, ale odmawia jego spełnienia.
Autoryzacja nie pomoże a prośba NIE POWINNA powtórzyć.
  Jeśli metoda żądania nie jest HEAD i serwer chce dokonać
  publicznie, dlaczego wniosek nie został spełniony, POWINIEN opisać   powód odmowy w jednostce. Jeśli serwer nie chce   udostępnić tę informację klientowi, kod statusu 404
  (Nie znaleziono) może być użyty zamiast tego.

Edycja: RFC 7231 (Hypertext Transfer Protocol (HTTP / 1.1): Semantics and Content) zmienia znaczenie 403:

6.5.3. 403 Zabronione

Kod statusu 403 (Zabroniony) wskazuje, że serwer   zrozumiał wniosek, ale odmawia jego zatwierdzenia. Serwer, który   pragnie upublicznić, dlaczego wniosek jest zabroniony   opisz tę przyczynę w ładunku odpowiedzi (jeśli jest).

Jeśli w żądaniu podano poświadczenia uwierzytelniające, to
  serwer uważa je za niewystarczające do udzielenia dostępu. Klient
  NIE POWINIEN automatycznie powtarzać żądania z tym samym
  kwalifikacje. Klient MOŻE powtórzyć żądanie z nowym lub innym   kwalifikacje. Jednak żądanie może być zabronione z przyczyn
  niezwiązane z poświadczeniami.

Serwer źródłowy, który chce "ukryć" bieżące istnienie pliku a
  niedozwolony zasób docelowy MOŻE zamiast tego odpowiedzieć kodem statusu
  404 Nie Znaleziono).

Tak więc 403 może teraz oznaczać wszystko. Zapewnienie nowych poświadczeń może pomóc ... lub może nie.


37
2018-02-27 09:44



To jest interesujące. Opierając się na RFC 7231 i RFC 7235, nie widzę wyraźnego rozróżnienia między 401 a 403 - Brian
403 oznacza "Znam cię, ale nie możesz zobaczyć tego zasobu". Nie ma powodu do pomyłek. - Michael Blackburn
"Jeśli żądanie zawierało poświadczenia uwierzytelniające, odpowiedź 401 wskazuje, że odmówiono autoryzacji dla tych poświadczeń Klient może powtórzyć żądanie z nowym lub zastąpionym nagłówkiem Authorization (sekcja 4.1)." Jednakże, następnie "4.2. Pole nagłówka" Autoryzacja "umożliwia agentowi użytkownika uwierzytelnienie się z serwerem źródłowym". Wygląda na to, że w RFC7235 używają terminu "autoryzacja", tak jak było to "uwierzytelnianie". W takim przypadku może się wydawać, że uwierzytelniony, ale nieupoważniony użytkownik nie powinien otrzymać 401, ale 403 - arcuri82


Jest to starsze pytanie, ale jedną z opcji, która nigdy nie była tak naprawdę podniesiona, było zwrócenie 404. Z punktu widzenia bezpieczeństwa, najwyższa głosowana odpowiedź cierpi na potencjalne ryzyko. Usterka wycieku informacji. Powiedzmy na przykład, że bezpieczna strona internetowa, o której mowa, to strona administratora systemu, a może częściej jest to rekord w systemie, do którego użytkownik nie ma dostępu. Idealnie nie chciałbyś, aby złośliwy użytkownik wiedział, że jest tam strona / rekord, nie mówiąc już o tym, że nie ma do nich dostępu. Kiedy buduję coś takiego, spróbuję nagrać nieautoryzowane / nieautoryzowane żądania w dzienniku wewnętrznym, ale zwrócę 404.

OWASP ma kilka więcej informacji o tym, w jaki sposób atakujący może użyć tego typu informacji w ramach ataku.


20
2017-12-25 09:09



Zastosowanie 404 zostało wymienione w poprzednich odpowiedziach. Jesteś na punkcie re: wyciek informacji i to powinno być ważnym czynnikiem dla każdego, kto przetworzy własny schemat uwierzytelniania / autoryzacji. +1 za wymienienie OWASP. - Dave Watts


To pytanie zostało zadane jakiś czas temu, ale myślenie ludzi idzie dalej.

Sekcja 6.5.3 w tym projekcie (autor: Fielding i Reschke) nadaje kodowi statusu 403 nieco inne znaczenie niż ten udokumentowany w RFC 2616.

Odzwierciedla to, co dzieje się w programach uwierzytelniania i autoryzacji używanych przez wiele popularnych serwerów internetowych i frameworków.

Podkreśliłem to, co uważam za najbardziej istotne.

6.5.3. 403 Zabronione

Kod statusu 403 (Forbidden) wskazuje, że serwer zrozumiał żądanie, ale odmawia autoryzacji. Serwer, który chce upublicznić, dlaczego żądanie zostało zabronione, może opisać ten powód w ładunku odpowiedzi (jeśli taki istnieje).

Jeśli w żądaniu podano dane uwierzytelniające, serwer uzna je za niewystarczające do udzielenia dostępu. Klient NIE POWINIEN powtarzać żądania z tymi samymi danymi uwierzytelniającymi. Klient MOŻE powtórzyć żądanie z nowymi lub innymi danymi uwierzytelniającymi.  Jednak żądanie może być zabronione z przyczyn niezwiązanych z poświadczeniami.

Serwer źródłowy, który chce "ukryć" bieżące istnienie zabronionego zasobu docelowego MAY zamiast tego odpowiedzieć kodem statusu 404 (Nie znaleziono).

Bez względu na to, jakiej konwencji używasz, ważne jest zapewnienie jednolitości całej witryny / interfejsu API.


19
2018-05-22 10:54



Projekt został zatwierdzony i obecnie jest RFC 7231. - Vebjorn Ljosa