웹 개발자를 위한 사이트 격리

Mathias Bynens

데스크톱의 Chrome 67에는 사이트 격리가 기본적으로 사용 설정된다는 새로운 기능이 있습니다. 이 도움말에서는 사이트 격리의 정의, 사이트 격리가 필요한 이유, 웹 개발자가 유의해 주시기 바랍니다.

사이트 격리란 무엇인가요?

인터넷은 무엇보다 고양이 비디오를 보고 암호화폐 지갑을 관리하기 위한 것입니다. 하지만 fluffycats.example이(가) 내 귀중한 암호화폐에 액세스하는 것을 원하지 않을 것입니다. 다행히 일반적으로 웹사이트는 Same-Origin 기능으로 인해 일반적으로 브라우저 내에서 서로의 데이터에 액세스할 수 없음 정책 그럼에도 불구하고 악성 웹사이트에서는 이 정책을 우회하여 다른 웹사이트를 공격하려고 시도할 수 있으며, 동일 출처 정책을 시행하는 브라우저 코드에서 보안 버그가 발견되는 경우가 있습니다. 이 Chrome팀은 이러한 버그를 최대한 빨리 수정하는 것을 목표로 합니다.

사이트 격리는 Chrome의 보안 기능으로 이러한 공격은 성공할 가능성이 더 낮아집니다. 다른 웹사이트의 페이지가 항상 각각 프로세스가 수행할 수 있는 작업을 제한하는 샌드박스에서 실행됩니다. 또한 이 프로세스는 다른 사이트로부터 특정 유형의 민감한 정보를 수신하지 못하도록 차단합니다. 그 결과, 사이트 격리를 사용하면 악성 웹사이트가 추측을 기반으로 스펙터 같은 부채널 공격을 통해 다른 사이트에서 데이터를 훔칩니다. Chrome팀이 사이트 격리는 공격자의 페이지가 일부 해답을 찾을 수 있습니다.

사이트 격리를 사용하면 신뢰할 수 없는 웹사이트가 정보에 액세스하거나 정보를 도용하기가 효과적으로 어려워집니다. 다른 웹사이트의 계정에서 볼 수 있습니다 다양한 유형의 사이버 위협으로부터 보안 버그는 최근 멜트다운 및 스펙터 부채널 공격을 확인해 보세요.

사이트 격리에 관한 자세한 내용은 Google 보안 블로그의 도움말을 참고하세요.

교차 출처 읽기 차단

모든 크로스 사이트 페이지가 별도의 프로세스로 전환되더라도 페이지가 합법적으로 이미지 및 자바스크립트와 같은 크로스 사이트 하위 리소스를 사용할 수 있습니다. 악성 웹페이지는 <img> 요소를 사용하여 은행 잔액과 같은 민감한 정보가 포함된 JSON 파일을 로드합니다.

<img src="https://your-bank.example/balance.json" />
<!-- Note: the attacker refused to add an `alt` attribute, for extra evil points. -->

사이트 격리를 사용하지 않으면 JSON 파일의 콘텐츠가 렌더기의 메모리로 전송됩니다. 올바른 이미지 형식이 아니라고 인지하여 렌더러가 이미지를 생성할 수 있습니다 하지만 공격자는 스펙터와 같은 취약점을 악용하여 메모리 덩어리에서 비롯됩니다

공격자는 <img>를 사용하는 대신 <script>를 사용하여 민감한 정보를 커밋할 수도 있습니다. 메모리:

<script src="https://your-bank.example/balance.json"></script>

교차 출처 읽기 차단(CORB)은 balance.json가 MIME 유형에 따라 렌더기 프로세스 메모리의 메모리에 들어가지 않도록 합니다.

CORB의 작동 방식을 분석해 보겠습니다. 웹사이트는 서버에 다음 두 가지 유형의 리소스를 요청할 수 있습니다.

  1. 데이터 리소스(예: HTML, XML, JSON 문서)
  2. 미디어 리소스(예: 이미지, JavaScript, CSS, 글꼴)

웹사이트는 자체 원본 또는 다른 출처에서 데이터 리소스를 수신할 수 허용 CORS 헤더(예: Access-Control-Allow-Origin: *입니다. 반면에 미디어 리소스는 원본에서 가져올 수 있습니다

CORB는 렌더러 프로세스가 교차 출처 데이터 리소스 (예: HTML, XML 또는 JSON)입니다.

  • 리소스에 X-Content-Type-Options: nosniff 헤더가 있음
  • CORS가 리소스에 대한 액세스를 명시적으로 허용하지 않음

교차 출처 데이터 리소스에 X-Content-Type-Options: nosniff 헤더가 설정되지 않은 경우 CORB는 응답 본문을 스니핑하여 HTML, XML 또는 JSON인지 확인합니다. 이것은 필요합니다. 예를 들어 일부 웹 서버가 잘못 구성되어 이미지를 text/html로 제공하기 때문입니다.

CORB 정책에 의해 차단된 데이터 리소스는 비어 있는 프로세스에 표시됩니다. 백그라운드에서 요청이 계속 발생합니다. 따라서 악성 웹페이지는 크로스 사이트 데이터를 프로세스로 가져와 절도하는 행위입니다.

최적의 보안과 CORB의 이점을 얻으려면 다음 권장사항을 따르는 것이 좋습니다.

  • 응답을 올바른 Content-Type 헤더로 표시합니다. 예를 들어, HTML 리소스는 text/html로 제공, JSON 리소스이며 JSON MIME 유형 및 XML MIME 유형).
  • X-Content-Type-Options: nosniff 헤더를 사용하여 스니핑을 선택 해제합니다. 이 헤더가 없으면 Chrome은 콘텐츠 유형이 올바른지 확인하기 위해 빠른 콘텐츠 분석을 수행하지만 JavaScript 파일, 자신 있게 옳은 일을 하는 것이 낫습니다

자세한 내용은 웹 개발자를 위한 CORB 도움말 또는 CORB 심층 설명을 확인해 보세요.

웹 개발자가 사이트 격리에 관심을 가져야 하는 이유는 무엇인가요?

대부분의 경우 사이트 격리는 웹 개발자에게 노출됩니다 예를 들어 학습할 새로운 웹 노출 API는 없습니다. 일반적으로 웹에서는 사이트 격리를 사용하거나 사용하지 않고 실행할 때 페이지가 차이를 알 수 없어야 합니다.

그러나 이 규칙에는 몇 가지 예외가 있습니다. 사이트 격리를 사용 설정하면 부작용을 찾아내는 것입니다. Google은 알려진 사이트 격리 문제의 목록 아래에서 가장 중요한 항목에 대해 자세히 설명합니다.

전체 페이지 레이아웃이 더 이상 동기식이 아님

사이트 격리를 사용하면 프레임이 페이지가 여러 프로세스에 분산될 수 있습니다. 이러한 상황은 사용자가 특정 사이트를 레이아웃 변경사항은 페이지의 모든 프레임에 즉시 전파됩니다.

예를 들어 fluffykittens.example라는 웹사이트가 있다고 가정해 보겠습니다. 이 웹사이트는 social-widget.example에 호스팅된 소셜 위젯:

<!-- https://fluffykittens.example/ -->
<iframe src="https://social-widget.example/" width="123"></iframe>
<script>
  const iframe = document.querySelector('iframe');
  iframe.width = 456;
  iframe.contentWindow.postMessage(
    // The message to send:
    'Meow!',
    // The target origin:
    'https://social-widget.example'
  );
</script>

처음에는 소셜 위젯의 <iframe> 너비가 123픽셀입니다. 하지만 FluffyKittens 페이지를 보면 너비를 456픽셀 (트리거 레이아웃)으로 변경하고 소셜 위젯에 메시지를 전송합니다. 여기에는 다음 코드가 포함됩니다.

<!-- https://social-widget.example/ -->
<script>
  self.onmessage = () => {
    console.log(document.documentElement.clientWidth);
  };
</script>

소셜 위젯은 postMessage API를 통해 메시지를 수신할 때마다 루트 <html> 요소입니다.

어떤 너비 값이 기록되나요? Chrome에서 사이트 격리를 사용 설정하기 전에는 답변은 456였습니다. 액세스 document.documentElement.clientWidth는 이전에 Chrome에서 동기식이었던 레이아웃을 강제 적용합니다. 사이트 격리를 사용 설정합니다. 그러나 사이트 격리를 사용 설정하면 교차 출처 소셜 위젯이 이제 레이아웃 재배치는 별도의 프로세스에서 비동기식으로 발생합니다. 따라서 이제 대답은 123, 즉 이전 width 값

페이지에서 교차 출처 <iframe>의 크기를 변경한 다음 페이지에 postMessage을 전송하는 경우 사이트 격리: 메시지를 수신할 때 수신 프레임에서 아직 새 크기를 모를 수 있습니다. 더보기 일반적으로 레이아웃 변경이 모든 페이지에 즉시 전파된다고 가정하면 페이지가 지정할 수 있습니다.

이 특정 예에서 더 강력한 솔루션은 상위 프레임에 width를 설정합니다. resize 이벤트를 수신 대기하여 <iframe>에서 변경사항을 감지합니다.

로드 취소 핸들러가 더 자주 타임아웃될 수 있음

프레임이 탐색되거나 닫히면 이전 문서 및 그 안에 삽입된 모든 서브프레임 문서가 영향을 받습니다. 모두 unload 핸들러를 실행합니다. 새 탐색이 동일한 렌더기 프로세스에서 발생하는 경우 (예: 동일한 출처 탐색), 이전 문서 및 하위 프레임의 unload 핸들러는 임의의 긴 시간이 지난 후에야 새 탐색이 커밋되도록 합니다.

addEventListener('unload', () => {
  doSomethingThatMightTakeALongTime();
});

이러한 상황에서는 모든 프레임의 unload 핸들러가 매우 안정적입니다.

그러나 사이트 격리가 없어도 일부 기본 프레임 탐색은 크로스 프로세스이므로 로드 취소 핸들러 동작 예를 들어 텍스트 입력을 통해 old.example에서 new.example(으)로 이동할 경우 주소 표시줄에 URL을 입력하면 new.example 탐색이 새로운 프로세스에서 발생합니다. 언로드 old.example 및 하위 프레임의 핸들러가 백그라운드의 old.example 프로세스에서 실행됩니다. new.example 페이지가 표시된 후 로드되지 않으면 이전 로드 취소 핸들러가 종료됩니다. 특정 제한 시간 내에 완료될 수 있습니다. 로드 취소 핸들러는 제한 시간 전에 완료되지 않을 수 있으므로 로드 취소 동작의 안정성이 떨어집니다.

사이트 격리를 사용하면 모든 크로스 사이트 탐색이 크로스 프로세스로 전환되므로 다른 사이트는 서로 프로세스를 공유하지 않습니다. 따라서 위의 상황이 더 많은 사례가 있으며 <iframe>의 로드 취소 핸들러에 백그라운드 및 시간 제한 동작이 있는 경우가 많습니다. 설명됩니다.

사이트 격리로 인해 발생하는 또 다른 차이점은 로드 취소 핸들러의 새로운 병렬 순서입니다. 사이트 격리를 사용하지 않으면 로드 취소 핸들러가 프레임 전체에서 엄격한 하향식 순서로 실행됩니다. 하지만 사이트 사용 시 격리, 로드 취소 핸들러는 여러 프로세스에서 동시에 실행됩니다.

이는 사이트 격리를 사용 설정하면 근본적인 결과입니다. Chrome팀은 일반적인 사용 사례를 위한 로드 취소 핸들러의 안정성 개선(가능한 경우) 또한 서브프레임 로드 취소 핸들러가 아직 특정 기능을 사용할 수 없고 문제를 해결하기 위해 노력하고 있습니다

로드 취소 핸들러의 중요한 사례는 세션 종료 핑을 전송하는 것입니다. 이 작업은 일반적으로 다음과 같습니다.

addEventListener('pagehide', () => {
  const image = new Image();
  img.src = '/end-of-session';
});
드림

이 변경사항을 고려할 때 더 강력한 접근 방식은 navigator.sendBeacon를 사용하는 것입니다. 다음 코드를 사용하세요.

addEventListener('pagehide', () => {
  navigator.sendBeacon('/end-of-session');
});

요청을 더 세부적으로 제어해야 하는 경우 Fetch API의 keepalive 옵션을 사용할 수 있습니다.

addEventListener('pagehide', () => {
  fetch('/end-of-session', {keepalive: true});
});

결론

사이트 격리를 사용하면 신뢰할 수 없는 웹사이트가 각 사이트를 자체 프로세스로 분리하여 다른 웹사이트의 계정을 만들 수 있습니다. 그 일환으로 CORB는 민감한 정보 리소스를 렌더기 프로세스에서 제외시킬 수 있습니다. 위의 권장사항을 따르면 최대한 활용해 보세요.

감사합니다. 알렉스 모쉬척, 찰리 레이스, 제이슨 밀러 나스코 오스코프 필립 월튼 슈비 패니커, 토마스 슈타이너 이 도움말의 초안 버전을 읽고 의견을 제공해 주셔서 감사합니다.