SharedArrayBuffer의 웹 탐색이 다소 미흡했지만, 지금은 문제가 해결되지 않습니다. 다음 사항에 유의하시기 바랍니다.
요약
SharedArrayBuffer는 현재 Firefox 79 이상에서 지원되며 Android Chrome 88에서 지원될 예정입니다. 하지만 교차 출처 분리된 페이지에만 사용할 수 있습니다.SharedArrayBuffer는 현재 데스크톱 Chrome에서 사용할 수 있지만 Chrome 92부터는 교차 출처 분리 페이지로 제한됩니다. 제때 변경할 수 없다고 생각되면 오리진 트라이얼을 등록하여 Chrome 113 이상까지 현재 동작을 유지할 수 있습니다.SharedArrayBuffer를 계속 사용하기 위해 교차 출처 분리를 사용 설정하려면 웹사이트의 다른 교차 출처 요소(예: 광고 게재위치)에 미칠 영향을 평가하세요. 서드 파티 리소스에서SharedArrayBuffer를 사용하여 영향과 안내를 이해하는지 확인하세요.
교차 출처 격리 개요
다음 헤더가 있는 페이지를 제공하여 페이지를 교차 출처 분리할 수 있습니다.
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
이렇게 하면 리소스가 Cross-Origin-Resource-Policy 헤더 또는 CORS 헤더(Access-Control-Allow-* 등)를 통해 명시적으로 허용하지 않는 한 페이지에서 교차 출처 콘텐츠를 로드할 수 없습니다.
보고 API도 있으므로 Cross-Origin-Embedder-Policy 및 Cross-Origin-Opener-Policy의 결과로 실패한 요청에 대한 데이터를 수집할 수 있습니다.
Chrome 92에 맞춰 이러한 변경사항을 적용할 수 없다고 생각되면 오리진 트라이얼에 등록하여 최소 Chrome 113까지 현재 데스크톱 Chrome 동작을 유지할 수 있습니다.
교차 출처 격리에 관한 자세한 내용과 정보는 이 페이지 하단의 추가 자료 섹션을 참고하세요.
지금까지 우리가 어떻게 발전해 왔는지 살펴보겠습니다.
Chrome 60에서 SharedArrayBuffer가 출시되었습니다 (Chrome 버전이 아닌 날짜로 시간을 생각하는 분들을 위해 2017년 7월). 모든 것이 훌륭했습니다.
6개월 동안 사용할 수 있습니다.
2018년 1월에 일부 유명 CPU에서 취약점이 발견되었습니다. 자세한 내용은 공지사항을 참고하세요. 하지만 이는 코드가 고해상도 타이머를 사용하여 액세스하면 안 되는 메모리를 읽을 수 있다는 의미입니다.
이는 사이트가 JavaScript 및 WASM 형식의 코드를 실행하도록 허용하되 이 코드로 액세스할 수 있는 메모리는 엄격하게 제어해야 하므로 브라우저 공급업체의 문제였습니다. 제 웹사이트를 방문해도 열려 있는 인터넷 뱅킹 사이트의 내용을 제가 읽을 수 없어야 합니다 사실 인터넷 뱅킹 사이트를 운영하고 계신지조차 모르고 있어요 이것들은 웹 보안의 기본입니다.
이 문제를 완화하기 위해 performance.now()와 같은 고해상도 타이머의 해상도를 줄였습니다. 그러나 worker의 타이트 루프에서 메모리를 수정하고 다른 스레드에서 다시 읽어 SharedArrayBuffer를 사용하여 고해상도 타이머를 만들 수 있습니다. 이는 의도가 분명한 코드에 큰 영향을 미치지 않고서는 효과적으로 완화할 수 없으므로 SharedArrayBuffer가 완전히 사용 중지되었습니다.
일반적인 완화 방법은 웹페이지의 시스템 프로세스에 다른 위치의 민감한 정보가 포함되지 않도록 하는 것입니다. Chrome은 처음부터 다중 프로세스 아키텍처에 투자했지만 (만화 참조), 여러 사이트의 데이터가 동일한 프로세스에 보관되는 경우도 있었습니다.
<iframe src="https://your-bank.example/balance.json"></iframe>
<script src="https://your-bank.example/balance.json"></script>
<link rel="stylesheet" href="https://your-bank.example/balance.json" />
<img src="https://your-bank.example/balance.json" />
<video src="https://your-bank.example/balance.json"></video>
<!-- …and more… -->
이러한 API에는 다른 출처의 콘텐츠를 선택하지 않고도 다른 출처의 콘텐츠를 사용할 수 있는 '레거시' 동작이 있습니다. 이러한 요청은 다른 출처의 쿠키로 이루어지므로 완전한 '로그인' 요청입니다. 요즘은 새 API를 사용하려면 다른 출처에서 CORS를 사용하여 선택해야 합니다.
Google에서는 콘텐츠가 '잘못된' 것으로 보이면 웹페이지 프로세스에 진입하지 못하도록 하여 이러한 기존 API를 해결하고, 이를 교차 출처 읽기 차단이라고 했습니다. 따라서 위의 경우에는 이러한 API에 유효한 형식이 아니므로 JSON이 프로세스에 입력되도록 허용되지 않습니다. 즉, iframe은 예외입니다. iframe의 경우 콘텐츠를 다른 프로세스에 배치합니다.
이러한 완화 조치를 통해 Chrome 68 (2018년 7월)에 SharedArrayBuffer를 다시 도입했지만 데스크톱에서만 도입했습니다. 추가 프로세스 요구사항으로 인해 휴대기기에서는 이러한 작업을 할 수 없었습니다. 또한 Google은 '잘못된' 데이터 형식만 차단하는 반면, 추측 가능한 URL의 유효한 CSS/JS/이미지에는 비공개 데이터가 포함될 수 있는 반면 Chrome의 솔루션은 완전하지 않다는 점도 지적했습니다.
웹 표준 담당자들이 함께 보다 완전한 교차 브라우저 솔루션을 개발했습니다. 해결책은 페이지에 '이에 따라 동의 없이 이 프로세스에 다른 출처 콘텐츠를 가져오는 기능을 포기한다'는 방법을 제공하는 것이었습니다.
이 선언은 페이지와 함께 제공되는 COOP 및 COEP 헤더를 통해 수행됩니다. 브라우저가 이를 적용하고 그 대신 페이지는 SharedArrayBuffer 및 비슷한 권한을 가진 기타 API에 대한 액세스 권한을 얻습니다. 다른 출처는 Cross-Origin-Resource-Policy 또는 CORS를 통해 콘텐츠 삽입을 선택할 수 있습니다.
Firefox는 버전 79 (2020년 7월)에서 이러한 제한사항과 함께 SharedArrayBuffer를 최초로 출시했습니다.
2021년 1월에 제가 이 글을 쓰고 여러분이 읽으셨습니다. 안녕하세요.
그것이 바로 지금 우리가 있는 곳입니다. Chrome 88에서는 교차 출처 격리된 페이지의 SharedArrayBuffer를 Android로 다시 가져오고 Chrome 92에서는 일관성과 완전한 교차 출처 격리를 위해 데스크톱에 동일한 요구사항을 적용합니다.
데스크톱 Chrome 변경 연기
이는 '원본 트라이얼' 형태로 일시적인 예외로, 사용자에게 교차 출처 분리 페이지를 구현할 수 있는 시간을 더 많이 제공합니다. 페이지를 교차 출처 분리할 필요 없이 SharedArrayBuffer를 사용 설정합니다. 이 예외는 Chrome 113에서 만료되며 데스크톱 Chrome에만 적용됩니다.
- 출처에 대한 토큰을 요청합니다.
- 페이지에 토큰을 추가합니다. 다음과 같은 두 가지 방법이 있습니다.
- 각 페이지의 헤드에
origin-trial<meta>태그를 추가합니다. 예를 들어 다음과 같이 표시될 수 있습니다.
<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE"> - 서버를 구성할 수 있는 경우
Origin-TrialHTTP 헤더를 사용하여 토큰을 추가할 수도 있습니다. 결과 응답 헤더는 다음과 같이 표시됩니다.
Origin-Trial: TOKEN_GOES_HERE
- 각 페이지의 헤드에