403 Zabronione vs 401 Nieautoryzowane odpowiedzi HTTP


2782

W przypadku strony internetowej, która istnieje, ale dla której użytkownik nie ma wystarczających uprawnień (nie jest zalogowany lub nie należy do odpowiedniej grupy użytkowników), jaka jest poprawna odpowiedź HTTP do wyświetlenia?

401 Unauthorized?
403 Forbidden?
Coś innego?

To, co do tej pory przeczytałem, nie jest bardzo jasne na temat różnicy między nimi. Jakie przypadki użycia są odpowiednie dla każdej odpowiedzi?


358
401 „Nieautoryzowane” powinno być 401 „Nieautoryzowane”, problem rozwiązany!
Christophe Roussy

47
Nie pamiętam, ile razy ja i moi koledzy wracaliśmy do przepełnienia stosu dla tego pytania. 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ł„ dowolny ”i wysłano nieprawidłowe ciasteczko”. Więc nie jestem w stanie dowiedzieć się, jak to rozwiązać. Googlowałem dużo czasu, miałem powody, ale nie znalazłem rozwiązania.
Sandeep Anand

@ Qwerty nie, nowy RFC7231 przestarzały RFC2616. 403 ma teraz inne znaczenie.
fishbone

1
@ fishbone również nie zauważyłeś, że kod statusu 401 został usunięty z tego RFC: D
Barkermn01

Odpowiedzi:


4111

Jasne wyjaśnienie Daniela Irvine :

Wystąpił problem z 401 Nieautoryzowanym , kodem stanu HTTP dla błędów uwierzytelnienia. I to wszystko: służy do uwierzytelnienia, a nie do autoryzacji. Otrzymanie odpowiedzi 401 oznacza, że ​​serwer mówi: „nie jesteś uwierzytelniony - albo nie jest wcale uwierzytelniony, albo jest uwierzytelniony nieprawidłowo - ale powtórz uwierzytelnienie i spróbuj ponownie”. Aby ci pomóc, zawsze będzie zawierał nagłówek uwierzytelniania WWW, który opisuje sposób uwierzytelnienia.

Jest to odpowiedź zwykle zwracana przez serwer internetowy, a nie aplikację internetową.

Jest to również coś bardzo tymczasowego; serwer prosi o ponowną próbę.

Tak więc do autoryzacji używam odpowiedzi 403 Forbidden . Jest stały, związany z moją logiką aplikacji i jest bardziej konkretną odpowiedzią niż 401.

Otrzymanie odpowiedzi 403 oznacza, że ​​serwer mówi: „Przykro mi. Wiem, kim jesteś - wierzę, kim jesteś, ale po prostu nie masz pozwolenia na dostęp do tego zasobu. Może jeśli poprosisz administratora systemu ładnie, otrzymasz pozwolenie. Ale proszę, nie zawracaj mi głowy, dopóki nie zmieni się twoje położenie.

Podsumowując, należy użyć nieautoryzowanej odpowiedzi 401 w przypadku braku lub złego uwierzytelnienia, a następnie odpowiedzi 403 Zabronionej należy użyć, gdy użytkownik jest uwierzytelniony, ale nie ma uprawnień do wykonania żądanej operacji na danym zasobie.

Kolejny ładny obrazowy sposób, w jaki należy stosować kody stanu HTTP.

wprowadź opis zdjęcia tutaj


43
Domyślny komunikat IIS 403 to „Jest to ogólny błąd 403 i oznacza, że ​​uwierzytelniony użytkownik nie ma uprawnień do przeglądania strony”, co wydaje się zgadzać.
Ben Challenor

333
@JPReddy Twoja odpowiedź jest poprawna. Spodziewałbym się jednak, że 401 zostanie nazwany „Nieautoryzowany”, a 403 będzie nazwany „Nieautoryzowany”. To bardzo mylące, że 401, który ma związek z uwierzytelnianiem, ma format towarzyszący tekstowi „Nieautoryzowane”… Chyba że nie jestem dobry w języku angielskim (co jest całkiem możliwe).
p.matsinopoulos

64
@ZaidMasud, zgodnie z RFC interpretacja ta jest nieprawidłowa. Odpowiedź Cumbayaha dobrze się zgadza. 401 oznacza „brakuje odpowiedniej 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 odpowiednio uwierzytelniony klient, który nie ma 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.

84
401 to błąd uwierzytelnienia, 403 to błąd autoryzacji. Proste.
Shahriyar Imanov

30
Pominąłeś „Cóż, w każdym razie to moje zdanie :)” podczas kopiowania z jego postu na blogu i niestety jego pogląd jest błędny. Jak twierdzą 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 stanu dla zasobów zablokowanych przez zakresy adresów IP lub pliki w moim katalogu głównym, do których nie chcę bezpośredniego dostępu (tzn. Skrypt musi je obsługiwać).
Kyle

402

Zobacz RFC2616 :

401 Nieautoryzowane:

Jeśli żądanie zawierało już poświadczenia autoryzacji, wówczas odpowiedź 401 wskazuje, że odmówiono autoryzacji tych poświadczeń.

403 Zabronione:

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

Aktualizacja

Z twojego przypadku użycia wydaje się, że użytkownik nie jest uwierzytelniony. Zwróciłbym 401.


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


21
Dzięki, 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,

52
Nie przegłosowałem, ale uważam tę odpowiedź za mylącą. 403 zabronione jest bardziej odpowiednio wykorzystywane w treściach, które nigdy nie będą wyświetlane (jak pliki .config w asp.net). albo to, albo 404. imho, nie byłoby właściwe zwracać 403 za coś, do czego można uzyskać dostęp, ale po prostu nie masz odpowiednich poświadczeń. moim rozwiązaniem byłoby przekazanie komunikatu o odmowie dostępu w celu zmiany poświadczeń. that or a 401.
Mel

27
„Odpowiedź MUSI zawierać pole nagłówka Uwierzytelnianie WWW (sekcja 14.47) zawierające wyzwanie mające zastosowanie do żądanego zasobu.” Wydaje się, że jeśli nie chcesz używać uwierzytelniania w stylu HTTP, kod odpowiedzi 401 nie jest odpowiedni.
Brilliand

8
Wrócę tu Billiand. Oświadczenie brzmi „Jeśli żądanie zawiera już poświadczenia autoryzacji”. Oznacza to, czy jest to odpowiedź z żądania, które dostarczyło poświadczenia (np. Odpowiedź z próby uwierzytelnienia RFC2617). Zasadniczo pozwala to serwerowi powiedzieć: „Zła para konto / hasło, spróbuj ponownie”. W zadanym pytaniu użytkownik jest prawdopodobnie uwierzytelniony, ale nie autoryzowany. 401 nigdy nie jest właściwą reakcją na te okoliczności.
ldrut

6
Brilliand ma rację, 401 jest odpowiednie tylko do uwierzytelniania HTTP.
Juampi

296

Brakuje innych odpowiedzi, że należy rozumieć, że Uwierzytelnianie i autoryzacja w kontekście RFC 2616 odnosi się TYLKO do protokołu uwierzytelniania HTTP RFC 2617. Uwierzytelnianie przez schematy poza RFC2617 nie jest obsługiwane w kodach stanu HTTP i nie jest brane pod uwagę przy podejmowaniu decyzji, czy użyć 401, czy 403.

Krótkie i zwięzłe

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

Oznacza to, że jeśli masz swój własny proces logowania i nigdy nie używasz uwierzytelniania HTTP, 403 jest zawsze właściwą odpowiedzią i 401 nigdy nie powinno być używane.

Szczegółowy i szczegółowy

Z RFC2616

10.4.2 401 Niedozwolone

Żądanie wymaga uwierzytelnienia użytkownika. Odpowiedź MUSI zawierać pole nagłówka Uwierzytelnianie WWW (sekcja 14.47) zawierające wyzwanie mające zastosowanie do żądanego zasobu. Klient MOŻE powtórzyć żądanie z odpowiednim polem nagłówka Autoryzacja (sekcja 14.8).

i

10.4.4 403 Zabronione Serwer zrozumiał żądanie, ale odmawia jego spełnienia. Autoryzacja nie pomoże, a prośba NIE POWINNA zostać powtórzona.

Pierwszą rzeczą, o której należy pamiętać, jest to, że „Uwierzytelnianie” i „Uwierzytelnianie” w kontekście tego dokumentu odnoszą się konkretnie do protokołów uwierzytelniania HTTP z RFC 2617. Nie odnoszą się one do żadnych opracowanych przez siebie protokołów uwierzytelniania używając stron logowania itp. Będę używał słowa „login” w odniesieniu do uwierzytelniania i autoryzacji metodami innymi niż RFC2617

Tak więc prawdziwą różnicą nie jest to, na czym polega problem, a nawet czy istnieje rozwiązanie. Różnica polega na tym, co serwer oczekuje od klienta w następnej kolejności.

401 wskazuje, że nie można podać zasobu, ale serwer ZAPYTA, aby klient logował się za pośrednictwem uwierzytelniania HTTP i wysłał nagłówki odpowiedzi w celu zainicjowania procesu. Możliwe, że istnieją autoryzacje, które umożliwią dostęp do zasobu, być może nie, ale spróbujmy i zobaczmy, co się stanie.

403 wskazuje, że nie można zapewnić zasobu i dla obecnego użytkownika nie ma sposobu na rozwiązanie tego za pomocą RFC2617 i nie ma sensu próbować. Może to wynikać z faktu, że wiadomo, że żaden poziom uwierzytelnienia nie jest wystarczający (na przykład z powodu czarnej listy IP), ale może być tak, ponieważ użytkownik jest już uwierzytelniony i nie ma uprawnień. Model RFC2617 to jeden użytkownik, jedno poświadczenie, więc przypadek, w którym użytkownik może mieć drugi zestaw poświadczeń, które mogą być autoryzowane, może zostać zignorowany. Nie sugeruje ani nie sugeruje, że jakaś strona logowania lub inny protokół uwierzytelniania inny niż RFC2617 może, ale nie musi pomóc - to jest poza standardami i definicją RFC2616.


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


7
Co więc powinniśmy zrobić, gdy użytkownik zażąda strony wymagającej uwierzytelnienia innego niż HTTP? Wysłać kod stanu 403?
marcovtwout

2
To jest odpowiedź, która odpowiedziała na moje pytania dotyczące rozróżnienia.
Patrick

9
Jest to ważne: „jeśli masz swój własny proces logowania i nigdy nie używasz uwierzytelniania HTTP, 403 jest zawsze właściwą odpowiedzią i 401 nigdy nie powinno być używane”.
ggg

1
@marcovtwout Wyślij 302 na swoją stronę logowania lub 403 zawierające ciało z informacją, jak się zalogować?
Alex

4
Czy RFC7235 nie przewiduje „autostartowania” lub alternatywnych wyzwań uwierzytelniania? Dlaczego przepływ danych mojej aplikacji nie może stanowić wyzwania w postaci WWW-Authenticatenagłówka? Nawet jeśli przeglądarka go nie obsługuje, moja aplikacja React może ...
jchook 11.10.16

127
  + -----------------------
  | ISTNIEJE ZASOBY? (jeśli prywatny, jest często sprawdzany PO sprawdzeniu autentyczności)
  + -----------------------
    | |
 NIE przeciwko TAK
    v + -----------------------
   404 | JEST ZALOGOWANY? (uwierzytelniony, aka ma plik cookie sesji lub JWT)
   lub + -----------------------
   401 | |
   403 NIE | | TAK
   3xx vv
              401 + -----------------------
       (404 brak ujawnienia) | Czy można uzyskać dostęp do zasobów? (pozwolenie, autoryzowane, ...)
              lub + -----------------------
             przekierowanie | |
             zalogować się NIE | | TAK
                               | |
                               vv
                               403 OK 200, przekierowanie, ...
                      (lub 404: brak ujawnienia)
                      (lub 404: zasób nie istnieje, jeśli prywatny)
                      (lub 3xx: przekierowanie)

Kontrole zwykle wykonuje się w następującej kolejności:

  • 404 jeśli zasób jest publiczny i nie istnieje lub przekierowanie 3xx
  • INACZEJ:
  • 401 jeśli nie jest zalogowany lub sesja wygasła
  • 403 jeśli użytkownik nie ma uprawnień dostępu do zasobu (plik, json, ...)
  • 404 jeśli zasób nie istnieje lub nie chce niczego ujawnić, lub przekierowanie 3xx

NIEAUTORYZOWANY : Kod statusu (401) wskazujący, że żądanie wymaga uwierzytelnienia , zwykle oznacza to, że użytkownik musi być zalogowany (sesja). Użytkownik / agent nieznany przez serwer. Można powtórzyć z innymi poświadczeniami. UWAGA: Jest to mylące, ponieważ powinno to być nazwane „nieuwierzytelnione” zamiast „nieautoryzowane”. Może się to również zdarzyć po zalogowaniu, jeśli sesja wygasła. Przypadek specjalny: można użyć zamiast 404, aby uniknąć ujawnienia obecności lub braku obecności zasobów (kredyty @gingerCodeNinja)

ZABRONIONE : 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 poświadczenia . Powtarzanie żądania nie zadziała, chyba że zmieni się dane uwierzytelniające, co jest bardzo mało prawdopodobne w krótkim okresie czasu. Przypadek specjalny: można użyć zamiast 404, aby uniknąć ujawnienia obecności lub braku obecności zasobów (kredyty @gingerCodeNinja)

NOT FOUND : 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, działa tak, jakby nie istniał. Powtarzanie nie zadziała. Jest to specjalne zastosowanie 404 (na przykład robi to github).

Jak wspomniano w @ChrisH, istnieje kilka opcji przekierowania 3xx (301, 302, 303, 307 lub brak przekierowania i użycie 401):


Na przykład zalogowałem się i mogę uzyskać dostęp do strony, ale nie ma dla mnie uprawnień włączonych. Który kod stanu zwróci?
barteloma

@bookmarker Logowanie jest nazywane uwierzytelnianiem, co jest pierwszym krokiem. Jeśli więc nie masz uprawnień po zalogowaniu, otrzymasz 403 Zabronione (niewystarczające poświadczenia oznaczają, że nie masz wystarczających uprawnień).
Christophe Roussy

3
Jasne i proste wyjaśnienie. Właśnie to czego potrzebuje.
Estevez

jeśli użytkownik nie jest zalogowany lub zalogowany, ale nie ma uprawnień, a treść nie istnieje w lokalizacji, czasami prawdopodobnie chcesz zwrócić 401/403 zamiast 404, aby nie ujawnić, co jest lub nie jest tam, jeśli użytkownik nie jest uwierzytelniony i zalogowany. Świadomość, że coś istnieje, może wskazywać na coś lub złamać NDA. Czasami więc część 404 tego diagramu powinna zostać przeniesiona pod zalogowanym / uwierzytelnionym.
gingerCodeNinja

1
@MattKocaj zauważa, że no revealsprawa może być czasami wykryta przez subtelne różnice czasowe i nie powinna być postrzegana jako funkcja bezpieczeństwa, może po prostu spowolnić atakujących lub nieco pomóc w prywatności.
Christophe Roussy

113

Zgodnie z RFC 2616 (HTTP / 1.1) 403 jest wysyłany, gdy:

Serwer zrozumiał żądanie, ale odmawia jego spełnienia. Autoryzacja nie pomoże, a prośba NIE POWINNA zostać powtórzona. Jeśli metoda żądania nie była HEAD, a serwer chce podać do publicznej wiadomości, dlaczego żądanie nie zostało spełnione, POWINIEN opisać przyczynę odmowy w jednostce. Jeśli serwer nie chce udostępnić tych informacji klientowi, zamiast tego można użyć kodu stanu 404 (Nie znaleziono)

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


5
A jeśli nie jest jasne, czy mają dostęp, czy nie? Powiedz, że mam 3 poziomy użytkowników - publiczny, członkowie i członkowie premium. Załóżmy, że strona jest tylko dla członków Premium. Użytkownik publiczny jest zasadniczo nieuwierzytelniony i po zalogowaniu może być członkiem lub członkiem premium. Na poziomie użytkownika członek 403 wydaje się odpowiednie. W przypadku członków premium 401. Co jednak służysz opinii publicznej?
VirtuosiMedia,

27
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 zaproponować sposób zmiany poświadczeń lub wysłania 401. Myślę, że 403 najlepiej nadaje się do treści, które nigdy nie są obsługiwane. W asp.net oznaczałoby to pliki web.config * .resx itp., Ponieważ bez względu na logującego się użytkownika pliki te NIGDY nie będą obsługiwane, więc nie ma sensu próbować ponownie.
Mel

6
+1, ale niepewna +1. Logiczny wniosek jest taki, że 403 nigdy nie powinien być zwracany, ponieważ 401 lub 404 byłoby zdecydowanie lepszą odpowiedzią.
CurtainDog,

12
@Mel Myślę, że plik, do którego klient nie powinien mieć dostępu, powinien mieć rozmiar 404. Jest to plik wewnętrzny systemu; zewnętrzny nie powinien nawet wiedzieć, że istnieje. Zwracając numer 403, informujesz klienta, że ​​istnieje, nie musisz przekazywać tych informacji hakerom. Specyfikacja 403 mówiAn 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,

3
Chociaż wydaje mi się, że jest to prawdopodobnie dokładna interpretacja starego RFC 2616, należy zauważyć, że RFC 7231 inaczej definiuje semantykę 403 i w rzeczywistości wyraźnie stwierdza, że „Klient MOŻE powtórzyć żądanie z nowymi lub różnymi poświadczeniami”. Tak więc, chociaż ta odpowiedź była dokładna w 2010 r., Dziś jest całkowicie błędna, ponieważ znaczenie kodu statusu zostało przepisane pod naszymi stopami. (Irytujące, zmiany w dodatku do RFC 2616 nie potwierdzają zmiany!)
Mark Amery 30'17

46

Zakładając uwierzytelnianie HTTP ( WWW-uwierzytelnienia i autoryzacji nagłówków) jest w użyciu , jeśli uwierzytelnianie jako inny użytkownik będzie udzieli dostępu do żądanego zasobu, a następnie 401 Nieuprawnione powinny być zwrócone.

403 Zabronione jest stosowane, gdy dostęp do zasobu jest zabroniony dla wszystkich lub ograniczony do danej sieci lub dozwolony tylko przez SSL, o ile nie ma to związku z uwierzytelnianiem HTTP.

Jeśli uwierzytelnianie HTTP nie jest używane, a usługa jest schematem uwierzytelniania opartym na plikach cookie, co jest obecnie normą, wówczas należy zwrócić kod 403 lub 404.

Odnośnie 401, pochodzi z RFC 7235 (Hypertext Transfer Protocol (HTTP / 1.1): Uwierzytelnianie):

3.1 401 Nieautoryzowane

Kod stanu 401 (nieautoryzowany) wskazuje, że żądanie nie zostało zastosowane, ponieważ brakuje prawidłowych poświadczeń uwierzytelnienia dla zasobu docelowego. Serwer źródłowy MUSI wysłać pole nagłówka Uwierzytelnianie WWW (sekcja 4.4) zawierające co najmniej jedno wyzwanie mające zastosowanie do zasobu docelowego. Jeśli żądanie zawiera poświadczenia uwierzytelnienia, wówczas odpowiedź 401 wskazuje, że odmówiono autoryzacji tych poświadczeń. Klient MOŻE powtórzyć żądanie z nowym lub zastąpionym polem Nagłówek autoryzacji (sekcja 4.1). Jeśli odpowiedź 401 zawiera to samo wyzwanie co poprzednia odpowiedź, a agent użytkownika już próbował przynajmniej raz uwierzytelnić, wówczas agent użytkownika POWINIEN przedstawić użytkownikowi załączoną reprezentację, ponieważ zwykle zawiera on odpowiednie informacje diagnostyczne.

Semantyka 403 (i 404) zmieniła się z czasem. Pochodzi z 1999 r. (RFC 2616):

10.4.4 403 Zabronione

Serwer zrozumiał żądanie, ale odmawia jego spełnienia.
Autoryzacja nie pomoże, a prośba NIE POWINNA zostać powtórzona.
Jeśli metoda żądania nie była HEAD, a serwer chce podać do
publicznej wiadomości, dlaczego żądanie nie zostało spełnione, POWINIEN opisać przyczynę odmowy w jednostce. Jeśli serwer nie chce udostępnić tych informacji klientowi,
zamiast tego można użyć kodu stanu 404 (Nie znaleziono).

W 2014 RFC 7231 (Hypertext Transfer Protocol (HTTP / 1.1): Semantics and Content) zmienił znaczenie 403:

6.5.3 403 Zabronione

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

Jeśli w żądaniu podano poświadczenia uwierzytelnienia,
serwer uważa je za niewystarczające do udzielenia dostępu. Klient
NIE POWINIEN automatycznie powtarzać żądania z tymi samymi
poświadczeniami. Klient MOŻE powtórzyć żądanie z nowymi lub różnymi poświadczeniami. Żądanie może być jednak zabronione z powodów
niezwiązanych z poświadczeniami.

Serwer
źródłowy, który chce „ukryć” bieżące istnienie zabronionego zasobu docelowego, MOŻE zamiast tego odpowiedzieć kodem stanu
404 (Nie znaleziono).

Zatem 403 (lub 404) może teraz znaczyć cokolwiek. Podanie nowych danych uwierzytelniających może pomóc ... lub nie.

Uważam, że powodem tego jest RFC 2616, zakładając, że uwierzytelnianie HTTP będzie używane, gdy w praktyce dzisiejsze aplikacje internetowe będą budować niestandardowe schematy uwierzytelniania przy użyciu na przykład formularzy i plików cookie.


2
To jest interesujące. W oparciu o RFC 7231 i RFC 7235 nie widzę wyraźnego rozróżnienia między 401 a 403
Brian

2
403 oznacza „Znam cię, ale nie widzisz tego zasobu”. Nie ma powodu do zamieszania.
Michael Blackburn

„Jeśli żądanie zawiera dane uwierzytelniające, wówczas odpowiedź 401 wskazuje, że odmówiono autoryzacji tych danych. Klient MOŻE powtórzyć żądanie z nowym lub zastąpionym polem Nagłówek autoryzacji (sekcja 4.1).” Jednak wówczas „4.2. Pole nagłówka„ Autoryzacja ”pozwala agentowi użytkownika uwierzytelnić się na serwerze źródłowym”. Wygląda na to, że w RFC7235 używają terminu „autoryzacja”, jakby to było „uwierzytelnianie”. W takim przypadku może się wydawać, że uwierzytelniony, ale nieautoryzowany użytkownik nie powinien otrzymać 401, ale raczej 403
arcuri82

28

To jest starsze pytanie, ale jedną z opcji, która tak naprawdę nigdy nie została podniesiona, było zwrócenie 404. Z punktu widzenia bezpieczeństwa, najwyżej głosowana odpowiedź cierpi na potencjalną lukę wycieku informacji . Powiedzmy na przykład, że bezpieczna strona internetowa, o której mowa, jest stroną administracyjną systemu, a może częściej jest zapisem w systemie, do którego użytkownik nie ma dostępu. Idealnie byłoby, gdyby złośliwy użytkownik nawet nie wiedział, że jest tam strona / rekord, nie mówiąc już o tym, że nie ma on dostępu. Kiedy buduję coś takiego, spróbuję zapisać nieautoryzowane / nieautoryzowane żądania w wewnętrznym dzienniku, ale zwrócę 404.

OWASP ma więcej informacji na temat tego, w jaki sposób osoba atakująca może wykorzystać ten typ informacji jako część ataku.


3
Zastosowanie 404 zostało wspomniane w poprzednich odpowiedziach. Jesteś na punkcie re: wyciek informacji i powinno to być ważne dla każdego, kto wprowadza własny schemat uwierzytelniania / autoryzacji. +1 za wzmiankę o OWASP.
Dave Watts

Jak na ironię, link OWASP prowadzi teraz do strony 404. Znalazłem coś podobnego (myślę) na owasp.org/index.php/…
anned20

Dzięki za zgłoszenie, zaktualizowałem to!
Patrick White

Zależy od interfejsu API i sposobu przyznania dostępu. Ale „wyciek” nie stanowi problemu, jeśli zwraca 401 dla nazwy użytkownika / hasła, czy to na pewno jest tak samo jak dla formularza internetowego?
James

26
  • 401 Nieautoryzowany : Nie wiem kim jesteś. To błąd uwierzytelnienia.
  • 403 Zabronione : wiem, kim jesteś, ale nie masz uprawnień dostępu do tego zasobu. To jest błąd autoryzacji.

Nie jestem pewien, czy to „zawsze” oznacza, że ​​nadawca był nieznany. Tylko to, o co prosili, nie było autoryzowane.
James

22

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 schematach uwierzytelniania i autoryzacji stosowanych przez wiele popularnych serwerów i platform.

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

6.5.3 403 Zabronione

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

Jeśli w żądaniu podano poświadczenia uwierzytelnienia, serwer uważa je za niewystarczające do udzielenia dostępu. Klient NIE POWINIEN powtarzać żądania z tymi samymi poświadczeniami. Klient MOŻE powtórzyć żądanie z nowymi lub różnymi poświadczeniami. Żądanie może być jednak zabronione z powodów niezwiązanych z poświadczeniami.

Serwer źródłowy, który chce „ukryć” bieżące istnienie zabronionego zasobu docelowego, MOŻE zamiast tego odpowiedzieć kodem stanu 404 (Nie znaleziono).

Niezależnie od stosowanej konwencji ważne jest zapewnienie jednolitości w całej witrynie / interfejsie API.


2
Projekt został zatwierdzony i jest teraz zgodny z RFC 7231.
Vebjorn Ljosa,

13

TL; DR

  • 401: Odmowa związana z uwierzytelnieniem
  • 403: Odmowa, która nie ma NIC wspólnego z uwierzytelnianiem

Praktyczne przykłady

Jeśli apache wymaga uwierzytelnienia (przez .htaccess), a ty uderzysz Cancel, odpowie na nie401 Authorization Required

Jeśli nginx znajdzie plik, ale nie ma praw dostępu (użytkownik / grupa) do odczytu / dostępu, odpowie za pomocą403 Forbidden

RFC (2616 sekcja 10)

401 Nieautoryzowane (10.4.2)

Znaczenie 1: Konieczność uwierzytelnienia

Żądanie wymaga uwierzytelnienia użytkownika. ...

Znaczenie 2: Uwierzytelnianie jest niewystarczające

... Jeśli żądanie zawierało już poświadczenia autoryzacji, wówczas odpowiedź 401 wskazuje, że odmówiono autoryzacji tych poświadczeń. ...

403 Zabronione (10.4.4)

Znaczenie: niezwiązane z uwierzytelnianiem

... Autoryzacja nie pomoże ...

Więcej szczegółów:

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

  • POWINIEN opisać przyczynę odmowy w podmiocie

  • Zamiast tego można użyć kodu stanu 404 (Nie znaleziono)

    (Jeśli serwer chce ukryć te informacje przed klientem)


11

nie są zalogowani lub nie należą do właściwej grupy użytkowników

Podałeś dwa różne przypadki; każda sprawa powinna mieć inną odpowiedź:

  1. Jeśli nie są w ogóle zalogowani, powinieneś zwrócić 401 nieautoryzowanych
  2. Jeśli są zalogowani, ale nie należą do właściwej grupy użytkowników, powinieneś zwrócić 403 Zabronione

Uwaga na temat RFC na podstawie komentarzy otrzymanych do tej odpowiedzi:

Jeśli użytkownik nie jest zalogowany, jest nieautoryzowany, którego odpowiednikiem HTTP jest 401 i jest wprowadzany w błąd jako Nieautoryzowany w RFC. Jak podano w sekcji 10.4.2 dla 401 Nieautoryzowanych :

„Żądanie wymaga uwierzytelnienia użytkownika .”

Jeśli nie masz uwierzytelnienia, poprawna odpowiedź to 401. Jednak jeśli jesteś nieautoryzowany, w sensie semantycznym, 403 jest prawidłową odpowiedzią.


5
To nie jest poprawne. Odwołaj się do RFC i odpowiedzi @ Cumbayah.
Davide R.

7
@DavideR. RFC używa uwierzytelniania i autoryzacji zamiennie. Uważam, że bardziej sensowne jest czytanie w znaczeniu uwierzytelniającym .
Zaid Masud

Ta odpowiedź jest odwrócona. Nieautoryzowane to nie to samo co Nie uwierzytelnione. @DavideR ma rację. Uwierzytelnianie i autoryzacja NIE są zamienne
BozoJoe

2
2616 powinien zostać spalony. Kilka nowszych wersji RFC jest o wiele wyraźniejszych, że istnieje potrzeba rozróżnienia między „nie znam cię” a „znam cię, ale nie możesz uzyskać do tego dostępu”. Nie ma uzasadnionego powodu, by uznać istnienie zasobu, który nigdy nie zostanie spełniony (lub nie zostanie spełniony za pośrednictwem protokołu HTTP), co sugerują trutery 403.
Michael Blackburn

6

Oto znaczenia:

401 : Użytkownik nie został (poprawnie) uwierzytelniony, zasób / strona wymagają uwierzytelnienia

403 : Użytkownik uwierzytelniony, ale jego rola lub uprawnienia nie pozwalają na dostęp do żądanego zasobu, na przykład użytkownik nie jest administratorem, a żądana strona jest dla administratorów


To świetna odpowiedź TLDR na to pytanie.
Kousha,

5

W mojej głowie jest to prostsze niż gdziekolwiek, więc:

401: Aby to zobaczyć, potrzebujesz podstawowego uwierzytelniania HTTP.

403: Nie widać tego, a podstawowe uwierzytelnianie HTTP nie pomoże.

Jeśli użytkownik musi się tylko zalogować przy użyciu standardowego formularza logowania HTML witryny, 401 nie byłoby odpowiednie, ponieważ jest ono specyficzne dla podstawowego uwierzytelniania HTTP.

Nie polecam używania 403 do odmawiania dostępu do takich rzeczy /includes, ponieważ jeśli chodzi o sieć, te zasoby w ogóle nie istnieją i dlatego powinny 404.

Pozostawia to 403 jako „musisz się zalogować”.

Innymi słowy, 403 oznacza „ten zasób wymaga innej formy uwierzytelnienia niż uwierzytelnianie podstawowe HTTP”.

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2


5

Myślę, że ważne jest, aby wziąć pod uwagę, że w przeglądarce 401 inicjuje okno dialogowe uwierzytelniania dla użytkownika w celu wprowadzenia nowych danych uwierzytelniających, podczas gdy 403 nie. Przeglądarki uważają, że w przypadku zwrotu 401 użytkownik powinien ponownie uwierzytelnić. Zatem 401 oznacza nieprawidłowe uwierzytelnienie, a 403 oznacza brak pozwolenia.

Oto kilka przypadków w ramach tej logiki, w których błąd zostałby zwrócony z uwierzytelnienia lub autoryzacji, z ważnymi pogrubionymi zdaniami.

  • Zasób wymaga uwierzytelniania, ale nie ma poświadczenia zostały określone .

401 : Klient powinien określić poświadczenia.

  • Podane poświadczenia są w niepoprawnym formacie .

400 : To nie jest ani 401, ani 403, ponieważ błędy składniowe powinny zawsze zwracać 400.

  • Podane poświadczenia odnoszą się do użytkownika, który nie istnieje .

401 : Klient powinien podać prawidłowe poświadczenia.

  • Podane poświadczenianieprawidłowe, ale określ poprawnego użytkownika (lub nie określaj użytkownika, jeśli określony użytkownik nie jest wymagany).

401 : Ponownie klient powinien podać prawidłowe poświadczenia.

  • Podane poświadczenia nie wygasł .

401 : Jest to praktycznie to samo, co niepoprawne poświadczenia, więc klient powinien podać prawidłowe poświadczenia.

  • Podane poświadczenia są całkowicie poprawne, ale nie wystarczają do określonego zasobu , choć możliwe jest, że poświadczenia z większą liczbą uprawnień mogłyby.

403 : Określenie prawidłowych poświadczeń nie zapewni dostępu do zasobu, ponieważ bieżące poświadczenia są już prawidłowe, ale tylko nie mają uprawnień.

  • Określony zasób jest niedostępny niezależnie od poświadczeń.

403 : Jest to niezależne od poświadczeń, więc określenie prawidłowych poświadczeń nie może pomóc.

  • Podane poświadczenia są całkowicie ważne, ale przede wszystkim klient jest zablokowany z ich użyciem.

403 : Jeśli klient jest zablokowany, podanie nowych poświadczeń nic nie da.


3

Po angielsku:

401

Potencjalnie masz dostęp, ale z jakiegoś powodu odmówiono ci tego. Takie jak złe hasło? Spróbuj ponownie, przy prawidłowym żądaniu otrzymasz odpowiedź pozytywną.

403

Nigdy nie masz pozwolenia. Twojego nazwiska nie ma na liście, nigdy nie wejdziesz, nie odejdziesz, nie wyślesz prośby o ponowną próbę, zawsze zostanie odrzucone. Idź stąd.


1

Biorąc pod uwagę najnowsze RFC w tej sprawie ( 7231 i 7235 ), przypadek użycia wydaje się dość jasny (dodano kursywą):

  • 401 jest dla nieuwierzytelnionego („brakuje ważnego uwierzytelnienia”); tzn. „Nie wiem, kim jesteś lub nie ufam, że jesteś tym, za kogo się podajesz”.

401 Nieautoryzowane

Kod stanu 401 (nieautoryzowany) wskazuje, że żądanie nie zostało zastosowane, ponieważ nie ma prawidłowego uwierzytelnienia uwierzytelnienia dla zasobu docelowego. Serwer generujący odpowiedź 401 MUSI wysłać pole nagłówka Uwierzytelnianie WWW (sekcja 4.1) zawierające co najmniej jedno wyzwanie mające zastosowanie do zasobu docelowego.

Jeśli żądanie zawiera poświadczenia uwierzytelnienia, wówczas odpowiedź 401 wskazuje, że odmówiono autoryzacji tych poświadczeń. Klient użytkownika MOŻE powtórzyć żądanie z nowym lub zastąpionym polem Nagłówek autoryzacji (sekcja 4.2). Jeśli odpowiedź 401 zawiera to samo wyzwanie co poprzednia odpowiedź, a agent użytkownika już próbował przynajmniej raz uwierzytelnić, wówczas agent użytkownika POWINIEN przedstawić użytkownikowi załączoną reprezentację, ponieważ zwykle zawiera on odpowiednie informacje diagnostyczne.

  • 403 jest dla osób nieupoważnionych („odmawia zezwolenia”); tzn. „Wiem, kim jesteś, ale nie masz uprawnień dostępu do tego zasobu”.

403 Zabronione

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

Jeśli w żądaniu podano poświadczenia uwierzytelnienia, serwer uważa je za niewystarczające do udzielenia dostępu. Klient NIE POWINIEN automatycznie powtarzać żądania z tymi samymi poświadczeniami. Klient MOŻE powtórzyć żądanie z nowymi lub różnymi poświadczeniami. Żądanie może być jednak zabronione z powodów niezwiązanych z poświadczeniami.

Serwer źródłowy, który chce „ukryć” bieżące istnienie zabronionego zasobu docelowego, MOŻE zamiast tego odpowiedzieć kodem stanu 404 (Nie znaleziono).


2
-1; fragmenty te zostały już zacytowane w innych odpowiedziach tutaj, a twój nie dodaje nic nowego. Twierdziłbym, że wyraźnie nie jest jasne, jakie jest to rozróżnienie; podsumowujesz oba kody jako „brakuje ważnego uwierzytelnienia” i „odmawia autoryzacji”, ale nie mogę wyobrazić sobie żadnej sytuacji, w której jeden z tych krótkich opisów miałby zastosowanie, a drugiej nie można interpretować jako obowiązującej.
Mark Amery

Istnieje wiele odpowiedzi, które obejmują wiele RFC i są edytowane i aktualizowane błotniste wody. Zamieściłem link, aby wyjaśnić, co authenticatedjest i co authorizedjest, i zostawiłem wszystkie nieaktualne RFC, aby aplikacja była przejrzysta.
cjbarth

Twoja edycja wyjaśnia twoją interpretację dwóch kodów, która wydaje się pasować do interpretacji wielu innych osób. Jednak osobiście uważam, że interpretacja nie ma sensu. Użycie wyrażenia Jeśli podano dane uwierzytelniające” w opisie 403 oznacza, że ​​numer 403 może być odpowiedni, nawet jeśli nie podano danych uwierzytelniających - tzn. Przypadek „nieuwierzytelniony”. Tymczasem dla mnie najbardziej naturalną interpretacją wyrażenia „dla zasobu docelowego” zawartego w opisie 401 jest to, że 401 może być użyte dla użytkownika, który jest uwierzytelniony, ale nie autoryzowany.
Mark Amery

-6

W przypadku 401 vs 403 odpowiedziano na to wiele razy. Zasadniczo jest to debata „środowisko żądań HTTP”, a nie debata „aplikacyjna”.

Wygląda na to, że pojawia się pytanie dotyczące problemu z rolowaniem własnego logowania (aplikacji).

W takim przypadku zwykłe niezalogowanie się nie wystarczy, aby wysłać numer 401 lub 403, chyba że użyjesz uwierzytelniania HTTP zamiast strony logowania (niezwiązanej z ustawieniem uwierzytelniania HTTP). Wygląda na to, że szukasz „Utworzonego 201” z obecnym ekranem do samodzielnego logowania (zamiast żądanego zasobu) do dostępu do pliku na poziomie aplikacji. To mówi:

„Słyszałem cię, jest tutaj, ale spróbuj tego zamiast tego (nie możesz tego zobaczyć)”


Co dokładnie powstaje?
Grant Gryczan,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.