본문 바로가기

CS/네트워크

[HTTP] 12. 기본 인증

이 포스팅은 "HTTP-완벽 가이드" 책을 학습하고 정리한 것입니다.

https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=49731592

 

HTTP 완벽 가이드

HTTP 규약이 어떻게 동작하고 웹 기반 애플리케이션을 개발하는 데 어떻게 사용하는지 설명한다. 하지만 이 책은 단순히 HTTP에 대해서만 다루지는 않는다. HTTP가 효율적으로 동작하도록 함께 사

www.aladin.co.kr

 

 

 


 

 

 

서버는 사용자가 접근할 수 있는 리소스인지 확인하기 위해, 사용자가 누구인지(or 어떤 권한을 갖고 있는지) 확인해야 한다. 이러한 목적으로 HTTP는 인증 관련 기능을 제공한다.

 

12.1 인증

인증이라함은, 당신이 누구인지 증명하는 것이다.

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

HTTP는 사용자 인증을 하는 데 사용하는 자체 인증요구/응답 프레임워크를 제공한다. 절차는 [요청 → 인증요구 → 인가 → 성공] 의 단계로 이뤄져있으며, 세부 사항은 아래와 같다.

 

 

 

12.1.2 인증 프로토콜과 헤더

 서버마다 사용하는 인증 프로토콜이 다를 수 있기 때문에, HTTP는 인증 프로토콜에 맞춰 확장 가능한 헤더를 제공한다. 헤더의 형식과 내용은, 사용하는 프로토콜에 따라 다르다.

  • WWW-Authenticate : 헤더에 비밀번호 및 다른 정보가 담겨질 영역을 설명한다. 이 헤더를 사용할 때는 401 Unauthorized 상태 코드를 응답하여, 클라이언트에게 인증을 요구한다.
  • Authorization : 클라이언트는 이 헤더에 인증 알고리즘과 사용자 이름 및 비밀번호를 기술한다. 이때 내부 데이터는 인코딩(ex. Base-64)될 수 있다.
  • Authentication-info : 인증 정보가 정확할 경우, 서버는 이 헤더에 인증 세션과 관련한 추가 정보를 기술할 수 있다.

 

12.1.3 보안 영역

위 이미지에서 WWW-Authenticate 헤더를 보면 realm이라는 필드를 확인할 수 있다. realm은 보안 영역(realm) 그룹을 지정하기 위해 사용된다.

HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic realm="Corporate Financials"

 

12.2 기본 인증

 

 웹 서버가 클라이언트에 요청에 대해 인증을 요구할 수 있다고 앞서 확인하였다. 200 OK 대신, 401 Unauthorized 상태 코드를 전달하여, 클라이언트에게 인증정보를 요구한다. 클라이언트가 브라우저인 경우, 사용자가 입력한 사용자 이름과 비밀번호를 Authorization 요청 헤더 안에 암호화해서 서버로 다시 보낸다.

 

12.2.2 Base-64 사용자 이름/비밀번호 인코딩

 base-64 인코딩은 8비트로 이루어져 있는 시퀀스를 6비트 덩어리의 시퀀스로 변환한다. 기본 인증 방식에서는 “사용자이름:비밀번호” 형태로 만든 뒤, 이를 인코딩한다. 그러나, Base-64 인코딩 방식은 실제 보안상으로 사용해서는 안된다. 쉽게 디코딩될 수 있기 때문에, 사실상 비밀번호를 네트워크에 그대로 전송하는 것과 다름없다. 다만, 혹시라도 디코딩 안되었을 경우 내부 담당자가 고객의 비밀번호를 확인하는 것을 막기 위함으로 사용된다.

 만약, Authorization 헤더에 비밀 정보를 담을 경우, SSL로 감싸진 형태(HTTPS)로 통신되어야 한다.

 

12.2.3 프록시 인증

 중개 프록시 서버를 통해 인증할 수도 있다. 요청이 사내 LAN으로 들어오기 전, 프록시 서버에서 인증을 수행할 수 있다. 회사 리소스 전체에 대해 통합적인 접근 제어를 하기를 원할 때 유용하다. 프록시 인증을 위해 사용되는 헤더는 아래와 같다. 기존 헤더 앞에 “Proxy-” 만 붙인 것이다.

  • Proxy-Authenticate
  • Proxy-Authorization
  • Proxy-Authenticate-info

 

12.3 기본 인증의 기본 결함

  1. base-64 인코딩은 보안적으로 무효하다
  2. 비밀정보를 다른 강력한 방법으로 인코딩하더라도, 해당 데이터가 노출되면, 제3자가 해당 데이터를 이용해 서버에 인증할 수 있다.
  3. 높은 보안성이 요구되지 않은 사내 인트라넷일 경우, 기본 인증이 사용될 수도 있다. 그러나, 일반적으로 사용자는 다른 사이트에 동일한 비밀번호를 사용함으로, 인트라넷에서 탈취된 비밀번호는, 다른 사이트에게 악용될 수 있다.
  4. 프록시 서버가 중간에서 HTTP 메시지를 변경할 경우, 기본 인증이 동작하지 않을 수 있다.
  5. 기본 인증은 가짜 서버에 취약하다.

'CS > 네트워크' 카테고리의 다른 글

[HTTP] 11. 클라이언트 식별과 쿠키  (0) 2024.01.16
[HTTP] 14. 보안 HTTP  (2) 2024.01.10
[HTTP] 10. HTTP/2.0  (2) 2024.01.08
[HTTP] 07. 캐시 (2)  (2) 2024.01.08
[HTTP] 07. 캐시 (1)  (0) 2024.01.07