403 금지됨 대 401 무단 HTTP 응답
https://stackoverflow.com/questions/3297048
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
존재하지만 사용자에게 충분한 권한이 없는(로그인하지 않았거나 적절한 사용자 그룹에 속하지 않은) 웹 페이지의 경우 제공할 적절한 HTTP 응답은 무엇입니까?
401 Unauthorized?
403 Forbidden?
다른 것?
지금까지 각각에 대해 읽은 내용은 둘 사이의 차이점이 명확하지 않습니다.각 응답에 적합한 사용 사례는 무엇입니까?
해결책
인증 오류의 HTTP 상태 코드 인 401 무단 에 문제가 있습니다. 그리고 그것은 단지 그냥 : 인증이 아닌 인증을위한 것입니다. 401 응답을받는 것은 서버가 당신에게 말하는 것입니다. " 인증 - 전혀 인증되지 않거나 인증되지 않았습니다 잘못되었지만 다시 인증하고 다시 시도하십시오. " 너를 돕기 위해, 항상 설명하는 www-authenticate 헤더가 항상 포함됩니다. 인증하려면.
이것은 웹 서버가 아니라 웹 서버에서 일반적으로 반환되는 응답입니다. 신청.
그것은 또한 매우 일시적인 것입니다. 서버가 시도하도록 요청하고 있습니다 다시.
그래서, 승인을 위해 403 금지 응답을 사용합니다. 이것의 영구적으로, 그것은 내 응용 프로그램 논리에 묶여 있으며 더 구체적인 것입니다. 401보다 응답.
403 응답을받는 것은 서버가 "미안해. 알아 당신이 누구인가 당신이 누구인지 믿습니다. 그러나 당신은 단지 가지고 있지 않습니다. 이 리소스에 액세스 할 수있는 권한. 어쩌면 당신이 시스템을 물어 보는 경우 관리자는 훌륭하게 허가를받을 수 있습니다. 그러나 제발 귀찮게하지 마십시오 당신의 곤경이 변화 할 때까지 다시. "
요약에서 401 무단 응답을 누락시켜야합니다 또는 불량 인증, 그리고 403 금지 된 응답을 사용해야합니다 그 후, 사용자가 인증되었지만 권한이 부여되지 않은 경우 지정된 자원에서 요청한 작업을 수행하십시오.
다른 HTTP 상태 코드가 어떻게되어야하는지 좋은 그림 형식 사용되었습니다.
다른 팁
다른 답변이 누락 된 것은 RFC 2616의 맥락에서 인증 및 권한 부여가 RFC 2617의 HTTP 인증 프로토콜에 대해서만 참조한다는 것을 이해해야한다는 것입니다. RFC2617 외부의 구성표 별 인증은 HTTP 상태 코드에서 지원되지 않습니다. 401 또는 403을 사용할지 여부를 결정할 때 고려되지 않습니다.
간략하고 터스
Unauthorized 클라이언트가 RFC2617 인증이 아니며 서버가 인증 프로세스를 시작하는 것을 나타냅니다. 금지 된 것은 클라이언트가 RFC2617 인증이며 권한이 없거나 서버가 요청 된 리소스에 대해 RFC2617을 지원하지 않음을 나타냅니다.
즉, 자신의 롤 - 당신 자신의 로그인 프로세스가 있고 HTTP 인증을 사용하지 않으면 403은 항상 적절한 응답이고 401은 절대로 사용되지 않아야합니다.
상세하고 심층
rfc2616
10.4.2 401 무단
요청에는 사용자 인증이 필요합니다. 응답에는 요청 된 자원에 적용 할 수있는 챌린지가 포함 된 WWW 인증 헤더 필드 (14.47 절)가 포함되어야합니다. 클라이언트는 적합한 인증 헤더 필드 (14.8 절)로 요청을 반복 할 수 있습니다.
및
10.4.4 403 금지됨 서버는 요청을 이해했지만이를 충족시키는 것을 거부합니다. 승인은 도움이되지 않으며 요청을 반복해서는 안됩니다.
명심해야 할 첫 번째는이 문서의 컨텍스트에서 "인증"및 "권한 부여"가 RFC 2617의 HTTP 인증 프로토콜을 특별히 나타냅니다. 이들은 롤 - 자신의 인증 프로토콜을 참조하지 않습니다. 로그인 페이지 등을 사용하여 작성했을 수 있습니다. RFC2617
이외의 방법으로 인증 및 권한 부여를 참조하려면 "로그인"을 사용합니다.이므로 실제 차이점은 문제가 문제가 아닌지 또는 해결책이 있는지 아닙니다. 차이점은 서버가 클라이언트가 다음에 수행 할 것으로 기대하는 것입니다.
401은 자원이 제공 될 수 없지만 서버가 클라이언트가 HTTP 인증을 통해 로그인하고 프로세스를 시작하기 위해 응답 헤더를 보내는 것을 요청합니다. 아마도 자원에 대한 액세스를 허용 할 수있는 권한이 있지만 아마도 거기에 있지만, 어떤 일이 일어나는지 시도하고 시도해 보겠습니다.
403은 자원을 제공 할 수 없으며 현재 사용자가 RFC2617을 통해이를 해결할 수 없으며 시도 할 때이 방법이 없습니다. 이는 인증 수준이 충분하지 않은 것으로 알려져 있기 때문일 수 있지만 (예를 들어, IP 블랙리스트로 인해) 사용자가 이미 인증되고 권한이 없기 때문일 수 있습니다. RFC2617 모델은 사용자가 권한을 부여 할 수있는 두 번째 자격 증명 세트가 무시 될 수 있으므로 사용자가 두 번째 자격 증명을 가질 수있는 경우는 하나의 사용자입니다. 어떤 종류의 로그인 페이지 또는 기타 비 RFC2617 인증 프로토콜이 도움이되거나 도움이되지 않을 수도 있고 그렇지 않을 수도 있습니다. 즉, RFC2616 표준 및 정의 외부입니다.
+-----------------------
| RESOURCE EXISTS ? (if private it is often checked AFTER auth check)
+-----------------------
| |
NO | v YES
v +-----------------------
404 | IS LOGGED-IN ? (authenticated, aka has session or JWT cookie)
or +-----------------------
401 | |
403 NO | | YES
3xx v v
401 +-----------------------
(404 no reveal) | CAN ACCESS RESOURCE ? (permission, authorized, ...)
or +-----------------------
redirect | |
to login NO | | YES
| |
v v
403 OK 200, redirect, ...
(or 404: no reveal)
(or 404: resource does not exist if private)
(or 3xx: redirection)
.
검사는 일반적 으로이 순서로 수행됩니다.
- 404 리소스가 공개되어 있지 않거나 존재하지 않거나 3xx 리디렉션
- 달리 :
- 401 로그인하지 않거나 세션 만료되지 않은 경우
- 403 사용자가 자원 (파일, JSON, ...) 에 액세스 할 수있는 권한이없는 경우
- 404 자원이 존재하지 않거나 아무것도 나타내지 않거나 3xx 리디렉션
: 상태 코드 (401)는 요청에 인증 가 필요하다는 것을 나타내는 상태 코드 (401)는 일반적으로 사용자가 로그인 (세션)을 입력해야합니다. 서버가 알 수없는 사용자 / 에이전트. 다른 자격 증명을 반복 할 수 있습니다. 참고 : 이것은 'Unauthorized'대신 'Unauthenticated'라는 이름의 이름이 지정되어야 만하면 혼란 스럽습니다. 세션이 만료되면 로그인 후에도 발생할 수 있습니다. 특별한 경우 : 자원의 존재 나 존재가 아닌 존재 또는 존재감을 밝히지 않으려면 404 대신 사용할 수 있습니다 (크레딧 @gingercodeninja)
금지 된 : 상태 코드 (403) 서버가 요청을 이해했지만이를 충족시키는 것을 거부했습니다. 서버가 알고 있지만 자격 증명이 충분하지 않은 사용자 / 에이전트가 있습니다. . 자격 증명이 변경되지 않는 한 반복 요청이 작동하지 않습니다. 짧은 시간은 매우 가능하지 않습니다. 특별한 경우 : 자원의 존재 나 존재가 아닌 존재 또는 존재감을 밝히지 않으려면 404 대신 사용할 수 있습니다 (크레딧 @gingercodeninja)
발견되지 않음 : 상태 코드 (404)가 요청 된 자원을 사용할 수 없음을 나타내는 상태 코드 (404). User / Agent는 알려지지 만 서버는 자원에 대해 밝히지 않으며 마치 존재하지 않는 것처럼 수행합니다. 반복은 작동하지 않습니다. 이것은 404의 특별한 사용입니다 (github는 예를 들어, 그것을 수행합니다).
@chrish가 언급 한 바와 같이 redirection 3xx (301, 302, 303, 307 또는 전혀 리디렉션하지 않고 401 사용) :
HTTP 인증 ( www-authenticate 및 권한 부여 헤더 헤더 헤더를 인증 헤더를 인증 헤더)가 사용하는 경우 가 사용 중입니다. 사용자는 요청 된 리소스에 대한 액세스 권한을 부여하고 401 권한이 없어야합니다.
403 금지 된 경우 자원에 대한 액세스가 모든 사람에게 금지되거나 주어진 네트워크로 제한되거나 HTTP 인증과 관련된 것과 관련이없는 것만 큼 SSL 만 허용되는 경우에 사용됩니다.
HTTP 인증이 사용되지 않는 경우 및 서비스가 쿠키 기반 인증 체계가 NOTADAYSASE 인 경우 403 또는 404를 반환해야합니다.
401에 관한
이것은 RFC 7235 (하이퍼 텍스트 전송 프로토콜 (http / 1.1) : 인증) :
3.1. 401 무단
401 (무단) 상태 코드는 요청이 유효한 인증 자격 증명이 없기 때문에 적용되지 않았습니다 대상 자원의 경우. 원본 서버는 A를 보내야합니다 적어도 하나를 포함하는 www-authenticate 헤더 필드 (4.4 절) 목표 자원에 적용 할 수있는 챌린지. 요청이있는 경우 포함 된 인증 자격 증명, 401 응답이 포함되었습니다 권한 부여가 해당 권한이 거부되었음을 나타냅니다 자격 증명 . 클라이언트는 새 요청을 반복 할 수 있습니다. 대체 된 인증 헤더 필드 (4.1 절). 401 인 경우 응답에는 이전의 응답과 동일한 도전 과제가 포함됩니다. 사용자 에이전트는 이미 적어도 한 번 이상 인증을 시도했습니다. 사용자 에이전트는 동봉 된 표현을 사용자는 일반적으로 관련 진단 정보가 포함되어 있기 때문에
403 (404)의 의미는 시간이 지남에 따라 변경되었습니다. 이것은 1999 년부터 (RFC 2616) :
10.4.4 403 금지 된
서버는 요청을 이해했지만이를 충족시키는 것을 거부합니다.
권한 부여는 에 도움이되지 않으며 요청을 반복해서는 안됩니다.
요청 방법이 머리가 아니고 서버가
공개 왜 요청이 이루어지지 않았는지, 그것은 엔티티 거절 이유. 서버가 원하지 않는 경우 이 정보를 클라이언트에서 사용할 수있는 상태 코드 404
(발견되지 않음) 대신 사용할 수 있습니다.
2014 년 RFC 7231 (HTTP / 1.1) : 의미 및 내용) 403 :
의 의미를 변경했습니다.따라서6.5.3. 403 금지 된
403 (금지 된) 상태 코드는 서버가 서버를 나타냅니다. 요청을 이해했지만 승인을 거부합니다. 서버의 서버 요청이 금지 된 이유를 대중에게하기를 원합니다. 응답 페이로드 (있는 경우)의 이유를 설명하십시오.
인증 자격 증명이 요청에 제공된 경우
서버는 액세스 권한을 부여하기에 충분하지 않습니다. 클라이언트
동일한 요청을 자동으로 반복해서는 안됩니다. 신임장. 클라이언트는 새 또는 다른 요청을 반복 할 수 있습니다. 신임장. 그러나 이유로 요청이 금지 될 수 있습니다
자격 증명과 관련이 없습니다.
의 현재 존재를 "숨기기"하고자하는 원본 서버 금지 된 대상 자원은 대신 상태 코드의 상태 코드로 응답 할 수 있습니다 404 (발견되지 않음).
이제 403 (또는 404)은 이제 아무 것도 의미하지 않을 수 있습니다. 새로운 자격 증명을 제공하는 것이 도움이 될 수 있습니다. 또는 그렇지 않을 수도 있습니다.
RFC 2616은 오늘의 웹 앱이 예를 들어 양식 및 쿠키와 함께 사용하여 사용자 정의 인증 체계를 구축 할 때 HTTP 인증이 사용될 때 RFC 2616이 RFC 2616입니다.
- 401 무단 : 당신이 누구인지 모르겠습니다.이 인증 오류입니다.
- 403 금지 된 : 당신이 누구인지 알고 있지만,이 자원에 액세스 할 수있는 권한이 없습니다. 이는 권한 오류입니다.
이것은 오래된 질문이지만, 실제로 결코 발생한 한 옵션은 404를 반환하는 것이 었습니다. 보안 관점에서 가장 높은 투표 된 응답은 잠재적 인 정보 누설 취약점 .예를 들어 문제의 보안 웹 페이지는 시스템 관리 페이지 인 경우 또는 더 일반적으로 사용자가 액세스 할 수없는 시스템의 레코드입니다.이상적으로 악의적 인 사용자가 페이지 / 기록이 있음을 알지 않으려면 액세스가 필요하지 않습니다.이와 같은 것을 구축 할 때, 내부 로그에 무단 침투 / 무단 요청을 기록하려고 시도하지만 404를 반환합니다.
OWASP는 일부 공격자 가이 유형을 어떻게 사용할 수 있는지에 대한 정보 공격의 일부로 정보의
이 질문은 얼마 전에 물어 났으나 사람들의 생각이 계속됩니다.
섹션 6.5.3 이 초안 (Fielding 및 Reschke에 의해 저작됨)은 상태 코드 403을 rfc 2616 .
인증 된 웹 서버 및 프레임 워크가 사용하는 인증 및 권한 부여 체계에서 발생하는 일을 반영합니다.
나는 내가 가장 두드러진다고 생각하는 비트를 강조했다.
6.5.3. 403 금지 된
403 (금지 된) 상태 코드는 서버가 요청을 이해했지만 승인을 거부 함을 나타냅니다. 요청이 금지 된 이유를 대중으로 만들고자하는 서버는 응답 페이로드 (있는 경우)의 이유를 설명 할 수 있습니다.
인증 자격 증명이 요청에 제공된 경우 서버는 액세스 권한을 부여하기 위해 불충분 한 것으로 간주합니다. 클라이언트는 동일한 자격 증명으로 요청을 반복해서는 안됩니다. 클라이언트는 새 또는 다른 자격 증명으로 요청을 반복 할 수 있습니다. 그러나 자격 증명과 무관 한 이유로 요청을 금지 할 수 있습니다.
"숨기기"를 원하는 원본 서버는 금지 된 대상 자원의 현재 존재 여부가 404 (발견되지 않음)의 상태 코드로 응답 할 수 있습니다.
사용하는 대건이든 중요한 것은 사이트 / API 전반에 걸쳐 균일 성을 제공하는 것입니다.
TL;DR
- 401:인증과 관련된 거부
- 403:인증과 전혀 관련이 없는 거부
실제 사례
만약에 아파치 인증이 필요합니다 (을 통해 .htaccess) 그리고 당신은 쳤습니다 Cancel, 이는 다음과 같이 응답합니다. 401 Authorization Required
만약에 nginx 파일을 찾았지만 파일이 없습니다. 액세스 권한 (사용자/그룹)이 이를 읽고 액세스하면 다음과 같이 응답합니다. 403 Forbidden
RFC(2616 섹션 10)
401 무단(10.4.2)
의미 1: 인증 필요
요청에는 사용자 인증이 필요합니다....
의미 2: 인증 불충분
...요청에 이미 인증 자격 증명이 포함된 경우 401 응답은 해당 자격 증명에 대한 인증이 거부되었음을 나타냅니다....
403 금지됨(10.4.4)
의미: 인증과 관련 없음
...승인은 도움이되지 않습니다 ...
자세한 내용은:
서버가 요청을 이해했지만 이행을 거부하고 있습니다.
엔터티에서 거부 이유를 설명해야 합니다.
대신 상태 코드 404(찾을 수 없음)를 사용할 수 있습니다.
(서버가 클라이언트로부터 이 정보를 유지하려는 경우)
그들은 로그인하지 않았거나 적절한 사용자 그룹에 속하지 않습니다
두 가지 다른 경우를 명시했습니다. 각각의 경우에는 응답이 다릅니다.
- 401 무단 를 반환해야합니다.
- 로그인하지만 적절한 사용자 그룹에 속하지 않으면 403 금지 를 반환해야합니다.
이 답변에 수신 된 주석을 기반으로 한 RFC에서 참고 :
사용자가 로그인하지 않은 경우 해당하는 경우 HTTP는 401이며 RFC에서 무단으로 무단으로 호출됩니다. 10.4.2 섹션 401 401 :
"요청에는 사용자가 필요합니다 인증 ."
인증되지 않은 경우 401이 올바른 응답입니다. 그러나 무단 인 경우, 의미 론적으로 정확한 의미에서 403은 올바른 응답입니다.
영어로 :
401
잠재적으로 액세스 할 수 있지만이 요청에 어떤 이유로 거부 당했다.나쁜 암호와 같은?올바른 요청으로 다시 시도하십시오 대신 성공 응답을 얻을 수 있습니다.
403
당신은 그렇지 않습니다.귀하의 이름이 목록에 있지 않습니다. 이제까지 들어가거나, 다시 시도 요청을 보내지 말고 거절 당할 것입니다, 항상.멀리 가라.
이들은 의미입니다.
401 : 사용자가 아님 (올바르게) 인증, 자원 / 페이지 인증이 필요합니다
403 : 사용자 인증이지만, 그의 역할 또는 사용 권한은 요청 된 자원에 액세스 할 수 없으며, 예를 들어 사용자가 관리자가 아닌 요청 페이지가 관리자
여기에있는 것보다 내 머리에서 간단합니다. 그래서 :
401 :이를 보려면 HTTP 기본 인증이 필요합니다.
403 :이 정보를 볼 수 없으며 HTTP 기본 인증이 도움이되지 않습니다.
사용자가 사이트의 표준 HTML 로그인 양식을 사용하여 로그인 해야하는 경우 HTTP 기본 인증과 관련이 있기 때문에 401이 적절하지 않습니다.
403을 사용하여 /includes와 같은 것에 대한 액세스를 거부하는 것이 좋습니다. 웹이 관련이 있기 때문에 해당 자원은 전혀 존재하지 않아 404입니다.
403을 "로그인해야합니다"라고
다른 말로하면, 403은 "이 자원은 HTTP Basic Auth 이외의 인증을 필요로합니다.
https://www.w3.org/protocols./rfc2616/rfc2616-sec10.html#sec10.4.2
브라우저에 401이 새로운 자격 증명을 입력 할 수있는 인증 대화 상자를 시작하는 것이 중요하다고 생각하는 것이 중요합니다. 브라우저는 401이 반환되면 사용자가 다시 인증해야한다고 생각합니다. 따라서 401이 잘못된 인증을 의미합니다. 403은 허가가 부족합니다.
여기서는 중요한 문구가 굵게 표시된 인증 또는 권한 부여로 인한 인증 또는 권한 부여로 오류가 반환되는 논리에서 몇 가지 경우가 있습니다.
- 자원은 인증이 필요하지만 자격 증명은 가 를 지정했습니다.
401 : 클라이언트는 자격 증명을 지정해야합니다.
- 지정된 자격 증명은 잘못된 형식 에 있습니다.
400 : 구문 오류가 항상 400을 반환해야함에 따라 401도 403도 아니다.
- 지정된 자격 증명은 가 존재하지 않습니다
401 : 클라이언트가 유효한 자격 증명을 지정해야합니다.
- 지정된 자격 증명 는 유효하지 않은 이지만 유효한 사용자를 지정하거나 지정한 사용자가 필요하지 않은 경우 사용자를 지정하지 않음).
401 : 다시 클라이언트는 유효한 자격 증명을 지정해야합니다.
- 지정된 자격 증명 은 만료 된
401 : 이것은 일반적으로 유효하지 않은 자격 증명과 실질적으로 동일하므로 클라이언트가 유효한 자격 증명을 지정해야합니다.
- 지정된 자격 증명은 완전히 유효하지만 자원 의 충분하지는 않지만 더 많은 권한이있는 자격 증명이 가능할 수도 있습니다.
403 : 현재 자격 증명이 이미 유효하지만 권한이 없으므로 유효한 자격 증명을 지정하면 리소스에 대한 액세스 권한이 부여되지 않습니다.
- 특정 자원 은 자격 증명에 관계없이 액세스 할 수없는 입니다.
403 : 이것은 자격 증명에 관계없이 유효한 자격 증명을 지정할 수 없습니다.
- 지정된 자격 증명이 완전히 유효하지만 특정 클라이언트 은 차단 입니다.
403 : 클라이언트가 차단 된 경우 새 자격 증명을 지정하는 것은 아무 것도하지 않습니다.
Given the latest RFC's on the matter (7231 and 7235) the use-case seems quite clear (italics added):
- 401 is for unauthenticated ("lacks valid authentication"); i.e. 'I don't know who you are, or I don't trust you are who you say you are.'
401 Unauthorized
The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource.
If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials. The user agent MAY repeat the request with a new or replaced Authorization header field (Section 4.2). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user agent SHOULD present the enclosed representation to the user, since it usually contains relevant diagnostic information.
- 403 is for unauthorized ("refuses to authorize"); i.e. 'I know who you are, but you don't have permission to access this resource.'
403 Forbidden
The 403 (Forbidden) status code indicates that the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any).
If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.
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).
In the case of 401 vs 403, this has been answered many times. This is essentially a 'HTTP request environment' debate, not an 'application' debate.
There seems to be a question on the roll-your-own-login issue (application).
In this case, simply not being logged in is not sufficient to send a 401 or a 403, unless you use HTTP Auth vs a login page (not tied to setting HTTP Auth). It sounds like you may be looking for a "201 Created", with a roll-your-own-login screen present (instead of the requested resource) for the application-level access to a file. This says:
"I heard you, it's here, but try this instead (you are not allowed to see it)"
