OAuth 취약점과 공격 패턴

OAuth 권한 부여 서버는 redirect_uri 매개변수를 엄격하게 검증해야 합니다. 서버가 접두사 일치 또는 와일드카드 일치(예: "https://app.example.com"으로 시작하는 모든 URL 허용)를 허용하면, 공격자는 "https://app.example.com.attacker.com/steal"로 리디렉션하거나 정상 도메인의 오픈 리디렉션을 이용하는 권한 부여 요청을 만들어 권한 부여 코드를 탈취할 수 있습니다.

CSRF 방어가 없으면 공격자가 OAuth 흐름을 시작하고 피해자의 브라우저가 권한 부여를 완료하도록 속일 수 있습니다. 피해자는 자신도 모르게 공격자의 클라이언트를 승인하게 됩니다. "state" 매개변수(RFC 6749)가 이를 방지합니다. 클라이언트는 임의의 state를 생성하여 요청에 포함하고 콜백에서 값이 일치하는지 확인합니다. 일치하지 않으면 흐름을 중단합니다.

모바일 플랫폼에서는 악성 애플리케이션이 정상 OAuth 클라이언트와 동일한 사용자 지정 URI 스킴을 등록하여 사용자가 인증한 후 리디렉션되는 권한 부여 코드를 가로챌 수 있습니다. PKCE(RFC 7636)가 완전한 방어책입니다. 흐름 시작 시 정상 애플리케이션만 생성한 코드 검증자가 없으면 가로챈 코드는 쓸모가 없습니다.

ID 토큰이나 액세스 토큰이 URL 프래그먼트 또는 쿼리 매개변수에 포함되면, 해당 페이지에서 이어지는 탐색 요청이 URL을 Referer 헤더에 포함하여 토큰이 타사 분석 스크립트나 CDN 제공자에게 유출될 수 있습니다. 토큰이 URL에 나타나지 않도록 항상 백채널 토큰 전달을 사용하는 권한 부여 코드 흐름을 사용해야 합니다.

클라이언트가 여러 OAuth 제공자를 지원할 때 혼동 공격을 통해 클라이언트가 제공자 A에서 얻은 권한 부여 코드를 제공자 B의 토큰 엔드포인트로 보내도록 만들 수 있습니다. 클라이언트는 ID 토큰의 "iss" 클레임을 검증하고, state 매개변수 또는 JARM(JWT로 보호되는 권한 부여 응답 모드)을 사용하여 콜백을 흐름을 시작한 특정 제공자에 결합해야 합니다.

서버 측 요청 위조(SSRF) 공격은 redirect_uri로 서버 측 HTTP 요청을 보내는 OAuth 구현을 대상으로 합니다. 권한 부여 서버가 확인을 위해 redirect_uri를 가져오면 공격자는 내부 IP 주소(예: http://169.254.169.254/latest/meta-data/)를 제공하여 클라우드 인스턴스 메타데이터 또는 내부 서비스에 액세스할 수 있습니다. 엄격한 허용 목록 기반 redirect_uri 검증으로 이를 방지할 수 있습니다.

많은 애플리케이션은 OIDC ID 토큰의 이메일 클레임을 사용하여 여러 제공자 사이의 계정을 연결합니다. 공격자가 다른 제공자에서 피해자의 계정과 일치하는 이메일 주소를 제어하면, 해당 이메일로 다른 제공자에 가입하여 피해자 계정에 액세스할 수 있습니다. 방어 방법은 이메일만이 아니라 (iss, sub) 쌍으로만 계정을 연결하는 것입니다.

JWT 알고리즘 혼동 공격은 검증 알고리즘을 선택하기 위해 "alg" 헤더를 신뢰하는 구현의 취약점을 악용합니다. 공격 방법: "alg"를 "RS256"에서 "HS256"으로 변경하고 서버의 공개 키를 HMAC 비밀 키로 사용하여 토큰에 서명합니다(공개 키이므로 공개되어 있음). 방어 방법: 검증 코드에 예상 알고리즘을 항상 명시하고 토큰 헤더의 alg 클레임을 절대 신뢰하지 않습니다.

공격자는 정상적으로 보이는 이름과 로고로 악성 OAuth 클라이언트를 등록한 다음 대상에게 피싱 링크를 보냅니다. 피해자는 Google, Microsoft 등이 호스팅하는 진짜 OAuth 동의 화면에서 악성 애플리케이션에 대한 화면을 보고 액세스 권한을 부여합니다. 방어 방법은 client_id가 예상한 애플리케이션에 해당하는지 확인하는 것입니다. Google과 Microsoft는 정상 애플리케이션을 위한 클라이언트 검증 프로그램을 제공합니다.

범위 상승은 클라이언트가 사용자가 승인한 범위보다 더 광범위한 권한을 가진 토큰을 얻을 때 발생합니다. 토큰 엔드포인트에서 범위 검증을 건너뛰거나, 서로 다른 요청의 범위가 합쳐진 토큰을 캐시하거나, 발급된 토큰의 범위가 승인된 범위를 초과하지 않는지 검증하지 않는 구현 결함은 모두 OAuth를 통한 권한 상승으로 이어질 수 있습니다.

OAuth 구현은 다음과 같이 방어해야 합니다. redirect_uri를 정확히 일치하도록 검증하고, 모든 공개 클라이언트에 PKCE를 요구하며, CSRF 방어를 위해 state 매개변수를 검증하고, 이메일이 아니라 (iss, sub)로 ID 토큰을 결합하며, 예상하는 JWT 알고리즘을 명시하고, 최소한의 범위를 요청하고, 짧은 수명의 액세스 토큰과 리프레시 토큰 순환을 사용하며, 브랜드 사칭 위험을 확인하기 위해 동의 화면의 표시를 감사해야 합니다.

OAuth 권한 부여 서버가 "https://app.example.com"으로 시작하는 모든 redirect_uri를 허용합니다. 어떤 공격이 가능합니까?

주요 OAuth 공격은 다음과 같습니다. 느슨한 redirect_uri 검증을 통한 오픈 리디렉션(정확히 일치하도록 사용), state 매개변수 누락을 통한 CSRF, 모바일에서의 코드 가로채기(PKCE로 완화), URL 내 토큰 유출, 다중 제공자 설정에서의 혼동(iss 검증), 서버가 가져오는 redirect_uri를 통한 SSRF, 이메일 클레임 충돌(iss+sub 사용), JWT 알고리즘 혼동(예상 alg 고정), 가짜 동의 화면을 통한 피싱입니다.