웹 사이트에 리소스에는 소유자의 동의 없이 권한 없는 사용자가 접근할 수 없어야 하고, 이를 위해서 서버는 사용자가 누구인지 식별할 수 있어야 한다.
보통은 사용자 이름과 비밀번호를 입력해서 인증한다. HTTP는 사용자 인증을 하는 데 사용하는 자체 인증요구/응답 프레임워크를 제공한다.
BUT 요즘은 각각의 인증 모듈을 이용해 '직접' 구현해 사용한다.
12.1.2 인증 프로토콜과 헤더
HTTP는 필요에 따라 고쳐 쓸 수 있는 제어 헤더를 통해, 다른 인증 프로토콜에 맞추어 확장할 수 있는 프레임워크를 제공한다.
HTTP에는 기본 인증과 다이제스트 인증이라는 두 가지 공식적인 인증 프로토콜이 있다.
12.1.3 보안 영역
웹 서버는 기밀문서를 보안 영역(realm) 그룹으로 나누고, 보안 영역은 저마다 다른 사용자 권한을 요구한다.
기본 인증은 Authorization: Basic <credentials>형식으로 유저 데이터를 전송하고, credentials는 기본적으로 Base64-Encoded(userid:password)를 따른다.
Base-64는 원래 시스템에 문제를 일으킬 수 있는 문자열(e.g. 한글이 포함된 URL...)을 받아 전송할 수 있도록 하기 위해 만들어졌다.
즉, 암호화의 목적으로 만들어진 게 아니다.
노출을 방지할 수는 있지만, 디코딩하는 것도 매우 간단하기 때문에 이를 보안 목적으로 사용하는 것은 부적절하다.
12.2.3 프락시 인증
중개 프락시 서버를 통해 인증하거나 프락시 서버에서 접근 정책을 중앙 관리할 수 있다.
웹 서버와 프락시 인증에서 쓰이는 상태 코드와 헤더들의 대조
기본 인증
프락시 서버
401 (Unauthorized)
407 (Proxy Authentication Required)
WWW-Authenticate
Proxy-Authenticate
Authorization
Proxy-Authorization
Authentication-Info
Proxy-Authentication-Info
접근 거부
프록시 서버가 주어진 리소스에 대한 접근 권한을 얻기 위해 적절하지 않은 유효한 인증 정보를 수신한다면, 서버는 403 Forbidden 상태 코드로 응답하여야 합니다. 401 Unauthorized 나 407 (en-US) Proxy Authentication Required 와는 다르게, 해당 사용자에 대한 인증은 불가능합니다.
12.3 기본 인증의 보안 결함
Base-64는 사용자 이름과 비밀번호를 쉽게 디코딩 할 수 있는 형식으로 네트워크에 전송한다.
따라서 어렵지 않게 디코딩 가능하고, 이는 사실상 비밀번호 그대로 보내는 것과 같다.
더 복잡한 방식으로 인코딩 되어도 제3자가 인코딩 된 것을 캡처하여 원 서버에 보내 인증을 선공하는 재전송 공격에 대한 대비가 없다.
기본 인증을 사용하는 사이트에서 사용한 비밀번호를 사용자들이 다른 사이트에서도 똑같은 비밀번호를 사용한다면 이를 악의적으로 이용할 수 있음
인증 헤더 외에 다른 부분을 수정하는 프락시나 중개자가 개입되는 경우, 기본 인증의 정상적인 동작을 보장하지 않는다.
기본 인증은 가짜 서버의 위장에 취약하다.
가짜 서버에 비밀번호를 보낼 수 있다
종합하자면, 기본인증은 노출이 되어도 치명적이지 않은 경우에는 여전히 유용하다.
또 기본 인증은 암호화된 데이터 전송(SSL과 같은)과 함께 연계해서 사용 가능하다.
++ HTTP Auth Type
WWW-Authenticate 헤더는 Type 에 인증 스킴을 명시한다.
Basic (base64-encoded credentials)
Bearer (bearer tokens to access OAuth 2.0-protected resources)
ruthetum
commented
2 years ago
12장 기본 인증
12.1 인증
12.1.1 HTTP의 인증요구/응답 프레임워크
웹 사이트에 리소스에는 소유자의 동의 없이 권한 없는 사용자가 접근할 수 없어야 하고, 이를 위해서 서버는 사용자가 누구인지 식별할 수 있어야 한다. 보통은 사용자 이름과 비밀번호를 입력해서 인증한다. HTTP는 사용자 인증을 하는 데 사용하는 자체 인증요구/응답 프레임워크를 제공한다. BUT 요즘은 각각의 인증 모듈을 이용해 '직접' 구현해 사용한다.
12.1.2 인증 프로토콜과 헤더
HTTP는 필요에 따라 고쳐 쓸 수 있는 제어 헤더를 통해, 다른 인증 프로토콜에 맞추어 확장할 수 있는 프레임워크를 제공한다. HTTP에는 기본 인증과 다이제스트 인증이라는 두 가지 공식적인 인증 프로토콜이 있다.
12.1.3 보안 영역
웹 서버는 기밀문서를 보안 영역(realm) 그룹으로 나누고, 보안 영역은 저마다 다른 사용자 권한을 요구한다.
12.2 기본 인증
기본 인증은 가장 잘 알려진 HTTP 인증 규약이다.
12.2.1 기본 인증의 예
12.2.2 Base-64 사용자 이름/비밀번호 인코딩
기본 인증은
Authorization: Basic <credentials>형식으로 유저 데이터를 전송하고, credentials는 기본적으로Base64-Encoded(userid:password)를 따른다.Base-64는 원래 시스템에 문제를 일으킬 수 있는 문자열(e.g. 한글이 포함된 URL...)을 받아 전송할 수 있도록 하기 위해 만들어졌다.
즉, 암호화의 목적으로 만들어진 게 아니다. 노출을 방지할 수는 있지만, 디코딩하는 것도 매우 간단하기 때문에 이를 보안 목적으로 사용하는 것은 부적절하다.
12.2.3 프락시 인증
중개 프락시 서버를 통해 인증하거나 프락시 서버에서 접근 정책을 중앙 관리할 수 있다.
12.3 기본 인증의 보안 결함
종합하자면, 기본인증은 노출이 되어도 치명적이지 않은 경우에는 여전히 유용하다. 또 기본 인증은 암호화된 데이터 전송(SSL과 같은)과 함께 연계해서 사용 가능하다.
++ HTTP Auth Type
WWW-Authenticate 헤더는 Type 에 인증 스킴을 명시한다.
Ref. HTTP 인증 Ref. HTTP Authentication Explained