12. 기본 인증
- 웹사이트에 있는 개인의 프로필이나 개인 문서는 해당 소유자의 동의없이는 권한이 없는 사용자가 볼 수 없어야합니다.
- 그러기 위해 서버는 사용자가 누구인지를 식별할 수 있어야합니다.
- 아래에서는 HTTP 인증, 기본 인증, 그리고 다이제스트 인증에 대해 서술합니다.
12.1 인증#
- 인증은 당신이 누구인지 증명하는 것입니다.
- 여러 데이터는 당신이 누군지 판단하는데 도움됩니다.
HTTP의 인증요구/응답 프레임워크#
- HTTP는 사용자 인증을 하는데 사용하는 자체 인증요구/응답 프레임워크를 제공합니다.
- 웹 애플리케이션이 HTTP 요청 메시지를 받으면, 서버는 요청을 처리하는 대신에 현재 사용자가 누구인지를 알 수 있게 비밀번호 같이 개인 정보를 요구하는 '인증 요구'로 응답할 수 있습니다.
인증 프로토콜과 헤더#
- HTTP는 필요에 따라 고쳐 쓸 수 있는 제어 헤더를 통해, 다른 인증 프로토콜에 맞추어 확장할 수 있는 프레임워크를 제공합니다.
- HTTP에는 기본 인증과 다이제스트 인증이라는 두 가지 공식적인 인증 프로토콜이 있습니다.
| 단계 | 헤더 | 설명 | 메서드/상태 |
|---|---|---|---|
| 요청 | 첫번째요청에는 인증 정보가 없음 | GET | |
| 인증 요구 | WWW-Authenticate | 서버는 사용자에게 사용자 이름과 비밀번호를 제공하라는 의미로 401 | 401 Unauthorized |
| 인증 | Authorization | 클라이언트는 요청을 다시보내는데 인증 정보헤더를 보냅니다 | GET |
| 성공 | Authentication-Info | 인증 정보가 정확하면 서버는 문서와 함께 응답합니다 | 200 OK |
보안 영역#
- 보안 영역은 저마다 다른 사용자 권한을 요구합니다.
realm 파라미터가 함께 기술된 기본 인증의 예입니다.
12.2 기본 인증#
- 기본 인증은 가장 잘 알려진 HTTP 인증 규약입니다.
- 기본 인증에서, 웹 서버는 클라이언트의 요청을 거부하고 유효한 사용자 이름과 이름을 요구할 수 있습니다.
- 브라우저는 사용자가 입력한 사용자 이름과 비밀번호를 Authorization 요청 헤더 안에 암호화해서 서버로 다시 보냅니다.
기본 인증의 예#
| 인증요구/응답 | 헤더 문법과 설명 |
|---|---|
| 인증요구(서버에서 클라이언트로) | 각 사이트는 보안 영역마다 다른 비밀번호가 있음, realm은 요청 받은 문서 집합의 이름, WWW-Authenticate: Basic realm=따옴표로 감싼 문서 집합 정보 |
| 응답(클라이언트에서 서버로) | 사용자 이름과 비밀번호는 콜론으로 있고, base-64로 인코딩하고 노출이 안되게 합니다. Authorization: Basic base-64로 인코딩한 사용자 이름과 비밀번호 |
Base-64 사용자 이름/비밀번호 인코딩#
- HTTP 기본 인증은 사용자 이름과 비밀번호를 콜론으로 이어 합치고, base-64 인코딩 메서드를 사용해 인코딩합니다.
프락시 인증#
- 중개 프락시 서버를 통해 인증할 수도 있습니다.
- 어떤 회사는 사용자들이 회사의 서버나 LAN이나 무선 네트워크에 접근하기 전에 프락시 서버를 거치게 하여 사용자를 인증합니다.
- 프락시 서버에서 접근 정책을 중앙 관리할 수 있기 때문에 통합적인 접근 제어에 장점을 가집니다.
| 웹 서버 | 프락시 서버 |
|---|---|
| 비인증 상태 코드:401 | 비인증 상태 코드:407 |
| WWW-Authenticate | Proxy-Authenticate |
| Authorization | Proxy-Authorization |
| Authentication-Info | Proxy-Authentication-Info |
12.3 기본 인증의 보안 결함#
- 기본 인증은 단순하고 편리하지만 안심할 수 없습니다.
아래의 보안 결함이 있습니다.
- 기본 인증은 사용자 이름과 비밀번호를 쉽게 디코딩할 수 있는 형식으로 네트워크에 전송합니다.
- SSL을 암호화 채널을 통해 보내거나 다이제스트 인증이 필요합니다.
- 보안 비밀번호가 디코딩하기 복잡하더라도 이를 캡쳐해서 인증에 성공하고 서버에 접근이 가능합니다.
- 기본 인증이 중요하지 않는 곳에 사용되더라도, 다른 사이트에서 사용하는 경우가 있기에 매우 위험합니다.
- 메시지의 인증 헤더를 건드리지는 않지만 그 외 다른 부분을 수정해서 트랜잭션의 본래 의도를 바꿔버리는 프락시나 중개자가 개입하는 경우, 정상 동작을 보장하지 않습니다.
- 기본 인증은 가짜 서버의 위장에 취약합니다.
따라서 기본 인증은 일반적인 환경에서 개인화나 접근 제어하는데 편리하며 다른 사람들이 보지 않기를 원하지만 봐도 치명적이지 않은 경우에 유용합니다.