웹 페이지가 있지만 사용자에게 충분한 권한이없는 (로그인되지 않았거나 적절한 사용자 그룹에 속하지 않은) 웹 페이지에 적합한 HTTP 응답은 무엇입니까?
401 Unauthorized?
403 Forbidden?
다른 것?
지금까지 내가 읽은 것은 둘 사이의 차이점에 대해서는 명확하지 않습니다. 각 응답에 적합한 사용 사례는 무엇입니까?
답변
Daniel Irvine 의 명확한 설명 :
인증 오류에 대한 HTTP 상태 코드 인 401 Unauthorized에 문제가 있습니다. 바로 그뿐입니다. 인증이 아니라 인증을위한 것입니다. 401 응답을받는 서버는 “인증되지 않았거나 전혀 인증되지 않았거나 잘못 인증 되었으나 다시 인증 한 후 다시 시도하십시오.”라고 서버에 알려줍니다. 이를 돕기 위해 항상 인증 방법을 설명하는 WWW-Authenticate 헤더가 포함됩니다 .
이것은 일반적으로 웹 응용 프로그램이 아닌 웹 서버에서 반환되는 응답입니다.
또한 매우 일시적인 것입니다. 서버가 다시 시도하도록 요청하고 있습니다.
따라서 승인을 위해 403 Forbidden 응답을 사용합니다 . 영구적이며 내 응용 프로그램 논리에 연결되어 있으며 401보다 더 구체적인 응답입니다.
서버가 403 응답을 수신하면“죄송합니다. 나는 당신이 누군지 알고 있습니다-당신이 말하는 사람을 믿습니다. 그러나 당신은이 자료에 접근 할 수있는 권한이 없습니다. 시스템 관리자에게 친절하게 문의하면 권한이 부여 될 수 있습니다. 하지만 상황이 바뀔 때까지 다시는 귀찮게하지 마십시오.”
요약하면 401 Unauthorized 응답은 누락되거나 잘못된 인증에 사용되어야하며 403 Forbidden 응답은 사용자가 인증되었지만 주어진 자원에 대해 요청 된 작업을 수행 할 권한이없는 경우에 사용해야합니다.
http 상태 코드 사용 방법에 대한 또 다른 멋진 그림 형식 입니다.
답변
RFC2616 참조 :
401 무단 :
요청에 이미 인증 자격 증명이 포함 된 경우 401 응답은 해당 자격 증명에 대한 인증이 거부되었음을 나타냅니다.
403 금지:
서버가 요청을 이해했지만 요청 이행을 거부하고 있습니다.
최신 정보
유스 케이스에서 사용자가 인증되지 않은 것으로 보입니다. 401을 반환합니다.
답변
RFC 2616의 컨텍스트에서 인증 및 권한 부여는 RFC 2617의 HTTP 인증 프로토콜 만 참조한다는 점을 이해해야합니다. RFC2617 외부의 체계에 의한 인증은 HTTP 상태 코드에서 지원되지 않으며 고려되지 않습니다. 401 또는 403 사용 여부를 결정할 때.
간단하고 간결
Unauthorized는 클라이언트가 RFC2617 인증을받지 않았으며 서버가 인증 프로세스를 시작하고 있음을 나타냅니다. 금지는 클라이언트가 RFC2617 인증을 받았으며 권한이 없거나 서버가 요청 된 자원에 대해 RFC2617을 지원하지 않음을 나타냅니다.
자체 롤업 로그인 프로세스가 있고 HTTP 인증을 사용하지 않는 경우 403은 항상 올바른 응답이며 401은 사용해서는 안됩니다.
상세하고 심층적 인
RFC2616에서
10.4.2 401 무단
요청에는 사용자 인증이 필요합니다. 응답에는 요청 된 자원에 해당하는 챌린지를 포함하는 WWW-Authenticate 헤더 필드 (섹션 14.47)가 포함되어야합니다. 클라이언트는 적절한 Authorization 헤더 필드 (14.8 절)로 요청을 반복 할 수있다.
과
10.4.4 403 금지됨 서버가 요청을 이해했지만 요청 이행을 거부하고 있습니다. 승인은 도움이되지 않으며 요청을 반복해서는 안됩니다.
가장 먼저 명심해야 할 것은이 문서의 맥락에서 “인증”및 “권한 부여”는 RFC 2617의 HTTP 인증 프로토콜을 구체적으로 나타냅니다. 사용자가 만든 롤-온 (roll-your-own) 인증 프로토콜은 언급하지 않습니다. 로그인 페이지 등을 사용합니다. “로그인”을 사용하여 RFC2617 이외의 방법으로 인증 및 권한 부여를 참조합니다.
따라서 실제 차이점은 문제가 아니거나 해결책이 있더라도 아닙니다. 차이점은 서버가 클라이언트가 다음에 할 것을 기대하는 것입니다.
401은 자원을 제공 할 수 없음을 나타내지 만 서버는 클라이언트가 HTTP 인증을 통해 로그인하도록 요청하고 프로세스를 시작하기 위해 응답 헤더를 보냈습니다. 아마도 리소스에 대한 액세스를 허용 할 수있는 권한이있을 수 있지만, 없을 수도 있지만 시도해보고 어떤 일이 일어나는지 보도록합시다.
403은 리소스를 제공 할 수 없으며 현재 사용자에게 RFC2617을 통해이를 해결할 방법이 없으며 시도 할 시점이 없음을 나타냅니다. 인증 수준이 충분하지 않은 것으로 알려져 있지만 (예 : IP 블랙리스트 등) 사용자가 이미 인증되었고 권한이 없기 때문일 수 있습니다. RFC2617 모델은 단일 사용자, 단일 자격 증명이므로 사용자가 권한을 부여 할 수있는 두 번째 자격 증명 집합이있는 경우 무시할 수 있습니다. 그것은 어떤 종류의 로그인 페이지 또는 다른 비 RFC2617 인증 프로토콜이 RFC2616 표준 및 정의를 벗어난 도움이 될 수도 있고 그렇지 않을 수도 있음을 암시하거나 암시하지 않습니다.
답변
+ -----------------------
| 자원이 있습니까? (비공개 인증 인 경우 종종 확인 후 확인)
+ -----------------------
| |
아니요 | v 예
v + -----------------------
404 | 로그인되어 있습니까? (인증, 일명 세션 또는 JWT 쿠키가 있음)
또는 + -----------------------
401 | |
403 아니오 | | 예
3xx vv
401 + -----------------------
(404 공개) | 자원을 이용할 수 있습니까? (권한, 승인, ...)
또는 + -----------------------
리디렉션 | |
로그인하려면 NO | | 예
| |
vv
403 OK 200, 리디렉션, ...
(또는 404 : 공개하지 않음)
(또는 404 : 개인의 경우 리소스가 존재하지 않습니다)
(또는 3xx : 리디렉션)
점검은 일반적으로 다음 순서로 수행됩니다.
- 리소스가 공개적이고 존재하지 않거나 xx 리디렉션 인 경우 404
- 그렇지 않으면:
- 로그인하지 않았거나 세션이 만료 된 경우 401
- 403 사용자에게 리소스 액세스 권한이없는 경우 (파일, json 등)
- 404 리소스가 존재하지 않거나 공개하지 않을 경우 3xx 리디렉션
UNAUTHORIZED : 요청에 인증 이 필요함을 나타내는 상태 코드 (401) . 일반적으로 이는 사용자가 로그인 (세션)해야 함을 의미합니다. 서버가 사용자 / 에이전트를 알 수 없습니다. 다른 자격 증명으로 반복 할 수 있습니다. 참고 : ‘무단’대신 ‘비인증’으로 이름을 지정 했으므로 혼동됩니다. 세션이 만료 된 경우 로그인 후 발생할 수도 있습니다. 특수 사례 : 자원의 존재 또는 존재 유무를 피하기 위해 404 대신 사용할 수 있습니다 (credits @gingerCodeNinja)
금지 : 서버가 요청을 이해했지만 요청을 이행하지 않았 음을 나타내는 상태 코드 (403). 서버에 알려진 사용자 / 에이전트이지만 자격 증명 이 충분하지 않습니다 . 자격 증명이 변경되지 않는 한 반복 요청은 작동하지 않으므로 짧은 시간 내에는 발생하지 않습니다. 특수 사례 : 자원의 존재 또는 존재 유무를 피하기 위해 404 대신 사용할 수 있습니다 (credits @gingerCodeNinja)
NOT FOUND : 요청 된 자원을 사용할 수 없음을 나타내는 상태 코드 (404). 사용자 / 에이전트는 알려져 있지만 서버는 리소스에 대해 아무 것도 공개하지 않으며 마치 존재하지 않는 것처럼합니다. 반복되지 않습니다. 이것은 404를 특수하게 사용합니다 (예 : github에서 수행).
@ChrisH에서 언급했듯이 리디렉션 3xx (301, 302, 303, 307) 또는 전혀 리디렉션하지 않고 401을 사용하는 몇 가지 옵션이 있습니다 .
답변
RFC 2616 (HTTP / 1.1) 에 따르면 다음과 같은 경우에 403이 전송됩니다.
서버가 요청을 이해했지만 요청 이행을 거부하고 있습니다. 승인은 도움이되지 않으며 요청을 반복해서는 안됩니다. 요청 방법이 HEAD가 아니고 서버가 요청이 이행되지 않은 이유를 공개하기를 원한다면, 엔티티에서 거절 이유를 설명해야한다. 서버가이 정보를 클라이언트에 제공하지 않으려면 대신 상태 코드 404 (찾을 수 없음)를 사용할 수 있습니다.
즉, 클라이언트가 인증을 통해 리소스에 액세스 할 수 있으면 401을 보내야합니다.
답변
HTTP 인증 ( WWW-Authenticate 및 Authorization 헤더) 이 사용 중이라고 가정 하고 다른 사용자로 인증하여 요청 된 자원에 대한 액세스 권한을 부여하면 401 Unauthorized가 리턴되어야합니다.
403 금지는 리소스에 대한 액세스가 모든 사람에게 금지되거나 지정된 네트워크로 제한되거나 HTTP 인증과 관련이없는 한 SSL을 통해서만 허용 될 때 사용됩니다.
현재 HTTP 인증을 사용하지 않고 쿠키 기반 인증 체계를 표준으로 사용하는 경우 403 또는 404를 반환해야합니다.
401에 대해서는 RFC 7235 (Hypertext Transfer Protocol (HTTP / 1.1) : 인증)에서 제공합니다.
3.1. 401 무단
401 (인증되지 않음) 상태 코드는 요청이 대상 리소스에 대한 유효한 인증 자격 증명이 없기 때문에 적용되지 않았 음을 나타냅니다. 오리진 서버는 대상 자원에 적용 가능한 하나 이상의 챌린지를 포함하는 WWW- 인증 헤더 필드 (섹션 4.4)를 보내야합니다. 요청에 인증 자격 증명이 포함 된 경우 401 응답은 해당 자격 증명에 대한 권한 부여가 거부되었음을 나타냅니다.. 클라이언트는 새로운 또는 교체 된 Authorization 헤더 필드 (4.1 절)로 요청을 반복 할 수있다. 401 응답에 이전 응답과 동일한 시도가 포함되어 있고 사용자 에이전트가 이미 한 번 이상 인증을 시도한 경우 사용자 에이전트는 일반적으로 관련 진단 정보를 포함하므로 동봉 된 표현을 사용자에게 제시해야합니다.
403 (및 404)의 의미는 시간이 지남에 따라 변경되었습니다. 1999 년 (RFC 2616)입니다.
10.4.4 403 금지
서버가 요청을 이해했지만 요청 이행을 거부하고 있습니다.
승인은 도움이되지 않으며 요청을 반복해서는 안됩니다.
요청 방법이 HEAD가 아니고 서버
가 요청이 이행되지 않은 이유 를 공개 하기를 원한다면 , 엔티티에서 거부 이유를 설명해야한다. 서버가이 정보를 클라이언트가 사용할 수 없게하려면 상태 코드 404
(찾을 수 없음)를 대신 사용할 수 있습니다.
2014 년 RFC 7231 (Hypertext Transfer Protocol (HTTP / 1.1) : 의미 및 내용)에서 403의 의미가 변경되었습니다.
6.5.3. 403 금지
403 (금지됨) 상태 코드는 서버가 요청을 이해했지만 승인을 거부 함을 나타냅니다. 요청이 금지 된 이유를 공개하려는 서버는 응답 페이로드에 해당 이유를 설명 할 수 있습니다 (있는 경우).
요청에 인증 자격 증명이 제공된 경우
서버 는 자격 증명이 액세스 권한을 부여하기에 충분하지 않은 것으로 간주합니다. 클라이언트
는 동일한
자격 증명으로 요청을 자동으로 반복해서는 안됩니다 . 클라이언트는 새로운 자격 증명이나 다른 자격 증명으로 요청을 반복 할 수 있습니다. 그러나
신임 정보와 관련이없는 이유로 요청이 금지 될 수 있습니다 .금지 된 대상 자원 의 현재 존재를 “숨기기”하려는 원 서버는 대신 상태 코드
404 (찾을 수 없음)로 응답 할 수 있습니다.
따라서 403 (또는 404)은 이제 무엇이든 의미 할 수 있습니다. 새로운 자격 증명을 제공하면 도움이 될 수도 있고 그렇지 않을 수도 있습니다.
이것이 변경 된 이유는 오늘날 웹 응용 프로그램이 예를 들어 양식 및 쿠키를 사용하여 사용자 지정 인증 체계를 작성할 때 HTTP 인증이 사용될 것이라고 가정 한 RFC 2616 때문이라고 생각합니다.
답변
이것은 오래된 질문이지만 실제로 제기되지 않은 한 가지 옵션은 404를 반환하는 것이 었습니다. 보안 측면에서 가장 높은 투표 응답은 잠재적 인 정보 유출 취약점으로 인해 어려움을 겪습니다 . 예를 들어, 해당 보안 웹 페이지는 시스템 관리 페이지이거나 더 일반적으로 사용자가 액세스 할 수없는 시스템의 레코드라고 가정하십시오. 이상적으로 악의적 인 사용자가 페이지 / 레코드가 있다는 것을 알기를 원하지 않을 것입니다. 이와 같은 것을 만들 때 내부 로그에 인증되지 않은 / 승인되지 않은 요청을 기록하려고하지만 404를 반환합니다.
OWASP에는 공격자가 이러한 유형의 정보를 공격의 일부로 사용하는 방법에 대한 추가 정보 가 있습니다.
