이 글에서는 Cookie Tossing에 대해 설명한다.
해당 내용은 https://labs.snyk.io/resources/hijacking-oauth-flows-via-cookie-tossing/ 블로그를 참고했다.
Cookie Tossing이란
Cookie Tossing이란 공격자가 웹사이트의 하위 도메인을 이용하여 악의적인 쿠키를 상위 도메인으로 보내는 공격 기법이다.
Cookie 설정 방법
Cookie는 HTTP Response의 Set-Cookie 헤더나 JS Cookie API를 통해 설정할 수 있다.
Set-Cookie 헤더를 이용하는 경우
HTTP Response에 Set-Cookie를 포함해 쿠키를 설정할 수 있다.
예시는 아래와 같다.
HTTP/1.1 200 OK
Set-Cookie: userId=patch01; Expires=Wed, 21 Oct 2024 07:28:00 GMT; Domain=.snyk.io; Path=/; Secure; HttpOnly; SameSite=Lax
Javascript를 이용하는 경우
document.cookie = "userId=patch01; expires=Wed, 21 Oct 2024 07:28:00 GMT; path=/; domain=.snyk.io; secure; samesite=lax";
위 예시를 보면 Cookie에는 여러 attribute가 있고 그 중에는 Domain이라는 attribute가 있다.
Domain attribute란
Cookie의 Domain attribute는 어떤 도메인이 쿠키에 접근할 수 있는지 지정하는 것이다.
기본적으로 쿠키는 쿠키를 설정한 도메인에서만 접근이 가능하지만 Domain 속성을 사용하면 쿠키의 접근 범위를 확장할 수 있다.
즉 a.example.com에서 Domain=.example.com으로 쿠키를 설정하면 example.com의 하위 도메인인
b.example.com이나 example.com등 example.com의 모든 서브도메인에서 접근할 수 있다.
하지만 특정 서브 도메인만을 위한 쿠키는 설정할 수 없다.
Cookie에는 Domain 속성 말고 다른 속성들도 더 있다.
그 중 하나가 Path라는 속성이다.
Path attribute란
Path 속성은 Cookie가 적용되는 URI를 지정한다.
예를 들어 Path=/account로 설정된 쿠키는 /account와 /account/setting 등 하위 디렉터리에서 접근할 수 있다.
그리고 Cookie는 Path 속성에 따라서 순서가 정해진다.
Path 값이 더 구체적으로 적혀 있다면 그 쿠키가 앞에 위치하게 되어 전송된다.
즉 Path 값이 /account/setting인 Cookie가 Path 값이 /account인 Cookie보다 앞에 위치하여 먼저 전송된다는 얘기이다.
(이걸 이용해서 Cookie Sandwich라는 공격을 수행해서 HttpOnly가 설정된 쿠키를 탈취할 수 있다. 이건 나중에 글로 쓸 예정)
Exploiting Cookie Tossing
공격을 하기 전에 사전 조건이 하나 필요하다.
바로 XSS나 다른 취약점 등으로 서브 도메인을 제어할 수 있어야 한다는 것이다.
서브 도메인을 제어할 수 있다면 부모 도메인에 쿠키를 설정할 수 있다.
그리고 위에서 설명했던 Domain, Path 속성을 이용해서 Cookie Tossing 공격을 할 수 있다.
예를 들어 공격자가 a.example.com에서 Domain=.example.com & Path=/api/payment로 쿠키를 설정할 수 있다고 가정해보자.
피해자가 example.com을 정상적으로 이용하다가 a.example.com에 접속하면 위 속성 값을 가진 쿠키가 설정이 된다.
그 후에 피해자는 정상적으로 행동을 하다가 결제 카드 추가 등 민감한 데이터를 처리하는 특정 API 엔드포인트(/api/payment)에 접근하면 애플리케이션은 공격자가 설정한 쿠키를 사용하게 된다.
그 결과 피해자의 결제 카드가 공격자의 계정의 추가되는 상황이 일어날 수 있다.
Gitpod 사례
먼저 Gitpod이란 웹 브라우저에서 바로 코딩 및 개발을 할 수 있도록 만들어진 클라우드 기반의 개발 환경이다.
Gitpod은 각 사용자의 개발 환경을 작업공간ID.gitpod.io와 같은 서브 도메인 주소로 제공한다.
그리고 이 환경에서는 Javascript를 실행할 수 있다고 한다.
이것이 전제 조건인 서브 도메인을 제어를 만족시키는 부분이다.
이 점을 이용해 Gitpod과 Github 또는 BitBucket 같은 외부 코드 저장소를 연동하는 과정(OAuth Flow)을 탈취할 수 있다면 피해자의 모든 소스 코드에 접근할 수 있다.
공격 과정은 아래와 같다.
1. 공격자는 자신의 Gitpod workspace(example.gitpod.io)에 Cookie를 설정하게 만드는 JS 코드를 설정한다.
이 코드는 공격자 자신의 로그인 세션 쿠키인 _gitpod_io_jwt2_를 저장하게 만든다.
이때 핵심은 쿠키의 Path 속성을 OAuth 인증 과정에서 사용되는 특정 API 경로(/api/authorize, /auth/bitbucket/callback)로 구체적으로 설정한다.
2. 공격자는 자신의 Workspace URL을 피해자에게 전달한다.
3. 피해자가 URL을 클릭하면 피해자의 브라우저에 공격자의 세션 쿠키가 저장이 된다. 이때까지 피해자는 별다른 이상 없다.
4. 피해자가 자신의 BitBucket 계정을 Gitpod에 연동하려고 시도할 때 문제가 발생한다.
Gitpod 서버는 인증을 시작하려 할 때, 피해자의 브라우저에 저장된 쿠키를 확인한다.
이때 Path 속성 때문에 일반적인 요청에서는 피해자의 쿠키가 사용되지만, OAuth 인증 경로(/api/authorize)에서는 공격자의 쿠키가 더 높은 우선순위를 갖게 되어 서버로 전송된다.
5. Gitpod 서버는 이 요청을 공격자가 보낸 것이라고 판단하고 공격자의 계정으로 인증 절차를 시작한다.
6. 피해자는 화면에 나타난 BitBucket 인증 창에서 정상적으로 자신의 계정 접근을 승인한다.
7. 인증이 완료되면 BitBucket은 피해자의 계정 정보를 Gitpod으로 넘겨준다.
8. 최종적으로 피해자의 BitBucket 계정이 공격자의 Gitpod 계정과 연동된다.
위 공격 과정으로 피해자의 계정을 탈취할 수 있다.
Cookie Tossing으로 위와 같은 일 들이 벌어질 수 있다.
그렇다면 막는 방법은 무엇일까?
Host Prefix
Cookie Tossing은 Host 접두사를 이용해 막을 수 있다.
Host 접두사는 Secure 속성이 있어야 하며 Path 속성은 반드시 /로 지정되어야 한다.
또한 Domain 속성을 포함할 수 없게 되어 Host 접두사는 Cookie Tossing을 막을 수 있다.
다만 이 Host 접두사 역시 우회가 가능하다!
이 내용 역시 추후에 다룰 예정.
'Attack Method' 카테고리의 다른 글
| Cookie Sandwich (4) | 2025.08.31 |
|---|