HTTP Cache 업데이트로 더 강력한 보안 및 개인 정보 보호하기
원문: Improve security and privacy by updating HTTP Cache, (CC BY 4.0) 저자: Arthur Sonzogni / Twitter - GitHub - Homepage
기본적으로, 리소스는 어떤 타입의 캐시에라도 저장될 수 있게 허용되어 있다. Cache-Control을 사용하지 않거나 잘못 사용하면 보안이나 사용자의 개인 정보에 부정적인 영향을 끼칠 수 있다.
개인화된 응답을 숨기고 싶다면 다음을 확인하자.
- 리소스를 캐싱 할 때 중계자를 두지 말아야 한다.
Cache-Control: private로 설정해야 한다. - 적절한 2차 캐시 키 를 설정해야 한다. 만약 응답이 쿠키에 저장된 인증 정보에 의해 다양하게
내려온다면,
Vary: Cookie로 설정하면 된다.
글을 읽는다면 아래와 같이 이런 설정이 중요한 이유를 알게될 것이다.
- 우리가 놓치고 있는 보안과 개인 정보의 문제
- 다양한 타입의 HTTP 캐시와 보편적인 오해
- 보안이 중요한 웹 사이트에 권장되는 조치
캐시와 관련된 보안 및 개인 정보 위협
스펙터(Spectre) 취약점으로 유출될 수 있는 리소스
스펙터 취약점 을 통해 OS 프로세스의 메모리를 읽을 수 있다. 이는 공격자가 허가되지 않은 Cross-Origin 데이터에 접근할 수 있다는 것을 의미한다. 따라서, 모던 웹 브라우저는 Cross-Origin끼리 페이지 분리 하기 위해 특정 기능의 사용을 제한시켰다(SharedArrayBuffer 나 고해상도 타이머 등).
모던 웹 브라우저는 Cross-Origin Embedder Policy (COEP) 를 강제한다. 이 기능은 Cross-Origin 리소스에도 동일하다.
- 쿠키 없이 요청된 퍼블릭 리소스
- CORS나 CORP 헤더를 통해 명시적으로 공유되도록 허가된 리소스
COEP 설정을 하더라도 스펙터 취약점 공격을 막을 수 없다. 그러나, COEP 설정은 Cross-Origin 리소스를 공격자에게 그다지 가치가 없게 만들거나(브라우저의 퍼블릭 리소스가 로드된 경우), 공격자에게도
공유되도록 허용(CORP: cross-origin 를 통해
공유된 경우) 되어있게 해준다.
HTTP 캐싱이 스펙터 공격에 어떤 영향을 주는가?
Cache-Control 헤더가 적절하게 설정되지 않았다면, 공격자가 다음과 같은 공격을 수행할 수 있다.
- 인증된 리소스가 캐싱 되어있다.
- 공격자가 Cross-Origin으로 분리된 페이지를 불러올 수 있다.
- 공격자가 인증된 리소스를 다시 요청한다.
- 브라우저에
COEP:credentialless가 설정 되어있다면 쿠키 없이 해당 리소스를 불러올 수 있다. 반면에, 인증된 리소스 대신에 캐시가 반환된다. - 이런 스펙터 공격을 통해 공격자가 개인화된 리소스를 확인할 수 있다.
웹 브라우저의 HTTP 캐시는 위 예제와 같은 공격이 일어나게 두지 않 지만, 브라우저의 즉각 제어권 외부에 있는 부가적인 캐시가 존재한다면 해당 공격이 성공할 것이다.
HTTP 캐시에 대한 보편적인 오해
1. 리소스는 브라우저에만 캐시 된다
캐시에는 여러 계층이 있다. 어떤 캐시는 단일 사용자를 위해서 사용되기도 하고, 일부 캐시는 여러 사용자를 위해 사용된다. 사용자에 의해 제어되거나, 서버에 의해 제어되기도 하고 중계자에 의해 제어되기도 한다.
- 브라우저 캐시: 이 캐시는 단일 사용자 소유이고, 웹 브라우저 내부에 구현되어 있다. 동일한 리소스를 여러 번 요청하지 않게 해서 성능을 향상시켜준다.
- 로컬 프록시: 이 캐시는 사용자에 의해 설치되었지만, 중계자에 의해 관리될 수 있다(사용자의 회사, 조직, 인터넷 제공자 등). 로컬 프록시는 여러 사용자를 위해 단일 응답을 캐싱 한다. 이는 "퍼블릭" 캐시 다. 로컬 프록시는 이 외에도 다양한 역할이 있다.
- 서버 캐시 / CDN: 이 캐시는 서버에 의해 제어된다. 서버 캐시의 목표는 서버의 동일한 응답을 캐싱 해서 여러 사용자에게 제공함으로써 서버의 부하를 낮추는 것이다. CDN의 목표도 서버 캐시와 비슷하지만, 세계 각국에 걸쳐 서버를 확장시켜서 사용자에게 인접하게 함으로써 지연 시간을 낮추기 위함이다.
서버와 브라우저 사이에 다양한 계층의 캐시가 있다. 서버 캐시를 만난다면, 그다음엔 CDN과 브라우저 캐시도 만날 것이다. 만약, 로컬 프록시도 구성했다면 CDN과 브라우저 캐시 사이에 오게 될 것이다.
2. SSL을 사용해서 중계자의 HTTPS 리소스 캐싱 방지
다양한 사용자는 보통 로컬에서 정의한 프록시를 사용한다. 예를 들어, 종량제 인터넷 연결을 공유하거나, 바이러스 검사, 데이터 유실 방지 등의 목적으로 사용한다. 중계자 캐싱은 TLS 도청 으로 수행된다.
중계자 캐시는 회사 임직원의 업무용 장비에 설치해둔다. 웹 브라우저는 로컬 프록시의 인증서를 신뢰하도록 설정되어 있다.
궁극적으로, 일부 HTTPS 리소스는 로컬 프록시에 의해 캐시 될 수 있다.
HTTP 캐시의 동작 원리
- 리소스는 기본적으로 암묵적인 캐싱이 허용되어 있다.
- 1차 캐시 키 는 URL과 메서드로 구성되어 있다.
- 2차 캐시 키 는 헤더에 포함되어 있는
Vary헤더의 내용이다.Vary:Cookie는 응답이 쿠키에 따라 다르다는 것을 의미한다. Cache-Control헤더는 더욱 미세한 제어를 할 수 있게 해준다.
웹 사이트를 위한 몇 가지 조언들
트래픽이 많거나 개인 정보로 상호작용하는 보안이 중요한 웹 사이트의 개발자는 다음 내용을 지켜서 보안을 강화해야 한다.
가장 위험한 경우는 쿠키에 의존하는 리소스에 접근할 때 다. 중계자 캐시는 예방 조치를 취하지 않은 요청에 대해 쿠키와 함께 요청되었던 응답을 반환할 수도 있다.
따라서, 아래 단계 중 하나의 방법을 처리하기를 권고한다.
- 중계자가 리소스를 캐싱 하지 못하도록
Cache-Control: private로 설정하자. - 적절한 2차 캐시 키 를 설정하자. 쿠키에 저장된 인증 정보 등의 이유로 각 쿠키마다 다양한 응답이
내려온다면,
Vary: Cookie로 설정하자.
특히 기본 동작을 수정해야 한다. Cache-Control과 Vary를 설정하자.
부가적인 고려 사항
보통 HTTP 캐시를 사용하는 비슷한 타입의 공격이 있지만, Cross-Origin 분리와는 다른 메커니즘을 사용한다. 예를 들어 Jake Archibald의 CORS에서 이기는 법 글에서 몇 가지 공격 방식을 설명했다.
인증 정보와 함께 요청이 되었는지에 따라 요청의 응답 리소스를 분류해서 HTTP 캐시에 저장하는 일부 웹브라우저에 의해 이런 공격은 일부 방어가 되었다. 2022년 현재의 Firefox는 캐시를 분류하지만 Chrome과 Safari는 그렇지 않다. Chrome은 가까운 시일 내에 캐시를 분류할 예정이라 예상 한다. 이 공격 방식은 최상위 Origin 별로 분류하는 것과 다르고, 상호 보완적 임을 이해하자.
이런 문제가 브라우저로 인해 일부 해소되었다고 하더라도, 로컬 프록시 캐시에서도 동일한 문제가 아직 남아있다. 그러므로 앞서 조언한 권고 사항을 준수하기를 바란다.
배너 사진은 Ben Pattinson 의 사진이며, 출처는 Unsplash 이다.
이 포스트는 원문: 'Improve security and privacy by updating HTTP Cache' 를 한국어로 번역한 포스트다. 별도 고지가 없는 경우 이 페이지의 컨텐츠는 저작자표시 4.0 국제 (CC BY 4.0) 라이선스를 따른다.