HTTP 캐시를 업데이트하여 보안 및 개인 정보 보호 개선

Cache-Control 헤더를 잊어버리거나 오용하면 웹사이트 보안 및 사용자 개인 정보 보호에 부정적인 영향을 미칠 수 있습니다.

Arthur Sonzogni
Arthur Sonzogni

기본적으로 리소스는 항상 모든 유형의 캐시로 캐시될 수 있습니다. Cache-Control 헤더를 사용하지 않거나 오용하면 웹사이트의 보안과 사용자의 개인 정보 보호에 부정적인 영향을 미칠 수 있습니다.

비공개로 유지하려는 맞춤형 응답의 경우 다음 중 하나를 수행하는 것이 좋습니다.

  • 중개자가 리소스를 캐시하지 못하도록 합니다. Cache-Control: private를 설정합니다.
  • 적절한 보조 캐시 키를 설정합니다. 쿠키로 인해 응답이 달라지는 경우(쿠키가 사용자 인증 정보를 저장할 때 발생할 수 있음) Vary: Cookie를 설정합니다.

이 내용이 중요한 이유와 다음 사항을 알아보세요.

  1. 알지 못하는 보안 및 개인 정보 보호 문제
  2. 다양한 유형의 HTTP 캐시 및 일반적인 오해
  3. 가치가 높은 웹사이트에 대한 권장 조치

스펙터 취약점의 유출 리소스

스펙터 취약점을 사용하면 페이지에서 OS 프로세스의 메모리를 읽을 수 있습니다. 즉, 공격자가 교차 출처 데이터에 무단으로 액세스할 수 있습니다. 그 결과 최신 웹브라우저는 SharedArrayBuffer 또는 고해상도 타이머와 같은 일부 기능의 사용을 교차 출처 격리가 적용된 페이지로 제한했습니다.

최신 웹브라우저는 교차 출처 삽입자 정책(COEP)을 시행합니다. 이렇게 하면 교차 출처 리소스가 다음 중 하나가 됩니다.

  • 쿠키 없이 요청된 공개 리소스
  • CORS 또는 CORP 헤더를 통해 교차 출처 간 공유가 명시적으로 허용된 리소스

COEP 설정은 공격자가 Spectre를 악용하는 것을 방지하지 않습니다. 그러나 교차 출처 리소스가 공격자에게 가치가 없거나 (브라우저에서 공개 리소스로 로드된 경우) 공격자와 공유되지 않도록 합니다 (CORP: cross-origin와 공유된 경우).

HTTP 캐싱은 Spectre에 어떤 영향을 미치나요?

Cache-Control 헤더가 제대로 설정되지 않으면 공격자가 공격을 실행할 수 있습니다. 예를 들면 다음과 같습니다.

  1. 사용자 인증 정보가 있는 리소스가 캐시됩니다.
  2. 공격자가 교차 출처 분리 페이지를 로드합니다.
  3. 공격자가 리소스를 다시 요청합니다.
  4. COEP:credentialless는 브라우저에 의해 설정되므로 리소스는 쿠키 없이 가져옵니다. 하지만 캐시에서 사용자 인증 정보가 포함된 응답을 대신 반환할 수 있습니다.
  5. 그러면 공격자는 Spectre 공격을 사용하여 맞춤설정된 리소스를 읽을 수 있습니다.

웹브라우저의 HTTP 캐시에서는 실제로 이러한 유형의 공격이 발생하지 않지만 브라우저의 즉각적인 제어 외부에 추가 캐시가 있습니다. 이로 인해 공격에 성공할 수 있습니다.

HTTP 캐시와 관련된 일반적인 오해

1. 리소스는 브라우저에만 캐시됩니다.

캐시 레이어는 종종 여러 개 있습니다. 일부 캐시는 단일 사용자 전용이며 일부는 여러 사용자 전용입니다. 일부는 서버에서 제어하고 일부는 사용자가 제어하며 일부는 중개자가 제어합니다.

  • 브라우저 캐시 이러한 캐시는 웹브라우저에 구현된 단일 사용자 소유의 전용 캐시입니다. 동일한 응답을 여러 번 가져오는 것을 방지하여 성능을 개선합니다.
  • 로컬 프록시 이 앱은 사용자가 설치했을 수도 있지만 회사, 조직, 인터넷 서비스 제공업체와 같은 중개자가 관리할 수도 있습니다. 로컬 프록시는 종종 여러 사용자의 단일 응답을 캐시하여 '공개' 캐시를 구성합니다. 로컬 프록시에는 여러 역할이 있습니다.
  • 원본 서버 캐시 / CDN 이는 서버에서 제어합니다. 출처 서버 캐시의 목표는 여러 사용자의 동일한 응답을 캐시하여 출처 서버의 부하를 줄이는 것입니다. CDN의 목표는 비슷하지만 전 세계에 퍼져 있으며 지연 시간을 줄이기 위해 가장 가까운 사용자 집합에 할당됩니다.
브라우저와 서버 사이에는 캐시 레이어가 여러 개 있는 경우가 많습니다.
브라우저와 서버 사이에 다양한 캐시 레이어가 있을 수 있습니다. 예를 들어 서버 캐시 다음에 CDN 및 브라우저 캐시가 있을 수 있습니다. CDN과 브라우저 캐시 사이에 로컬 프록시가 설정되어 있을 수도 있습니다.

2. SSL은 중개자가 HTTPS 리소스를 캐시하지 못하도록 합니다.

많은 사용자가 액세스 목적 (예: 요금제 연결 공유), 바이러스 검사 또는 데이터 손실 방지 (DLP) 목적으로 로컬에서 구성된 프록시를 정기적으로 사용합니다. 중간 캐시에서 TLS 가로채기를 실행하고 있습니다.

중간 캐시는 종종 회사 직원의 워크스테이션에 설치됩니다. 웹브라우저는 로컬 프록시의 인증서를 신뢰하도록 구성됩니다.

궁극적으로 일부 HTTPS 리소스는 이러한 로컬 프록시에서 캐시될 수 있습니다.

HTTP 캐시의 작동 방식

  • 리소스는 기본적으로 암시적으로 캐시될 수 있습니다.
  • 기본 캐시 키는 URL과 메서드로 구성됩니다. (URL, 방법)
  • 보조 캐시 키는 Vary 헤더에 포함된 헤더입니다. Vary: Cookie는 응답이 Cookie에 종속됨을 나타냅니다.
  • Cache-Control 헤더를 사용하면 더 세부적으로 제어할 수 있습니다.

트래픽이 많은 웹사이트, 개인 식별 정보와 상호작용하는 웹사이트 등 가치가 높은 웹사이트의 개발자는 지금 바로 보안을 개선해야 합니다.

가장 큰 위험은 쿠키에 따라 리소스에 대한 액세스가 달라질 때 발생합니다. 예방 조치를 취하지 않은 경우 중간 캐시가 쿠키로 요청된 응답을 쿠키로 요청되지 않은 요청에 대해 반환할 수 있습니다.

다음 단계 중 하나를 따르는 것이 좋습니다.

  • 중개자가 리소스를 캐시하지 못하도록 합니다. Cache-Control: private를 설정합니다.
  • 적절한 보조 캐시 키를 설정합니다. 쿠키로 인해 응답이 달라지는 경우(쿠키가 사용자 인증 정보를 저장할 때 발생할 수 있음) Vary: Cookie를 설정합니다.

특히 기본 동작을 변경합니다. 항상 Cache-Control 또는 Vary를 정의합니다.

추가 고려사항

HTTP 캐시를 사용하는 다른 유형의 유사한 공격도 있지만 이러한 공격은 교차 출처 격리와는 다른 메커니즘을 사용합니다. 예를 들어 제이크 아치볼드가 CORS에서 이기기 위한 방법에서 몇 가지 공격을 설명합니다.

이러한 공격은 리소스 응답이 사용자 인증 정보로 요청되었는지 여부에 따라 HTTP 캐시를 분할하는 일부 웹브라우저에서 완화됩니다. 2022년 현재 Firefox는 캐시를 분할하지만 Chrome과 Safari는 분할하지 않습니다. 향후 Chrome에서 캐시를 분할할 수 있습니다. 이러한 공격은 최상위 출처별로 분할과는 다르며 이를 보완합니다.

웹브라우저에서 이 문제를 완화할 수 있더라도 로컬 프록시 캐시에는 문제가 남아 있습니다. 따라서 위의 권장사항을 따르는 것이 좋습니다.

헤더 사진: Unsplash의 벤 패틴슨.