OAuth는 여러 버전을 제공하며, 기본적인 통찰력은 [OAuth 2.0 문서](https://oauth.net/2/)에서 확인할 수 있습니다. 이 토론은 주로 널리 사용되는 [OAuth 2.0 인가 코드 그랜트 유형](https://oauth.net/2/grant-types/authorization-code/)에 중점을 두며, **응용 프로그램이 다른 응용 프로그램의 사용자 계정에 액세스하거나 작업을 수행할 수 있는 인가 프레임워크**를 제공합니다(인가 서버).
가정적인 웹사이트 _**https://example.com**_은 **모든 소셜 미디어 게시물을 쇼케이스**하기 위해 OAuth 2.0을 사용합니다. _https://example.com_은 **소셜 미디어 게시물에 액세스**하도록 권한을 요청합니다. 결과적으로 _https://socialmedia.com_에서 **요청되는 권한 및 요청을 하는 개발자**를 설명하는 동의 화면이 표시됩니다. 귀하의 승인 후, _https://example.com_은 **귀하를 대신하여 귀하의 게시물에 액세스**할 수 있게 됩니다.
5. https://example.com은 `code`를 사용하여 당신을 대신하여 `access_token`을 얻기 위해 서버 측 요청을 만듭니다. 이 과정에서 `client_id`와 `client_secret`가 함께 사용됩니다. 이를 통해 당신이 동의한 권한에 액세스할 수 있게 됩니다:
`redirect_uri`는 OAuth 및 OpenID 구현에서 보안에 중요한 역할을 합니다. 인가 후에 인증 코드와 같은 민감한 데이터가 전송되는 위치를 지정하기 때문입니다. 잘못 구성된 경우, 공격자가 이러한 요청을 악의적인 서버로 리디렉션하여 계정 탈취를 가능케 할 수 있습니다.
악용 기술은 인가 서버의 유효성 검사 논리에 따라 다양합니다. 엄격한 경로 일치부터 지정된 도메인이나 하위 디렉토리 내의 모든 URL을 허용하는 것까지 다양합니다. 일반적인 악용 방법으로는 오픈 리다이렉트, 경로 순회, 약한 정규식 악용 및 토큰 도난을 위한 HTML 삽입이 있습니다.
`redirect_uri` 외에도 `client_uri`, `policy_uri`, `tos_uri`, `initiate_login_uri`와 같은 다른 OAuth 및 OpenID 매개변수도 리디렉션 공격에 취약할 수 있습니다. 이러한 매개변수는 선택 사항이며 지원 범위는 서버마다 다릅니다.
OpenID 서버를 대상으로 하는 경우, 발견 엔드포인트(`**.well-known/openid-configuration**`)는 종종 `registration_endpoint`, `request_uri_parameter_supported`, "`require_request_uri_registration`과 같은 가치 있는 구성 세부 정보를 나열합니다. 이러한 세부 정보는 등록 엔드포인트 및 서버의 기타 구성 세부 정보를 식별하는 데 도움이 될 수 있습니다.
이 버그 바운티 보고서 [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html)에서 언급된 바에 따르면 리디렉트 **URL이 사용자가 인증한 후 서버 응답에 반영**될 수 있으며 **XSS에 취약**할 수 있습니다. 테스트할 가능한 페이로드:
OAuth 구현에서 **`state` 매개변수**의 오용 또는 누락은 **Cross-Site Request Forgery (CSRF)** 공격의 위험을 크게 증가시킬 수 있습니다. 이 취약점은 `state` 매개변수가 **사용되지 않거나 정적 값으로 사용되거나 적절하게 유효성이 검사되지 않을 때** 발생하며, 이로 인해 공격자가 CSRF 보호를 우회할 수 있습니다.
이러한 취약점의 실제 사례는 다양한 **CTF 챌린지** 및 **해킹 플랫폼**에서 문서화되어 있으며, 실제 적용 가능성을 강조합니다. 이 문제는 **Slack**, **Stripe**, **PayPal**과 같은 제3자 서비스와의 통합에도 영향을 미치며, 공격자는 알림이나 결제를 자신의 계정으로 리디렉션할 수 있습니다.
1.**계정 생성 시 이메일 확인 없음**: 공격자는 피해자의 이메일을 사용하여 미리 계정을 생성할 수 있습니다. 피해자가 나중에 로그인을 위해 제3자 서비스를 사용하는 경우, 애플리케이션이 이 제3자 계정을 공격자가 미리 생성한 계정에 부적절하게 연결할 수 있어 무단 액세스로 이어질 수 있습니다.
2.**느슨한 OAuth 이메일 확인 악용**: 공격자는 이메일을 확인하지 않는 OAuth 서비스를 악용하여 해당 서비스에 등록한 후 계정 이메일을 피해자의 이메일로 변경할 수 있습니다. 이 방법은 첫 번째 시나리오와 유사하게 무단 계정 액세스의 위험을 초래하지만 다른 공격 벡터를 통해 발생합니다.
비밀 OAuth 매개변수를 식별하고 보호하는 것이 중요합니다. **`client_id`**는 안전하게 공개할 수 있지만 **`client_secret`**를 공개하면 중대한 위험을 초래할 수 있습니다. `client_secret`가 노출되면 공격자가 애플리케이션의 신원과 신뢰를 악용하여 사용자 `access_token` 및 개인 정보를 **도용**할 수 있습니다.
일반적인 취약점은 애플리케이션이 권한 `code`를 `access_token`으로 교환하는 것을 서버 측이 아닌 클라이언트 측에서 잘못 처리할 때 발생합니다. 이 실수로 인해 `client_secret`가 노출되어 공격자가 애플리케이션의 위장으로 `access_token`을 생성할 수 있습니다. 더 나아가 사회 공학을 통해 공격자는 OAuth 권한에 추가적인 범위를 추가하여 애플리케이션의 신뢰 상태를 더 악용할 수 있습니다.
이 버그 바운티 보고서에서: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) **AWS Cognito**가 사용자에게 돌려주는 **토큰**이 **사용자 데이터를 덮어쓸 충분한 권한을 가질 수 있다는 것**을 볼 수 있습니다. 따라서, **다른 사용자 이메일로 사용자 이메일을 변경**할 수 있다면, 다른 사람의 계정을 **탈취**할 수 있을 수도 있습니다.
[**이 글에서 언급된 것**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts)과 같이, **토큰**(코드가 아닌)을 받기를 기대하는 OAuth 플로우는 토큰이 해당 앱에 속해 있는지 확인하지 않으면 취약할 수 있습니다.
왜냐하면 **공격자**가 **OAuth를 지원하는 애플리케이션을 만들고 Facebook으로 로그인**한 다음 피해자가 **공격자의 애플리케이션**에서 Facebook으로 로그인하면, **공격자는 사용자의 OAuth 토큰을 가져와서 사용자의 사용자 토큰을 사용하여 피해자 OAuth 애플리케이션에 로그인할 수 있습니다**.
[**이 글에 따르면**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), 피해자가 **공격자의 호스트를 가리키는 returnUrl**이 있는 페이지를 열도록 만들 수 있었습니다. 이 정보는 **쿠키(RU)에 저장**되며 **나중 단계에서****프롬프트**가 **사용자에게** 해당 **공격자의 호스트에 액세스를 허용할지 물어볼 것입니다**.
이 프롬프트를 우회하기 위해 **Oauth 플로우를 시작하는 탭을 열어** 이 **RU 쿠키를 설정**할 수 있었고, **프롬프트가 표시되기 전에 탭을 닫고** 그 값을 가지지 않은 새 탭을 열 수 있었습니다. 그러면 **프롬프트는 공격자의 호스트에 대해 알리지 않겠지만**, 쿠키는 그것으로 설정되므로 **토큰은 리다이렉션 시 공격자의 호스트로 전송**됩니다.
OAuth의 Dynamic Client Registration은 **Server-Side Request Forgery (SSRF)** 공격을 위한 덜 명백하지만 중요한 취약성 벡터로 작용합니다. 이 엔드포인트는 OAuth 서버가 클라이언트 애플리케이션에 대한 세부 정보를 받아들일 수 있도록 하며, 이 정보에는 악용될 수 있는 민감한 URL도 포함될 수 있습니다.
- **Dynamic Client Registration**은 주로 `/register`에 매핑되며 `client_name`, `client_secret`, `redirect_uris`, 로고 또는 JSON Web Key Sets (JWKs)의 URL을 포함하는 POST 요청을 통해 세부 정보를 받아들입니다.
- 이 기능은 **RFC7591** 및 **OpenID Connect Registration 1.0**에서 제시된 사양을 준수하며 SSRF에 취약할 수 있는 매개변수를 포함합니다.
<summary><strong>htARTE (HackTricks AWS Red Team Expert)로부터 제로에서 영웅까지 AWS 해킹 배우기</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
