들어가며

  • 서버는 사용자가 누구인지 식별할 수 있어야 한다.
  • HTTP는 자체적인 인증관련 기능을 제공
  • HTTP 인증과 기본 인증을 알아본다.

12.1 인증

  • HTTP의 인증요구/응답 프레임워크
    • HTTP는 사용자 인증을 하는 데 사용하는 자체 인증요구/응답 프레임워크를 제공한다.
    • HTTP 모델
      • 웹 애플리케이션이 HTTP 요청 메시지를 받으면, 서버는 요청을 처리하는 대신에 현재 사용자를 식별할 수있는 ‘인증 요구’로 응답할 수 있다.
      • 인증 요구 응답을 받은 사용자는 다시 요청을 보낼 때 인증 정보(사용자 이름과 패시워드)를 첨부해야 한다.
  • 인증 프로토콜과 헤더
    • HTTP는 필요에 따라 고쳐 쓸 수 있는 제어 헤더를 통해, 다른 인증 프로토콜에 맞추어 확장할 수 있는 프레임워크를 제공한다.
    단계 헤더 설명 메서드/상태
    요청   첫 번째 요청에는 인증 정보가 없다 GET
    인증 요구 WWW-Authenticate 서버는 사용자에게 인증을 요구하며 401 상태 정보로 요청을 반려한다. 서버에는 각각 다른 비밀번호 영역이 있으므로 WWW-Authenticate 헤더에 해당 영역을 설명해 놓는다. 401 Unathorized
    인증 Authorization 클라이언트는 요청을 다시 보내는데, 인증 알고리즘과 사용자 이름과 비밀번호를 기술한 Authorization 헤더를 함께 보낸다. GET
    성공 Authentication-Info 인증 정보가 정확하다면, 서버는 문서와 함께 응답한다. 특정 인증 알고리즘은 선택적 헤더인 Authentication-Info에 인증 세션에 관한 추가 정보를 기술해서 응답하기도 한다. 200 OK
    • 클라이언트가 서버로 인증하려면, 인코딩된 비밀번호와 그 외 파라미터들을 Authorization 헤더에 담아서 요청을 다시 보낸다.
    • 인증 요청이 성공적으로 완료되면, 서버는 정상적인 코드(eg. 200 OK)를 반환하며, 추가적인 알고리즘에 대한 정보를 Authentication-Info 헤더에 기술할 수도 있다.
  • 보안 영역 
    WWW-Authenticate: Basic realm="Family"
    • 웹 서버는 기밀문서를 보안 영역(realm) 그룹으로 나누며, 보안 영역은 저마다 다른 사용자 권한을 요구한다.

12.2 기본 인증

  • 기본 인증은 가장 잘 알려진 HTTP 인증 규약이다.

  • 원래 HTTP/1.0에 기술되어 있었지만, HTTP 인증의 상세 내용을 다루는 RFC 2617로 옮겨졌다.

  • 기본 인증의 예
    • 사용자가 자신의 가족사진인 /family/jeff.jpg 요청한다.
    • 서버가 WWW-Authenticate 헤더와 함께 개인 가족사진에 접근하는 데 필요한 비밀번호를 요구하는 401 Unauthorization Required 응답을 반환한다.
    • 브라우저가 401 응답을 받고 Family 영역에 관한 사용자 이름과 비밀번호를 요구하는 대화상자를 띄운다.
    • 사용자가 사용자 이름과 비밀번호를 입력하면, 브라우저는 그것들을 콜론으로 이어 붙이고(eg. admin:admin), base-64 방식으로 인코딩한 후에 Authorization 헤더에 그 값을 담아 다시 서버로 요청한다.
    • 서버가 사용자 이름과 비밀번호를 디코딩하고, 그 값이 정확한지 검사한 후, 문제가 없으면 HTTP 200 OK 메시지와 함께 요청 받았던 문서를 응답한다.
    인증요구/응답 헤더 문법과 설명
    인증요구(서버에서 클라이언트로) 각 사이트는 보안 영역마다 다른 비밀번호가 있을 것이다. realm은 요청 받은 문서 집합의 이름을 따옴표로 감싼 것으로, 사용자는 이 정보를 보고 어떤 비밀번호를 사용해야 하는지 알 수 있다. WWW-Authenticate: Basic realm=따옴표로 감싼 문서 집합 정보
    응답(클라이언트에서 서버로) 사용자 이름과 비밀번호는 콜론으로 잇고, base-64로 인코딩해서 사용자 이름과 비밀번호에 쉽게 국제문자를 포함할 수 있게 하고, 네트워크 트래픽에 사용자 이름과 비밀번호가 노출되지 않게 한다. Authorization: Basic base-64로 인코딩한 사용자 이름과 비밀번호
    • 기본 인증은 Authentication-Info 헤더를 사용하지 않는다.
  • Base-64 사용자 이름/비밀번호 인코딩
    • Base-64 인코딩은 바이너리, 텍스트, 국제 문자 데이터(어떤 시스템에서는 문제를 일으킬 수 있는) 문자열을 받아서 전송할 수 있게, 그 문자열을 전송 가능한 문자인 알파벳으로 변환하기 위해 발명됐다.
  • 프락시 인증
    • 프락시 서버에서 접근 정책을 중앙 관리 할 수 있기에 통합적인 접근 제어를 위해서 프락시 서버를 사용하면 좋다.

12.3 기본 인증의 보안 결함

  • 단순하고 편리하지만 안심할 수는 없다.
  • 악의적이지 않은 누군가가 의도치 않게 리소스에 접근하는 것을 막는데 사용하거나, SSL 같은 암호 기술과 혼용한다.
    • 기본인증은 사용자 이름과 비밀번호를 쉽게 디코딩할 수 있는 형식으로 네트워크에 전송하며 이는 누구나 디코딩할 수 있도록 쉽다.
    • 보안 비밀번호가 디코딩하기에 더 복잡한 방식으로 인코딩 되었더라도 공격 예방에 도움되지 않는다.
    • 중요 정보가 아니더라도 일반 사용자가 보기에는 위험해 보인다.
    • 메시지의 인증 헤더를 건드리지 않지만, 그 외 다른 부분을 수정해서 트랜잭션의 본래 의도를 바꿔버리는 프락시가 개입하는 경우, 기본 인증의 정상 작동을 보장하지 않는다.
    • 가짜 서버의 위장에 취약하다.

** 참고 서적: HTTP 완벽 가이드