Security

OAuth 2.0 대표 취약점과 보안 고려 사항 알아보기

NHN

2017년 3월 2일

원문에서 보기 ↗

1. OAuth 2.0 이란?

OAuth 2.0은 다양한 플랫폼 환경에서 권한 부여를 위한 산업 표준 프로토콜입니다.

(정의) 제 3의 앱이 자원의 소유자인 서비스 이용자를 대신하여 서비스를 요청할 수 있도록 자원 접근 권한을 위임하는 방법 출처 : 금융보안원 "OAuth 2.0 개요 및 보안 고려사항" 보안연구부-2015-030

어떤 서비스를 이용하실 때 페이스북이나 구글 아이디로 회원가입이 가능한 것을 보신적이 있으실텐데요~

OAuth 2.0은 페이스북이나 구글의 아이디로 제 3의 서비스에 로그인해서 등록되어 있는 정보(친구 목록)나 기능(담벼락 글쓰기)에 접근할 수 있는 권한을 제어하기 위한 표준 프로토콜입니다.

시작 전 용어 정리

사용자 : Resource Owner
ex) 일반 사용자

클라이언트 : Client
ex) 구글, 페이스북 아이디로 로그인이 가능한 서비스. 제 3의 서비스.

API 서버 : Resource Server
ex) 이름, 나이 등 아이디 관련 정보를 제공하는 서버. 구글, 페이스북 등.

권한 부여 서버 : Authorization Server
ex) 로그인을 통해 인증 후 권한을 부여하는 서버. 구글, 페이스북 등.

인증 서버 : Authentication Server
ex) 실제로 로그인 서비스를 제공하는 서버. 구글, 페이스북 등

`Authorization Code Grant` 방식

OAuth 2.0는 총 4 가지 인증 방법을 갖고 있는데, 그 중 비교적 안전한 Authorization code grant 방식의 인증 과정을 소개합니다. [그림 1]은 페이코에서 적용한 인증 프로세스로 Authorization code grant 방식을 사용하고 있습니다. 자세한 내용은 https://developers.payco.com/guide/development/start에서 확인할 수 있습니다.

1 (1).png [그림 1] 페이코의 OAuth 2.0 프로세스

2. 대표 보안 취약점 - CSRF, Covert Redirect

2.1 CSRF 공격을 통한 계정 탈취

SNS 계정 연동할 수 있는 서비스는 [그림 2]와 같이 하나의 서비스에 여러 개의 SNS 계정을 연결할 수 있습니다. 계정을 연동하기 위해서는 OAuth 인증 과정을 통하는데, 이 때 CSRF 공격으로 피해자 계정에 공격자 계정을 연동할 수 있습니다.

[그림 2] 여러 개의 SNS 계정이 연결된 사례

서비스의 계정 연동을 아래 "SNS 계정 연동 FLOW"처럼 진행하는 경우가 있습니다.

SNS 계정 연동 FLOW

1. 기존 계정과 SNS 계정 연동 요청
2. 요청 SNS 로그인 페이지 출력 (Client ID 값이 포함된 로그인 페이지)
3. ID/PW 를 통해 SNS 계정에 로그인
4. 로그인 성공 시 인증 서버로부터 Authorization code를 발급 받음 (Authentication Server -> 사용자)
5. 발급 받은 code 값과 state 값을 Client 서버로 전송 (사용자 -> Client Server)
6. code 값과 state 값 검증 후 Client 서버에 로그인 되어있는 계정과 SNS 계정이 연동됨

여기서 state 값은 CSRF token 역할을 하는데, 만약 state 값에 대해 검증이 누락되어 있거나 미흡할 경우 사용자 계정을 탈취할 수 있습니다. 5번 과정에서 Client 서버로 전송하는 내용을 추출하여 만든 CSRF 공격 페이지에 사용자(피해자)가 접근하면, 사용자(피해자) 계정과 공격자 계정이 연동되며, 공격자의 SNS 계정을 통해 사용자(피해자) 계정으로 로그인을 할 수 있습니다.

2.2 Covert Redirect

OAuth 2.0 인증 Flow 중 redirect_uri 파라미터 값에 대해 검증이 누락되거나 미흡할 경우 발생하는 취약점입니다.

정상적인 경로라면 사용자(Resource Owner)가 로그인 성공 후 발급받은 Authorization code를 Client로 전달해야합니다. 그러나 [그림 3]과 같은 방법으로 공격자는 사용자(피해자)에게 변조된 Redirect URI를 보내 로그인을 유도합니다. 4번 단계에서 사용자(피해자)가 Redirect URI 값이 변조된 URL로 로그인할 경우, Authorization code 값이 공격자 서버로 전달되어 공격자는 사용자(피해자)의 계정을 탈취할 수 있습니다.

[그림 3] Redirect URI 파라미터를 이용한 계정 탈취 과정

대응 방안은 Authorization Server 에서 Redirect URI 값에 대해 Full Path 검증을 진행해야합니다. 만일 도메인까지만 검증하거나 일부 경로까지만 검증하도록 조치할 경우, Redirect 취약점이 존재하는 Client는 여전히 Authorization code를 탈취할 수 있습니다.

예시)

http://client.co.kr/OAuth/Callback?code=XXXXXXXXXXXXXXXXXXXX 에서 도메인까지만 검증할 경우
http://client.co.kr/logout?returnURL=http%3a%2f%2fattacker.NulLBr4in.com%2fcode%2f 로 변조하게되면
도메인이 동일하여 검증을 우회하고 공격자 서버로 code를 전송합니다.

위 예시처럼 도메인까지만 검증할 경우, code 값에 Query string이 포함되서 공격자 서버로 전달되거나 HTTP 헤더의 Referer를 참고하여, Authorization code 값을 탈취할 수 있습니다.

3. 보안 검수 항목

OAuth의 경우 취약점이 발생하면 사용자 계정 탈취로 이어지기 때문에 적용 및 구현할 때 보안에 좀 더 신경을 써서 진행해야합니다. [그림 4]는 OAuth 2.0를 적용할 때 고려할 보안 검수 항목과 검수 방법으로 구성해봤습니다.

[그림 4] OAuth 2.0 보안 검수 항목

4. 마무리

OAuth 2.0 은 안전하지만 구현이 매우 복잡하기로 유명합니다.

복잡함 때문에 실제로도 OAuth 2.0를 제공하는 많은 서비스에서 취약점이 발견되고 있는데요, 구현만 제대로 한다면 안전하지만 매우 복잡하다보니 취약점이 존재할 확률이 높은 것 같습니다.

심지어 취약점이 발생할 경우 사용자 계정 탈취로 이어질 수 있으므로 OAuth 2.0 구현 시 충분한 이해와 준비, 검토가 요구되며 서비스 오픈 이후에도 꾸준한 보안 검수를 통해 취약점이 발생하지 않도록 관리가 필요합니다.

끝으로, OAuth 2.0 Authorization code grant 인증 방식 도표를 활용하여 취약점을 보완하기 위한 설명으로 마무리하겠습니다.

[그림 5] OAuth 2.0 Authorization code grant 인증 방식의 취약점 보완 방안

읽어주셔서 감사합니다. 혹시 내용에 오류나 의견이 있으시면 편하게 연락주세요!

5. 참고 자료

https://tools.ietf.org/html/rfc6749 https://developers.payco.com/guide/development/starthttps://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-06https://developers.payco.com/guide/development/start https://developers.payco.com/guide/development/starthttps://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-06https://developers.payco.com/guide/development/start http://secuinside.com/archive/2016/2016-1-6.pdf https://oauth.net/advisories/2014-1-covert-redirect/ https://spring.io/blog/2011/11/30/cross-site-request-forgery-and-oauth2 http://www.twobotechnologies.com/blog/2014/02/importance-of-state-in-oauth2.html [문서] OAuth2.0 개요 및 보안 고려사항. (보안연구부 보안기술팀 / 2015.12.14) - 금융보안원