[12장] 기본 인증

janjanee·2022년 8월 1일

[스터디] HTTP 완벽 가이드

목록 보기

11/14

HTTP는 사용자 인증을 하는 데 사용하는 자체 인증요구/응답 프레임워크를 제공한다.

웹 애플리케이션이 HTTP 요청 메시지를 받으면, 서버는 요청을 처리하는 대신에 현재 사용자가
누구인지를 알 수 있게 비밀번호 같이 개인 정보를 요구하는 '인증 요구'로 응답할 수 있다.

사용자가 다시 요청을 보낼 때는 인증 정보(사용자 이름/비밀번호)를 첨부해야한다.
인증 정보가 맞지않다면 서버는 재인증요구를 보내거나 에러를 보낼 수 있다.

HTTP에는 기본 인증과 다이제스트 인증이라는 두 가지 공식적인 인증 프로토콜이 있다.
현대에 HTTP의 인증요구/응답 프로토콜을 사용하는 인증 프로토콜로는 OAuth가 있다.

아래는 기본 인증에 대해 설명한다.

단계	헤더	설명	메서드/상태
요청		첫 번째 요청에는 인증 정보가 없다.	GET
인증요구	WWW-Authenticate	서버는 사용자에게 이름과 비밀번호를 제공하라는 의미로 401 상태 정보와 함께 요청을 반려한다.	401 Unauthorized
인증	Authorization	클라이언트는 요청을 다시 보내는데, 이번에는 인증 알고리즘과 사용자 이름, 비밀번호를 기술한 Authorization 헤더를 함께 보낸다.	GET
성공	Authentication-Info	인증 정보가 정확하면, 서버는 문서와 함께 응답한다. 어떤 인증 알고리즘은 선택적인 헤더인 Authentication-Info에 인증 세션에 관한 추가 정보를 기술해서 응답하기도 한다.	200 OK

웹 서버는 기밀문서를 보안 영역(realm) 그룹으로 나눈다. 보안 영역은 저마다 다른 사용자 권한을 요구한다.

WWW-Authenticate: Basic realm="Corporate Financials"

realme은 Corporate Financials(회사 재무) 같이 해설형식으로 돼 있어서, 사용자 이름과
비밀번호를 가지고 있는 사용자가 권한의 범위를 이해하는 데 도움이 되어야 한다.

인증요구/응답	헤더 문법과 설명
인증요구(서버 -> 클라이언트)	각 사이트는 보안 영역마다 다른 비밀번호가 있을것이다. realm은 요청받은 문서 집합의 이름을 따옴표로 감싼 것으로, 사용자는 이 정보를 보고 어떤 비밀번호를 사용해야 하는지 알 수 있다.
응답(클라이언트 -> 서버)	사용자 이름과 비밀번호는 콜론으로 잇고, base-64로 인코딩해서 사용자 이름과 비밀번호에 쉽게 국제문자를 포함할 수 있게 하고, 네트워크 트래픽에 사용자 이름과 비밀번호가 노출되지 않게 한다.

기본 인증 프로토콜은 12.1.2의 표에서 봤던 Authentication-Info 헤더를 사용하지 않는다.

기본 인증에서 base-64로 인코딩을 사용하는 예를 보여준다.

(a) 사용자 이름과 비밀번호를 입력받는다.

name : brian-totty pw: Ow!
(b) 사용자 이름과 비밀번호를 콜론으로 잇는다.

brian-totty:Ow!
(c) Base 64 인코딩한다.

YnJpYW4tdG90dHk6T3ch
(d) 인가 요청을 보낸다.

GET /family/jeff.jpg HTTP/1.0 Authorization: Basic YnJpYW4tdG90dHk6T3ch

base-64 인코딩은 바이너리, 텍스트, 국제 문자 데이터 문자열을 받아서 전송할 수 있게, 그 문자열을 전송 가능한
문자인 알파벳으로 변환하기 위해 발명됐다.

어떤 회사는 사용자들이 회사의 서버나 LAN 또는 무선 네트워크에 접근하기 전에 프락시 서버를 거치게 하여 사용자를 인증한다.

이 절차의 첫 번째 단계는 프락시 인증으로 사용자를 식별하는 것이다.

프락시 인증은 웹 서버의 인증과 헤더와 상태 코드만 다르고 절차는 같다.
아래의 표는 웹 서버와 프락시 인증에서 쓰이는 상태 코드와 헤더들의 대조표다.

base-64로 인코딩된 사용자 이름과 비밀번호는 인코딩 절차를 반대로 수행해서 어렵지 않게 디코딩할 수 있다.
보안 비밀번호를 디코딩하기 복잡하게 인코딩 했더라도 누군가는 그것을 원 서버에 보내서 인증에 성공하고 서버에 접근할 수 있다.
기본 인증이 회사 인트라넷이나 개인화된 콘텐츠 같이 보안에 치명적이지 않은 곳에서 사용된다 하더라도 위험한건 마찬가지이다.
메시지의 인증 헤더를 건드리지 않지만, 그 외 다른 부분을 수정해서 트랜젝션의 본래 의도를 바꾸는 프락시나 중개자가 개입하는 경우, 기본 인증은 정상적인 동작을 보장하지 않는다.
가짜 서버의 위장에 취약하다. 가짜 서버나 가짜 게이트웨이에 연결되어 있더라도, 알아차리지 못할 수 있다.

기본 인증은 위의 보안 결함들로 인해, 호기심 많은 사용자가 우연이나 사고로 정보에 접근해서 보는 것을 예방하는 정도로 사용한다.

기본 인증은 사용자 이름과 비밀번호를 악의적인 개인들에게 숨기려고 암호화된 데이터 전송(SSL과 같은)과 함께
연계해서 사용할 수 있다. 이는 널리 사용하는 기술이다.