Chrome 브라우저에서의 document.domain 변경

우영제·2022년 2월 17일
1

오늘은 최근 크롬 개발자 블로그에 보안 관련해서 업데이트 된 내용이 있어 알려드리려고 합니다.

원문 링크 : 크롬 개발자 블로그

1. 요약

한 줄로 요약하자면,

보안상의 문제로 document.domain 에 값을 설정하는 것을 크롬브라우저에서 금지할 예정입니다.

라는 겁니다.


"간단하죠?"


iframe을 사용하지 않으셨던 분들이라면, 저게 도대체 뭔지 모르실 수도 있습니다.

하지만 무심코 사용하던 npm 라이브러리가 위 속성에 종속적인 경우

deprecated 된다면 갑자기 원인 모를 버그에 빠질 수도 있기 때문에,


이 포스팅을 읽고 document.domain을 검색해서

앞으로 닥칠 상황에 미리미리 대응할 수 있는 개발자가 되셨으면 합니다!

2. 왜 바꾸려고 하는가?

이 부분을 이해하려면 원래 document.domain이 어떤 방식으로 동작했는지를 알아야합니다.

2-1. 이전 사용 형태

하나의 페이지에 별도의 iframe으로 다른 페이지가 들어가 있는 경우 두 페이지 간의 통신을 가능하게 하기 위해 사용했습니다.

예를들어,

  • 메인 페이지 : post.naver.com
  • 서브 페이지 : video.naver.com

이런 형태로 페이지가 구성됐다고 했을 때,


원칙적으로는 호스트가 다르기 때문에 서로 정보 교환이 안 됩니다.


그러나!


이 document.domain을 사용하면 서로의 window나 document에 접근할 수 있었습니다.

그 방법은 바로

parent, child의 도메인을 자신의 상위 도메인으로 변경한다.

입니다.

  • 블로그 예제

  • 또 다른 예시
// post.naver.com
document.domain = 'naver.com'

// video.naver.com
document.domain = 'naver.com'

이런식으로 바꿔주면 post와 video 페이지 간의 SOP를 통과해서

정보를 주고 받을 수 있었다는 것이죠


그런데 여기서 중요한 부분은 자신의 상위 도메인으로의 변경만 가능하다는 점입니다.

아예 생뚱맞게

// post.naver.com
document.domain = 'kakao.com' // 불가

이런식으로 바꿀 수는 없습니다!


그래서 정리하자면 document.domain을 사용하면 내부에 또 다른 호스트의 페이지를 갖는 페이지 간의 정보 교환을 용이하게 해주는 역할을 해줬습니다.

2-2. 그럼 왜 바꾸려고 하는가?

2-2-1. 사용자 정보 탈취 가능성

예를들어 제가 post.youngje.com 이라는 페이지가 있다고 가정하겠습니다.

내부에 사용자 별로 user1.youngje.com, user1.youngje.com 이런식으로 sub-domain을 제공했다고 한다면,

document.domain은 youngje.com이 되겠죠.

그리고 해커가 domain을 youngje.com으로 바꾸고 뭔가 정보를 요청한다면

다른 사용자의 페이지인 것처럼 정보에 접근할 수 있습니다.

2-2-2. 다른 포트로의 접근 가능성

또 이 document.domain을 통해 SOP를 통과시키는 방법은

포트 번호를 따로 구분하지 않기 때문에

포트가 다른 동일한 IP주소 또는 호스트를 가진 페이지에서 접근이 가능해진다.

위 두 가지 이유로 인해 domain을 set하는 로직은 deprecated 예정이고, 다른 브라우저들도 마찬가지라고 합니다!

3. 그럼 앞으로는 어떻게 해야하지?

간단합니다. Window.postMessage API를 통해서 정보를 교환하면 됩니다!

메시지에 대한 처리는

// 응답 메시지 처리
window.addEventListener('message', (event) => {
  // 보안을 강화하고 싶다면 origin 제한 하는 코드도 추가 할 수 있습니다.
  if (event.origin !== 'https://post.naver.com') return;
  // event 에는 data, origin, source 값이 있으니 용도에 맞게 사용
});

이런식으로 message에 대한 이벤트 핸들러를 통해 구현이 가능합니다.

만약 구현하시는 코드 중에

  1. document.domain을 사용하는 코드
  2. iframe에 접근하는 코드
  3. window.open 으로 열린 팝업에 접근하는 코드
  4. 팝업에서 opener 에 접근하는 코드

위에 해당되는 코드가 있다면

postMessageAPI를 활용해서 구현하시기를 추천드립니다!

4. 결론

사실 document.domain을 저런 방식으로 악용할 수 있을 거라고는 생각해보지 않았는데,

저런 시도들이 있음으로서 웹의 동작 방식에 대해 더 깊은 이해를 할 수 있었던 거 같습니다.


FE 개발자도 보안에 신경써야 한다는 것을 유념하면서,

오늘의 포스팅을 마치겠습니다!

profile
Front-end Developer

0개의 댓글