Chrome 브라우저에서의 document.domain 변경
오늘은 최근 크롬 개발자 블로그에 보안 관련해서 업데이트 된 내용이 있어 알려드리려고 합니다.
원문 링크 : 크롬 개발자 블로그
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.postMessage API를 통해서 정보를 교환하면 됩니다!
메시지에 대한 처리는
// 응답 메시지 처리
window.addEventListener('message', (event) => {
// 보안을 강화하고 싶다면 origin 제한 하는 코드도 추가 할 수 있습니다.
if (event.origin !== 'https://post.naver.com') return;
// event 에는 data, origin, source 값이 있으니 용도에 맞게 사용
});
이런식으로 message에 대한 이벤트 핸들러를 통해 구현이 가능합니다.
만약 구현하시는 코드 중에
- document.domain을 사용하는 코드
- iframe에 접근하는 코드
- window.open 으로 열린 팝업에 접근하는 코드
- 팝업에서 opener 에 접근하는 코드
위에 해당되는 코드가 있다면
postMessageAPI를 활용해서 구현하시기를 추천드립니다!
4. 결론
사실 document.domain을 저런 방식으로 악용할 수 있을 거라고는 생각해보지 않았는데,
저런 시도들이 있음으로서 웹의 동작 방식에 대해 더 깊은 이해를 할 수 있었던 거 같습니다.
FE 개발자도 보안에 신경써야 한다는 것을 유념하면서,
오늘의 포스팅을 마치겠습니다!
Author And Source
이 문제에 관하여(Chrome 브라우저에서의 document.domain 변경), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@youngjewoo/Chrome-브라우저에서의-document.domain-제거저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)