XS_leak

Background

XS leak에 대해 이해하려면 먼저 CORS와 SOP에 대해 알아야 한다.

동일 출처 정책 (Same Origin Policy)

SOP는 동일한 출처에서만 리소스를 공유하도록 유도한다. 동일한 출처란 "프로토콜|호스트|포트"가 모두 같은 곳을 말한다. 즉,

http://123.123.123.12:8000 = http://123.123.123.12:8000 
https://1.1.1.1:8000 != http://1.1.1.1:8000
http://search.naver.com != http://mail.naver.com

이렇게 하나만 달라도 다른 출처로 간주하는 것. 참고로 TLD나 subdomain이 달라도 다른 출처로 간주된다.

 

SOP는 다른 서버, API로 요청을 보내고 응답 받을 수는 있지만, 요청을 받는 것을 막는다. 이게 꽤나 중요한 게, SOP가 없다면 아마 side channel을 이용한 해커들의 공격이 마구잡이로 일어날꺼다. 

 

근데 이렇게만 보면 개발자들에게 있어서 리소스가 너무나도 한정적이다. 특히 외부 API를 못가져오는 건 재앙이나 마찬가지일꺼다. 때문에 이를 완화시키기 위해 CORS라는 게 존재한다.

 

교차 출처 리소스 공유 (Cross Origin Resource Sharing)

CORS는 교차 출처 리소스 공유에 대한 정책이다. SOP에서 교차 출처를 모두 막지만, CORS를 통해 이를 완화하여 특정 출처의 리소스를 공유할 수 있다.

 

CORS 기본 동작

1. 브라우저가 헤더의 Origin 필드에 출처를 담아 보냄

2. 서버가 Access-Control-Allow-Origin: 출처 를 담아 클라이언트에게 전달

3. 클라이언트에서 Origin과 Access-Control-Allow-Origin을 비교

4. 유효하지 않으면 차단

 

위 CORS의 동작을 보면 알 수 있듯, 서버와 브라우저가 상호작용을 통해 리소스를 허용한다. 따라서 결론적으로 CORS를 통해 출처를 허용하려면, 서버가 Access-Control-Allow-Origin 헤더에 허용할 출처를 포함해서 응답하면 되는 것이다.

 

이 외에도 CORS의 동작 방식이 더 있는데, 본 글은 xs leak 설명이 중심이기에 배경 지식 설명은 이 정도면 충분할 것 같다. (Reference를 참조하시길..)

 

XS leak이란?

직역하면 교차 사이트 유출이다. 쉽게 말하면 타겟 사이트의 동작에 기반하여 사이드 채널을 통해 정보를 얻는 것인데, 대략 구조를 그려보자면 

이런 느낌이지 싶다. 여기서 알아야 할 부분이, 앞서 말한 SOP/CORS 모두 브라우저 단에서 이뤄지는 정책들이기 때문에, 우리가 지금 보고 있는 XS leak은 브라우저 단에서 일어나는 취약점이라는 것이다. 이를 먼저 알면 이해하기 편하다. (브라우저 단 취약점이다? ==> JS/HTML을 반드시 공부해라!)

 

웹은 상호 작용할 수 있도록 설계되어 있다. 비단 사용자 뿐만 아니라 다른 사이트 또한 마찬가지이다. iframe, a href, img 등등.. 그리고 이를 안전하게 하도록 브라우저는 SOP를 사용한다. 하지만 SOP로도 해커들을 완벽하게 막을 수는 없었다. 사실 정확히 말하면 개발자들의 웹 설계 방식도 한 몫 하지만..

 

Scenario

XS leak을 유발하는 시나리오는 다양하다. 패턴이 꽤 많아서 XS leak wiki를 참고하는 것을 추천한다.

https://xsleaks.dev/

Introduction

대표적으로 몇 개만 살펴보자면

 

1. Frame Counting

브라우저에서는 window.open() 이나 <iframe>을 사용할 경우 다른 출처의 페이지여도 다음과 같은 속성은 접근이 가능하다.

iframe.contentWindow.length
iframe.contentWindow.frames.length

해당 속성들은 자식 프레임의 개수 (정상 응답만) 를 반환한다. 만약 타겟 페이지에서 <iframe>을 이용해서 입력 결과를 반환한다면 해당 속성들을 이용해서 결과를 유추할 수 있지 않을까? 예를 들어

iframe.src = `타겟 서버/search?query=CLOUD`;

iframe.onload = () => {
  const frameCount = iframe.contentWindow.length;
  if(frameCount >= 1){
      console.log("HIT!!");
  }
};

이런 식으로 말이다. 

 

2. Timing

Timing 기법의 경우 네트워크 환경에 따라 측정이 불안정 할 수 있다. 따라서 여러 번 측정하면서 패턴을 파악하고 측정 결과 간 

비교해야 한다. 예를 들어 DB에서 결과를 가져오는 시간에 따른 패턴이라던가, 결과에 따른 브라우저 렌더링 및 동작 시간을 파악한다던가.. 

누가 봐도 설계 문제인 게 아니면 굉장히 어려운 기법이라고 생각한다. 다만, 공격자에게 어려운 만큼 방어하는 입장에서는 예방하기 더 어렵겠지만.

 

3. Etc.

단순하게 서버의 응답 코드만으로도 정보가 유출될 수 있다. 예를 들어 idx를 조회하는 페이지가 있다면

/my-idx?user=Cloud&idx=101 ==> 404
/my-idx?user=Cloud&idx=102 ==> 200
/my-idx?user=Cloud&idx=103 ==> 404
/my-idx?user=Cloud&idx=104 ==> 404

이런 식으로 user의 idx를 응답 코드를 통해 유추할 수 있다. 

이를 이용해서 CTFd 라는 플랫폼에서 1-day 취약점이 발생했었는데, 자세한 부분은 해당 링크를 참고하는 게 좋겠다.

https://blog.hspace.io/posts/XS-Leak101-2/

XS-Leak101#2

 

Mitigation

SameSite Cookie, COOP(Cross-Origin-Opener-Policy), COEP(Cross-Origin-Embedded-Policy), CSP(Content-Security-Policy), X-Frame-Options, Origin-Agent-Cluster, CORP(Cross-Origin-Resource-Policy) 등 브라우저 단에서 막을 수 있는 여러 방법들이 있다. 물론 서버 측의 설계를 바꿀 수도 있겠지만, 웬만하면 개발자들의 인권을 존중하자..!

 

Practice

https://github.com/CloudNaaam/xs_leak

GitHub - CloudNaaam/xs_leak: for study

사실 이게 이 글을 쓴 진짜 이유다. 사이드 프로젝트로 xs leak을 간단하게 구현해봤다. 

 

Reference

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-CORS-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC-%ED%95%B4%EA%B2%B0-%EB%B0%A9%EB%B2%95-%F0%9F%91%8F

https://velog.io/@jesop/SOP%EC%99%80-CORS

https://xsleaks.dev/

https://www.hahwul.com/cullinan/attack/xs-leaks

https://blog.hspace.io/posts/XS-Leak101-2/