Cache-Control 헤더를 잊거나 오용하면 웹사이트의 보안과 사용자의 개인 정보 보호에 부정적인 영향을 줄 수 있습니다.
기본적으로 리소스는 항상 모든 유형의 캐시로 캐시될 수 있습니다.
Cache-Control 헤더를 사용하지 않거나 오용하면 웹사이트 보안 및 사용자 개인 정보 보호에 부정적인 영향을 미칠 수 있습니다.
비공개로 유지하고 싶은 맞춤형 대답을 받으려면 다음 중 하나를 수행하는 것이 좋습니다.
- 중개자가 리소스를 캐시하지 못하게 합니다.
Cache-Control: private를 설정합니다. - 적절한 보조 캐시 키를 설정합니다.
쿠키로 인해 응답이 다른 경우(쿠키가 사용자 인증 정보를 저장할 때 발생할 수 있음)
Vary: Cookie를 설정합니다.
Google 애널리틱스가 중요한 이유를 알아보고 다음 정보를 확인해 보세요.
- 알지 못하는 보안 및 개인 정보 보호 문제
- 다양한 유형의 HTTP 캐시와 일반적인 오해
- 가치가 높은 웹사이트를 위한 권장 조치
캐시 관련 보안 및 개인 정보 보호 위험
스펙터 취약점으로 인한 유출 리소스
스펙터 취약점으로 인해 페이지에서 OS 프로세스의 메모리를 읽을 수 있습니다. 즉, 공격자가 교차 출처 데이터에 무단으로 액세스할 수 있습니다. 따라서 최신 웹브라우저에서는 SharedArrayBuffer 또는 고해상도 타이머와 같은 일부 기능의 사용을 교차 출처 격리가 적용된 페이지로 제한했습니다.
최신 웹브라우저에서는 교차 출처 삽입 정책(COEP)을 적용합니다. 이렇게 하면 교차 출처 리소스가 다음 중 하나에 해당합니다.
- 공개 리소스, 쿠키 없이 요청됨
- CORS 또는 CORP 헤더를 통해 교차 출처 공유가 명시적으로 허용된 리소스
COEP 설정은 공격자가 스펙터를 악용하는 것을 방지하지 않습니다. 그러나 교차 출처 리소스가 공격자에게 가치가 없거나 (브라우저에서 공개 리소스로 로드될 때) 공격자와 공유 (CORP: cross-origin와 공유된 경우) 허용되지 않습니다.
HTTP 캐싱은 스펙터에 어떤 영향을 미치나요?
Cache-Control 헤더가 제대로 설정되지 않으면 공격자가 공격을 실행할 수 있습니다. 예를 들면 다음과 같습니다.
- 인증된 리소스가 캐시됩니다.
- 공격자가 교차 출처 분리 페이지를 로드합니다.
- 공격자가 리소스를 다시 요청합니다.
COEP:credentialless가 브라우저에 의해 설정되므로 쿠키 없이 리소스를 가져옵니다. 하지만 캐시는 대신 인증된 응답을 반환할 수 있습니다.- 그런 다음 공격자는 스펙터 공격을 사용하여 맞춤설정된 리소스를 읽을 수 있습니다.
웹브라우저의 HTTP 캐시는 실제로 이러한 유형의 공격을 허용하지 않지만 브라우저의 즉각적인 제어 범위를 벗어난 추가 캐시가 존재합니다. 따라서 공격이 성공할 수도 있습니다.
HTTP 캐시에 관한 일반적인 오해
1. 리소스가 브라우저에 의해서만 캐시됨
캐시 레이어가 있는 경우가 많습니다. 일부 캐시는 단일 사용자 전용이고, 일부는 여러 사용자에게 사용됩니다. 일부는 서버에서, 일부는 사용자, 일부는 중개자에 의해 제어됩니다.
- 브라우저 캐시. 이러한 캐시는 단일 사용자가 소유하며 전용이며 웹브라우저에 구현됩니다. 같은 응답을 여러 번 가져오는 것을 방지하여 성능을 개선합니다.
- 로컬 프록시. 이는 사용자가 설치했을 수 있지만 회사, 조직, 인터넷 제공업체 등 중개자에 의해 관리될 수도 있습니다. 로컬 프록시는 종종 여러 사용자에 대해 단일 응답을 캐시하며, 이를 '공개' 캐시라고 합니다. 로컬 프록시에는 여러 역할이 있습니다.
- 원본 서버 캐시 / 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 캐시를 사용하는 다른 유사한 유형의 공격도 있지만 이러한 공격에는 교차 출처 격리와 다른 메커니즘이 사용됩니다. 예를 들어 Jake 아치볼드는 CORS에서 승리하는 방법에 일부 공격에 대해 설명합니다.
이러한 공격은 리소스 응답이 사용자 인증 정보로 요청되었는지에 따라 HTTP 캐시를 분할하는 일부 웹브라우저를 통해 완화됩니다. 2022년 현재 Firefox는 캐시를 분할하는 반면 Chrome 및 Safari는 캐시하지 않습니다. 향후 Chrome에서 캐시를 분할할 수 있습니다. 이러한 공격은 최상위 출처별로 분할하는 것을 보완하며 서로 다릅니다.
웹브라우저에서 이 문제를 완화할 수 있더라도 문제는 로컬 프록시 캐시에 남아 있습니다. 따라서 위의 권장사항을 따르는 것이 좋습니다.
헤더 사진: Ben Pattinson(Unsplash 제공)