[보안이슈] OAuth Misconfiguration(1) : 정의

[보안이슈] OAuth Misconfiguration(1)

 

01___Intro

최근, 버그 바운티를 조금씩 진행하면서 자주 발생하게 되는 취약점들을 정리하고 있다.
최근 로그인 기능들이 OAuth 환경을 지원하면서 많은 취약점들이 발생하고 있다.

이에 대해 알아보기로 하자.

 

02___What is OAuth ?

인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹세아트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로 사용되는, 접근 위임을 위한 개방형 표준이다.
-위키백과-

OAuth에는 1.0과 2.0이 존재한다.
여기서 우리는 2.0에 대해서만 알아보기로 하자.
(1.0은 시간이 날 때 차 후에 정리하겠다)

 

03___What is OAuth 2.0 ?

OAuth 2.0은 1.0의 유저 인증플로우, 전반적인 목적만을 공유하고, 1.0을 새로 작성한 것이다. 이 둘의 차이점은 웹 애플리케이션, 앱 애플리케이션, 데스크탑 애플리케이션 등의 인증방식을 강화하고 Consumer에 개발 간소화를 중심으로 개발되었다.

 

04___OAuth 1.0 vs OAuth 2.0 Difference

1.0과 2.0의 차이점은 인증 절차가 간소화됨으로써 개발자가 이를 구현하기 더 쉬워졌고, 기존에 사용하던 용어도 변경되며 Authorization server와 Resource 서버의 분리가 명시적으로 되었다. 또한, 다양한 인증 방식을 지원하게 되었다.

1) 인증 절차 간소화

- 기능의 단순화, 기능과 규모의 확장성 등을 지원하기 위해 만들어졌다.
- 기존의 OAuth 1.0은 디지털 서명 기반이었지만, OAuth 2.0의 암호화는 HTTPS에 맡김으로써 복잡한 디지털 서명에 관한 로직을 요구하지 않기 때문에 구현 자체가 개발자 입장에서 쉬워졌다.

2) Resource Server와 Authorization Server서버의 분리

- 커다란 서비스는 인증 서버를 분리하거나 다중화 할 수 있어야 함.
- Authorization Server의 역할을 명확히 함.

3) 다양한 인증방식(Grant_type)

- Authorization Code Grant
- Implicit Grant
- Resource Owner Password Credentials Grant
- Client Credentials Grant
- Device Code Grant
- Refresh Token Grant

 

05___OAuth 2.0 종류

01_ Authorization Code Grant

일반적인 웹사이트에서 소셜로그인과 같은 인증을 받을 때 가장 많이 쓰는 방식으로 기본적으로 지원하고 있는 방식이다. 아래는 Authorization Code Grant type 으로 Access Token을 얻어오는 시퀀스 다이어그램이다.

1. 먼저 클라이언트가 Redirect URL을 포함하여 Authorization server 인증 요청을 한다.
2. AuthorizationServer는 유저에게 로그인창을 제공하여 유저를 인증하게 된다.
3. AuthorizationServer는 Authorization code를 클라이언트에게 제공해준다.
4. Client는 코드를 Authorization server에 Access Token을 요청한다.
5. Authorization 서버는 클라이언트에게 Access token을 발급해준다.
6. 그 Access token을 이용하여 Resource server에 자원을 접근할 수 있게 된다.
7. 그이후에 토큰이 만료된다면 refresh token을 이용하여 토큰을 재발급 받을 수 있다.

 

02_ Implicit Grant

Public Client인 브라우저 기반의 애플리케이션(Javascript application)이나 모바일 애플리케이션에서 바로 Resource Server에 접근하여 사용할 수 있는 방식이다.

1. 클라이언트는 Authorization server에 인증을 요청한다.
2. 유저는 Authorization server를 통해 인증한다.
3. Authorization server는 Access token을 포함하여 클라이언트의 Redirect url을 호출한다.
4. 클라이언트는 해당 Access token이 유효한지 Authorization server에 인증요청한다.
5. 인증서버는 그 토큰이 유효하다면 토큰의 만기시간과함께 리턴해준다.
6. 클라이언트는 Resource server에 접근할 수 있게된다.

 

03_ Resource Owner Password Credentials Grant

Client에 아이디/패스워드를 받아 아이디/패스워드로 직접 access token을 받아오는 방식이다. Client가 신용이 없을 때에는 사용하기에 위험하다는 단점이 있다. 클라이언트가 확실한 신용이 보장될 때 사용할 수 있는 방식이다.

1. User가 Id와 Password를 입력한다
2. 클라이언트는 유저의 id와 password와 클라이언트 정보를 넘긴다.
3. Authorization sever는 Access token을 넘긴다.

 

04_ Client Credentials Grant

애플리케이션이 Confidential Client일 때 id와 secret을 가지고 인증하는 방식이다.

1. 클라이언트 정보를 Authorization server에 넘긴다.
2. Access Token을 Client에 전달한다.

 

05_ Device Code Grant

장치 코드 부여 유형은 브라우저가 없거나 입력이 제한된 장치에서 사용됩니다.

 

06_ Refresh Token Grant

기존에 저장해둔 리프러시 토큰이 존재할 때 엑세스토큰 재발급 받을 필요가 있을 때 사용한다. 그리고 기존 액세스는 토큰이 만료된다.