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

Cache-Control 헤더를 잊어버리거나 오용하면 웹사이트의 보안과 사용자의 개인 정보에 부정적인 영향을 미칠 수 있습니다. 이것이 왜 중요한지 읽고 다음을 읽어보세요.

 

Spectre 취약점으로 인한 리소스 누출

• Spectre 취약점은 페이지가 OS 프로세스의 메모리를 읽을 수 있도록 합니다.
• 결과적으로 최신 웹 브라우저는 SharedArrayBuffer 또는 고해상도 타이머와 같은 일부 기능의 사용을 원본 간 격리가 있는 페이지로 제한했습니다.
• 최신 웹 브라우저는 COEP(Cross-Origin Embedder Policy)를 시행합니다.
• 이렇게 하면 교차 출처 리소스가 다음 중 하나인지 확인합니다.
• 쿠키 없이 요청된 공개 리소스
• CORS 또는 CORP 헤더를 통해 출처 간 공유가 명시적으로 허용된 리소스

HTTP 캐싱은 Spectre에 어떤 영향을 줍니까?

• Cache-Control 헤더가 제대로 설정되지 않은 경우 공격자는 Spectre 공격을 성공적으로 실행하면 공격을 실행할 수 있습니다.
• 웹 브라우저의 HTTP 캐시는 이러한 일이 발생하도록 허용하지 않지만 이 공격의 성공으로 이어질 수 있는 브라우저의 즉각적인 제어 외부에 추가 캐시가 존재합니다.

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

• 캐시에는 여러 계층이 있는 경우가 많습니다. 일부 캐시는 단일 사용자 전용이고 일부 캐시는 여러 사용자 전용입니다. 일부는 서버, 일부는 사용자, 일부는 중개자에 의해 제어됩니다.
• 브라우저 캐시
• 동일한 응답을 여러 번 가져오는 것을 방지하여 성능을 향상시킵니다.
• 로컬 프록시. 그들은 종종 "공개" 캐시를 구성하는 여러 사용자에 대한 단일 응답을 캐시합니다.

SSL은 중개자가 HTTPS 리소스를 캐싱하는 것을 방지합니다.

• 많은 사용자가 액세스 목적(예: 측정 연결 공유), 바이러스 검사 또는 데이터 손실 방지(DLP) 목적에 관계없이 로컬로 구성된 프록시를 정기적으로 사용합니다.

HTTP 캐시 작동 방식

• 리소스는 기본적으로 암시적으로 캐시할 수 있습니다. 기본 캐시 키는 URL과 메서드로 구성됩니다.
• 보조 캐시 키는 Vary 헤더에 포함된 헤더입니다.
• 쿠키는 응답이 쿠키에 의존함을 나타냅니다. Cache-Control 헤더는 더 세분화된 제어를 제공합니다.

웹사이트에 대해 다음 권장 조치를 취하세요.

• 중개자가 리소스를 캐싱하는 것을 방지합니다. Cache-Control: private로 설정합니다.
• 적절한 보조 캐시 키를 설정합니다. 쿠키로 인해 응답이 다른 경우(쿠키가 자격 증명을 저장할 때 발생할 수 있음) Vary: Cookie.

추가 고려 사항

• HTTP 캐시를 사용하는 유사한 다른 유형의 공격이 있지만 이들은 교차 출처 격리와 다른 메커니즘에 의존합니다.
• 이러한 공격이 다르고 최상위 오리진별로 분할하는 것과 상보적일지라도 문제는 로컬 프록시 캐시에 남아 있습니다.

 

출처- https://web.dev/http-cache-security/