1. OAuth 토큰 보안 취약점
1.1 Bearer Token
OAuth 2.0에서는 Bearer token을 보안 장치로 정의하고 있다. 이 토큰을 가진 사람이라면, 누구나 토큰을 사용하고 있다. 이런 결정은 OAuth 1.0 매커니즘에서 오는 여러 문제점들을 제거하기 위함이다. OAuth 1.0은 보호된 리소스가 토큰과 시그니처를 함께 검증해서 토큰과 연관된 시크릿도 같이 소유하고 있음을 확인했다. 때문에 시그니처 탈취 방지를 위해 TLS도 같이 사용해야 한다는 요구사항도 있었다. 여기서 TLS 사용, 시그니처를 정확히 계산해야 한다는 부담이 문제가 되어 복잡하고 사용하기 어렵다는 평이 많았다.
1.2 Bearer 토큰 사용 시 발생할 수 있는 위험
Bearer 토큰은 세션 쿠키와 유사한 특징을 가지고 있기 때문에 보안과 관련된 문제가 발생할 수 있다. 공격자가 토큰을 탈취한다면, 해당 토큰이 인가하는 모든 리소스에 접근할 수 있게 된다. 때문에 OAuth에서는 SSL/TLS와 같이 종단간 기밀성을 보장하는 방법을 사용해 access token 전송을 해야한다.
우선 토큰과 세션 쿠키의 공통점, 차이점을 비교해보자.
- 공통점
- 평문으로된 문자열 사용
- 시크릿이나 시그니처를 포함하지 않는다
- 보안 떄문에 TLS를 기본적으로 사용해야 한다
- 차이점
- 웹 브라우저에서는 쿠키를 오래전부터 사용했지만, OAuth 클라이언트에서는 그렇지 않다
- 웹 브라우저에서는 CORS로 인해 상이한 도메인 간 쿠키 전달이 안되지만, OAuth 클리이언트는 그렇지 않다.
토큰 탈취와 더불어 OAuth Bearer token 사용을 발생할 수 있는 위험은 다음과 같다.
- 토큰 위조: 공격자가 자신의 토큰을 만들거나, 기존에 유효한 토큰을 변조해 리소스 서버가 클라이언트에게 접근 권한을 인가하게 만들 수 있다.
- 토큰 재사용: 기간이 만료된 토큰을 이용 시도한다. 이 떄, 리소스 서버는 어떠한 유효 데이터도 전달하면 안된다
- 토큰 리다이렉트: A 리소스 서버에서 만들어진 토큰을 이용해 B 리소스 서버에 접근하려 한다. 이 때, 리소스 서버 B는 토큰이 유효하다고 판단해서는 안된다.
- 토큰 유출: 토큰에 민감한 정보가 포함되어 있다면, 공격자가 해당 정보를 취득할 수 있다.
1.3 구성요서 별 보안 위협과 대응책
OAuth 2.0 각 구성 요소에서 발생할 수 있는 Bearer token 관련 보한 위협과 대응책에 대해 알아보자.
- 클라이언트에서 탈취
- 클라이언트에게는 Bearer access token에 대한 어떤 암호화도 요구되지 않는다. 따라서 클라이언트에서 탈취된다면, 토큰이 허용하는 모든 리소스에 접근할 수 있게 된다.
- 대응책: 작업에 필요한 최소한의 권한 범위만 공유한다.
- 인가 서버에서 탈취
- 공격자가 인가 서버 DB에 접근할 수 있다면, 여러 리소스 소유자의 보안이 침해될 수 있다. 인가 서버는 보통 토큰을 DB에 저장하기 때문이다.
- 대응책:
- 액세스 토큰 자체를 저장하는 대신, 액세스 토큰의 해시 값을 저장하면 된다.
- 토큰 유출에 대비해 액세스 토큰 유효 기간을 짧게 유지한다. API 사용에 필요한 평균 기간보다 유효 기간이 짧으면 좋다.
- 전반적인 보안 감사, 로깅을 진행한다. 토큰 발급, 폐기에 대한 세부 내용(클라이언트, 리소스 소유자, 권한 범위, 리소스, 시간 등)에 의심스러운 행위가 있는지 관측해야 한다.
- 보호된 리소스에서 탈취
- 인가 서버와 유사한 방식으로 액세스 토큰을 처리하기에, 인가 서버와 같은 방식의 대응책이 필요하다.
- 추가 대응책:
- 액세스 토큰은 시스템 로그상에서, 특히 분석을 위해 인입되는 모든 HTTP 트래픽 캡처에서 유출될 수 있다. 때문에 로그에서 토큰 값을 제거해야 한다.
- 리소스 엔드 포인트는 데이터 수집 최소화 원칙, 특정 작업을 수행하기 위해 필요한 최소한의 권한 범위만 요청하게 설계돼야 한다.