이 포스트는 “HTTP 완벽가이드”의 “12장, 기본 인증”을 정리한 내용입니다.

  • 수 많은 사람들이 웹을 통해 업무를 보거나 개인적인 데이터에 접근한다.
  • 웹 사이트에 리소스에는 소유자의 동의 없이 권한 없는 사용자가 접근할 수 없어야 한다.
  • 이를 위해서 서버는 사용자가 누구인지 식별할 수 있어야 한다. 서버는 사용자를 식별하여 작업이나 리소스에 접근할 권한을 결정한다.
  • 보통은 사용자 이름과 비밀번호를 입력해서 인증한다. HTTP는 자체적인 인증 관련 기능을 제공한다

#인증 프로토콜과 헤더

  • HTTP는 필요에 따라 고쳐 쓸 수 있는 제어 헤더를 통해, 다른 인증 프로토콜에 맞추어 확장할 수 있는 프레임워크를 제공한다.
  • 아래 표에 나열된 헤더의 형식과 내용은 인증 프로토콜에 따라 달라진다.
  • 인증 프로토콜은 HTTP 인증 헤더에 기술되어 있다.
  • HTTP에는 “기본 인증” 과 “다이제스트 인증”이 있다.
  • 이 포스트에는 “기본 인증” 관해서만 다룬다.

네 가지 인증 단계
자료 출처: "HTTP 완벽가이드", 이응준, 정상일 옮김, 인사이트, 2014

#기본 인증의 예 구체적으로 살펴보기 위해 다음 그림을 참고하자.
기본 인증의 예
자료 출처: http://www.asp.net/web-api/overview/security/basic-authentication

  1. 서버가 사용자에게 인증요구를 보낼 때
    서버는 401 Unauthorized 응답과 함께 WWW-Authenticate헤더를 기술해서 어디서 어떻게 인증할지 설명

  2. 다음으로 클라이언트가 서버로 인증
    인코딩된 비밀번호와 그 외 인증 파라미터들을 Authorization 헤더에 담아서 요청

  3. 성공적으로 완료되면 정상적인 상태 코드를 반환한다. 추가적인 인증 알고리즘에 대한 정보를 Authentication-Info 헤더에 기술

#보안 영역

  • 서버가 클라이언트로 인증 요구를 할 때, realm 지시자가 기술 되어 있는 WWW-Authenticate헤더를 전송

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

      HTTP/1.0 401 Unauthorized   
  WWW-Authenticate: Basic realm="Corporate Financials"
  • remalm은 위의 예시와 같이 해설 형식으로 돼어 사용자가 권한 범위를 이해하는데 도움이 되어야 한다.
  • "executive-committee@bigcompany.com"과 같은 서버의 호스트명을 넣는 것도 유용할 수 있다.

#HTTP 기본 인증의 헤더 자료 출처: "HTTP 완벽가이드", 이응준, 정상일 옮김, 인사이트, 2014

#기본 인증의 보안 결함 - 기본 인증은 단순하고 편리하지만 안심할 수 없다. 기본 인증은 악의적이지 않은 누군가가 의도치 않게 리소스에 접근하는 것을 막는데 사용하거나, SSL 같은 암호 기술과 혼용한다.

  1. base-64인코딩된 값은 쉽게 디코딩할 수 있다. 사실상 ‘비밀번호 그대로’ 보내는 것과 다름없다.
  2. 제삼자는 사용자 이름과 비밀번호를 캡처하여 악용할 수 있다. 캡처한 정보를 통해 인증에 성공하고 서버에 접근할 수 있다.
  3. 사용자들의 행태에 비추어 매우 위험하다. 악의적으로 정보를 훔친 다음 금융 정보에 접근할 수 있다.
  4. 프락시나 중개자가 개입하는 경우 정상적인 동작을 보장하지 않는다.
  5. 기본 인증은 가짜 서버의 위장에 취약하다.

#결론 기본 인증은 일반적인 환경에서 개인화나 접근을 제어하는데 편리하며, 다른 사람들이 보지 않기를 원하기는 하지만, 보더라도 치명적이지 않은 경우에는 여전히 유용하다. 기본 인증은 호기심 많은 사용자가 우연이나 사고로 정보에 접근해서 보는 것을 예방하는 데 사용한다.

출처: "HTTP 완벽가이드", 이응준, 정상일 옮김, 인사이트, 2014