도서 HTTP 완벽 가이드를 읽고 알게 된 지식을 정리한 글입니다.
인증이란 사용자 스스로를 증명하는 것이다. HTTP의 기본 인증 방식을 다뤄본다.
기본 인증 예
- 사용자가 게시판에 글을 쓰는 페이지에 요청한다.
- 서버가 글쓰기 페이지에 접근하는 데 필요한 인증 정보를 요구한다.
- 브라우저가 사용자를 로그인 페이지로 리다이렉트시킨다. 사용자가 로그인을 완료하면, 브라우저는 그것들을 이어 붙인 뒤 인코딩한다.
- 서버가 사용자 이름과 비밀번호를 디코딩하여 그 값이 정확한지 검사한 후, 문제가 없다면 200 OK 상태 코드와 함께 글쓰는 페이지를 반환한다.
인증과 관련된 헤더
| 헤더 이름 | 헤더 설명 |
| WWW-Authenticate | realm은 요청 받은 문서 집합의 이름을 따옴표로 감싼 것으로, 사용자는 이 정보를 보고 어떤 비밀번호를 사용해야 하는지 알 수 있다. WWW-Authenticate: Basic realm=따옴표로 감싼 문서 집합 정보 |
| Authorization | 사용자 이름과 비밀번호는 콜론으로 잇고, base-64로 인코딩해서 사용자 이름과 비밀번호에 쉽게 국제문자를 포함할 수 있게 하고, 네트워크 트래픽에 사용자 이름과 비밀번호가 노출되지 않게 한다. Authorization: Basic base-64로 인코딩한 사용자 이름과 비밀번호 |
기본 인증의 보안 결함
기본 인증은 단순하고 편리하다. 그래서 누군가가 의도치 않게 리소스에 접근하는 것을 막는 데 사용하거나, SSL 같은 암호 기술과 혼용한다.
아래는 기본 인증의 보안 결함이다.
- 사용자 이름과 비밀번호를 쉽게 디코딩할 수 있는 형식으로 네트워크에 전송한다. base-64 인코딩된 사용자 이름과 비밀번호는 인코딩 절차를 반대로 수행하면 어렵지 않게 디코딩할 수 있다. 어떤 외부인이 기본 인증으로 보낸 사용자 이름과 비밀번호를 가로챈다면 문제가 된다.
- 디코딩하기에 더 복잡한 방식으로 인코딩되어 있다고 하더라도, 여전히 제삼자는 재전송 공격을 할 수 있다.
- 기본 인증이 중요하지 않은 웹사이트에 사용된다 하더라도, 많은 사용자들은 모든 사이트에 같은 인증 정보를 사용하므로 문제가 될 수 있다.
- 메시지의 인증 헤더를 건드리지는 않지만, 그 외 다른 부분을 수정해서 트랜잭션의 본래 의도를 바꿔버리는 프락시나 중개자가 중간에 개입하는 경우, 기본 인증은 정상적인 동작을 보장하지 않는다.
- 기본 인증은 가짜 서버의 위장에 취약하다. 만약 사용자가 가짜 서버나 가짜 사이트에 연결되어 있는데도 정상 서버나 정상 사이트라고 믿는다면, 공격자는 사용자에게 인증 정보를 요청하고 그것을 나중에 사용할 목적으로 저장한 다음 에러가 난 척을 할 것이다.
'CS > Network' 카테고리의 다른 글
| HTTP: 엔터티와 인코딩 (1) | 2023.03.27 |
|---|---|
| HTTP: 보안 HTTP (0) | 2023.03.24 |
| HTTP: 클라이언트 식별과 쿠키 (0) | 2023.03.20 |
| HTTP: 캐시 (0) | 2023.03.13 |
| HTTP: 웹 서버 (0) | 2023.03.13 |