본문 바로가기
books/HTTP 완벽가이드

[HTTP 완벽가이드 12장] 기본 인증

by Moonsc 2020. 5. 24.
728x90

3부.HTTP : 식별, 인가, 보안



12장. 기본 인증

허가된 사람만이 데이터에 접근하고 업무를 처리할 수 있어야 한다. 그러기 위해서는 서버가 사용자가 누구인지 식별할 수 있어야 하며, 
서버가 사용자가 누구인지 알면 그 사용자가 어떤 작업이나 리소스에 접근할 수 있는지 결정 할 수 있다. 


12.1 인증

  • 인증은 당신이 누구인지 증면하는 것이다.

  • 완벽한 인증은 없다. 다만 당신에 대한 여러 데이터는 당신이 누구인지 판단하는데 도움이 된다.

    1) HTTP의 인증요구/응답 프레임워크

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

    2) 기본 인증 프로토콜과 헤더

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

3) 보안 영역

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

  • 웹 서버는 기밀문서를 보안 영역 (realm) 그룹으로 나눈다.

  • 보안 영역은 저마다 다른 사용자 권한을 요구한다.

  • realm는 서버의 호스트명을 넣는 것도 유용할 수 있다.


    HTTP/1.0 401 Unauthorized
    WWW-authenticate: Basic realm="family"

12.2 기본 인증

  • 거의 모든 주요 클라이언트와 서버에 기본 인증이 구현되어 있다.

  • 기본 인증에서 웹 서버는 클라이언트의 요청을 거부하고 유효한 사용자 이름과 비밀번호를 요구할 수 있다.

  • 서버는 200 대신 401 상태 코드와 함께, 클라이언트가 접근하려던 보안 영역을 WWW-authenticate에 기술해서 응답하여 인증 요구를 시작한다.

  • 인증 정보를 포함하여 요청하라는 응답을 받은 클라이언트는 사용자 계정과 비밀번호를 입력하는 대화상자를 연다.

    1) 기본 인증 예 (생략)

    2) base-64 사용자 이름/비밀번호 인코딩

    • 기본 인증은 사용자 이름과 비밀번호를 콜론(:) 으로 이어서 합치고, base-64로 인코딩한다.

    3) 프락시 인증

    • 프락시 서버에서 접근 정책을 중앙 관리 할 수 있기에 통합적인 접근 제어를 위해서 프락시 서버를 사용하면 좋다.

12.3 기본 인증의 보안 결함

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

댓글