12. 기본 인증
웹은 많은 사람들이 편리하게 접근하고 공유할 수 있는 공간이다.
하지만 공유하길 원하지 않는 정보들에 대해 허가된 사용자만이 접근할 수 있는 공간의 필요성도 존재한다
12.1 인증
인증의 기본 개념은 사용자가 누구인지 증명하는 것이다
물론 완벽한 인증은 존재하지 않지만, 정보가 많을수록 제대로 식별할 가능성이 높아진다
12.1.1 HTTP의 인증요구/응답 프레임워크
HTTP는 자체 인증요구/응답 프레임워크를 제공한다
서버는 인증 요청을 하고, 클라이언트는 사용자의 인증 정보를 첨부해 다시 요청을 보낸다
12.1.2 인증 프로토콜과 헤더
HTTP는 customize 가 가능한 제어 헤더를 통해 여러 인증 프로토콜에 맞게 확장할 수 있는 프레임워크를 제공한다
네 가지 인증 단계
요청
인증 요구
Basic : 기본 인증 스킴으로 ID/PW 를 base64 encoding 하여 전달
realm : 인증을 요구하는 공간이나 범위에 대한 설명
인증
WWW-Authenticate 헤더에 정의된 스킴에 맞춰 Authorization 헤더에 ID/PW 쌍을 기술하여 전송
Authentication-info
추가적인 인증 알고리즘에 대한 정보를 기술
12.1.3 보안 영역
HTTP가 각 리소스마다 다른 접근 조건을 다루는 방법
realm (보안 영역)
접근이 제한된 문서들을 realm 그룹으로 나눔
realm 그룹은 각각 다른 사용자 권한을 요구
realm 은 사용자가 권한의 범위를 이해하는 데 도움이 되는 형식으로 설정되어야 한다
12.2 기본 인증
웹 서버는 클라이언트의 요청을 거부하고 ID/PW 를 요구할 수 있다
401 status code 와 함께 WWW-Authenticate 헤더에 스킴과 realm 을 기술하여 응답을 내려 인증 요구를 시작
Authentication-Info 헤더를 사용하지 않음
12.2.2 Base-64 사용자 이름/비밀번호 인코딩
HTTP기본 인증은 사용자 이름과 비밀번호를 콜론으로 이어서 합치고 base-64 인코딩을 한다
binary data 를 6bits 단위로 끊어 공통의 ASCII 문자로 변환
왜 base64 인코딩을 하지? base64 인코딩은 6bits 를 하나의 character 로 변환하기 때문에 2bits 의 overhead 가 발생하며, encode-decode 과정에서 추가적인 cpu 연산까지 발생하는데 왜 base64 encoding 을 해서 전송하는 것일까?
ASCII 는 7bits encoding 방식을 사용하기 때문에 남은 1bit 의 처리가 시스템별로 다르게 구현되어 있을 수 있다. 또한 일부 제어문자의 경우 시스템별로 다른 코드값을 가진다
따라서 공통 ASCII 코드문자로만 이루어진 데이터를 전송하여 예상치 못한 호환 문제를 방지하고, 추가적으로 HTTP 헤더에서 사용할 수 없는 문자를 포함한 문자열을 처리하기 위해 base64 encoding 을 사용하는 것
12.2.3 프락시 인증
프락시 서버를 사용하면 접근 정책을 중앙 관리할 수 있어 프락시를 통한 사용자 인증을 사용하는 경우도 있다
12.3 기본 인증의 보안 결함
기본 인증은 해당 요청이 탈취당했을 경우 누구나 쉽게 디코딩해서 인증 정보를 확인할 수 있다
탈취당해도 원본을 확인할 수 없는 TLS 같은 암호화 채널을 사용하거나 다이제스트 인증 같은 프로토콜을 사용
탈취한 인증 정보를 직접 디코딩 할 수 없더라도 서버로 해당 문자열들 그대로 보내 인증에 성공할 수 있다
기본 인증은 재전송 공격을 방지하기 위한 장치가 없음
중간에 프락시와 같은 중개자에 의해 인증 헤더가 아닌 다른 부분을 수정하여 트랜잭션의 의도를 바꾸는 경우 정상적인인증 동작을 보장하지 않는다
인증 정보를 요청하는 가짜로 위장한 서버에 대한 대책이 없다
기본인증은 우연한 사고를 예방하기 위한 1차적인 방어수단정도로 사용된다
Last updated
