HTTP 응답에 no-cache와 no-store를 모두 사용해야하는 이유는 무엇입니까?

사용자 정보 유출을 막으라는 말을 들었는데, 응답으로 "no-cache"만으로는 충분하지 않습니다. "no-store"도 필요합니다.

Cache-Control: no-cache, no-store

이 사양 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html을 읽은 후에도 왜 그런지 잘 모르겠습니다.

내 현재 이해는 중간 캐시 서버 전용이라는 것입니다. "no-cache"가 응답하더라도 중간 캐시 서버는 여전히 콘텐츠를 비 휘발성 저장소에 저장할 수 있습니다. 중간 캐시 서버는 다음 요청에 저장된 콘텐츠를 사용할지 여부를 결정합니다. 그러나 응답에 "no-store"가 있으면 중간 캐시 서버가 콘텐츠를 저장하지 않습니다. 따라서 더 안전합니다.

"no-cache"와 "no-store"가 모두 필요한 다른 이유가 있습니까?

캐시no-cache 하지 않는다는 의미 가 아님을 명확히해야합니다 . 실제로 모든 요청에 ​​대해 캐시 된 응답을 사용하기 전에 "서버에서 재 검증"을 의미합니다.

must-revalidate반면에 리소스가 오래된 것으로 간주 될 때만 재 검증하면됩니다.

서버가 리소스가 여전히 유효하다고 말하면 캐시가 해당 표현으로 응답 할 수 있으므로 서버가 전체 리소스를 다시 보낼 필요가 줄어 듭니다.

no-store사실상 전체 캐시 금지 지시문이며 어떤 형태의 캐시로도 표현이 저장되는 것을 방지하기위한 것입니다.

나는 무엇이든 말하지만 RFC 2616 HTTP 사양에서 이것을 주목하십시오.

히스토리 버퍼는 정상적인 작동의 일부로 이러한 응답을 저장할 수 있습니다.

그러나 이것은 잠재적으로 no-store더 강력 하게 만들기 위해 새로운 RFC 7234 HTTP 사양에서 생략되었습니다 .

http://tools.ietf.org/html/rfc7234#section-5.2.1.5

특정 상황에서 IE6는 Cache-Control: no-cache응답 헤더에있는 경우에도 파일을 캐시합니다 .

W3C는의 상태no-cache :

no-cache 지시문이 field-name을 지정하지 않으면, 캐시는 원 서버와의 성공적인 재 검증없이 후속 요청을 만족시키기 위해 응답을 사용해서는 안됩니다.

내 응용 프로그램에서 no-cache헤더 가있는 페이지를 방문한 다음 로그 아웃 한 다음 브라우저에서 다시 누르면 IE6는 여전히 캐시에서 페이지를 가져옵니다 (서버에 대한 새 / 유효성 확인 요청없이). no-store헤더에 추가하면 중단되었습니다. 그러나 W3C를 사용하면 실제로이 동작을 제어 할 방법이 없습니다.

히스토리 버퍼는 정상적인 작동의 일부로 이러한 응답을 저장할 수 있습니다.

브라우저 기록과 일반 HTTP 캐싱 간의 일반적인 차이점은 사양의 특정 하위 섹션에 설명 되어 있습니다.

로부터 HTTP 1.1 사양 :

노점 :

노 점포 의 목적지침은 민감한 정보 (예 : 백업 테이프)의 부주의 한 공개 또는 보존을 방지하는 것입니다. no-store 지시문은 전체 메시지에 적용되며 응답 또는 요청으로 전송 될 수 있습니다. 요청으로 전송되는 경우 캐시는이 요청 또는 이에 대한 응답의 일부를 저장해서는 안됩니다. 응답으로 전송되는 경우 캐시는이 응답 또는이를 유도 한 요청의 일부를 저장해서는 안됩니다. 이 지시문은 비공유 및 공유 캐시 모두에 적용됩니다. 이 문맥에서 "저장해서는 안된다"는 것은 캐시가 정보를 비 휘발성 저장소에 의도적으로 저장해서는 안되며, 정보를 전달한 후 가능한 한 빨리 휘발성 저장소에서 정보를 제거하기 위해 최선을 다해야 함을 의미합니다. 이 지시문이 응답과 연관되어 있어도 사용자는 이러한 응답을 캐싱 시스템 외부에 명시 적으로 저장할 수 있습니다 (예 : "다른 이름으로 저장"대화 상자 사용). 히스토리 버퍼는 정상적인 작동의 일부로 이러한 응답을 저장할 수 있습니다. 이 지침의 목적은 캐시 데이터 구조에 대한 예상치 못한 액세스를 통해 우발적 인 정보 공개에 대해 우려하는 특정 사용자 및 서비스 작성자의 명시된 요구 사항을 충족하는 것입니다. 이 지침을 사용하면 경우에 따라 개인 정보가 향상 될 수 있지만, 우리는 이것이 개인 정보 보호를위한 신뢰할 수 있거나 충분한 메커니즘이 아니라는 점에주의합니다. 특히 악의적이거나 손상된 캐시는이 지침을 인식하거나 준수하지 않을 수 있으며 통신 네트워크는 도청에 취약 할 수 있습니다. 히스토리 버퍼는 정상적인 작동의 일부로 이러한 응답을 저장할 수 있습니다. 이 지침의 목적은 캐시 데이터 구조에 대한 예상치 못한 액세스를 통해 우발적 인 정보 공개에 대해 우려하는 특정 사용자 및 서비스 작성자의 명시된 요구 사항을 충족하는 것입니다. 이 지침을 사용하면 경우에 따라 개인 정보가 향상 될 수 있지만, 우리는 이것이 개인 정보 보호를위한 신뢰할 수 있거나 충분한 메커니즘이 아니라는 점에주의합니다. 특히 악의적이거나 손상된 캐시는이 지침을 인식하거나 준수하지 않을 수 있으며 통신 네트워크는 도청에 취약 할 수 있습니다. 히스토리 버퍼는 정상적인 작동의 일부로 이러한 응답을 저장할 수 있습니다. 이 지침의 목적은 캐시 데이터 구조에 대한 예상치 못한 액세스를 통해 우발적 인 정보 공개에 대해 우려하는 특정 사용자 및 서비스 작성자의 명시된 요구 사항을 충족하는 것입니다. 이 지침을 사용하면 경우에 따라 개인 정보가 향상 될 수 있지만, 우리는 이것이 개인 정보 보호를위한 신뢰할 수 있거나 충분한 메커니즘이 아니라는 점에주의합니다. 특히 악의적이거나 손상된 캐시는이 지침을 인식하거나 준수하지 않을 수 있으며 통신 네트워크는 도청에 취약 할 수 있습니다. 이 지침을 사용하면 경우에 따라 개인 정보가 향상 될 수 있지만, 우리는 이것이 개인 정보 보호를위한 신뢰할 수 있거나 충분한 메커니즘이 아니라는 점에주의합니다. 특히 악의적이거나 손상된 캐시는이 지침을 인식하거나 준수하지 않을 수 있으며 통신 네트워크는 도청에 취약 할 수 있습니다. 이 지침을 사용하면 경우에 따라 개인 정보가 향상 될 수 있지만, 우리는 이것이 개인 정보 보호를위한 신뢰할 수 있거나 충분한 메커니즘이 아니라는 점에주의합니다. 특히 악의적이거나 손상된 캐시는이 지침을 인식하거나 준수하지 않을 수 있으며 통신 네트워크는 도청에 취약 할 수 있습니다.

모든 캐싱을 방지하려면 (예 : 뒤로 버튼을 사용할 때 강제로 다시로드) 다음이 필요합니다.

• IE 용 캐시 없음

• Firefox 용 매장 없음

여기에 대한 내 정보가 있습니다.

http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/

no-store정상적인 상황에서는 필요하지 않으며 속도와 사용 편의성을 모두 손상시킬 수 있습니다. HTTP 응답에 민감한 정보가 포함되어있어 사용자에게 부정적인 영향을 미치더라도 디스크 캐시에 전혀 기록되지 않아야하는 경우 사용하기위한 것입니다.

작동 원리 :

• 일반적으로 브라우저와 같은 사용자 에이전트가 응답을 캐시하지 않아야한다고 결정하더라도 사용자 에이전트 내부의 이유로 디스크 캐시에 저장할 수 있습니다. 이 버전은 "소스보기", "뒤로", "페이지 정보"등과 같은 기능에 활용 될 수 있습니다. 사용자가 반드시 페이지를 다시 요청하지는 않았지만 브라우저는이를 새 페이지보기로 간주하지 않습니다. 사용자가 현재보고있는 것과 동일한 버전을 제공하는 것이 좋습니다.

• 을 사용 no-store하면 해당 응답이 저장되지 않지만 이는 브라우저가 서버에 대해 별도의 새 요청을하지 않고 "소스보기", "뒤로", "페이지 정보"등을 제공하는 기능에 영향을 미칠 수 있으며 이는 바람직하지 않습니다. 즉, 사용자가 소스를 보려고 시도 할 수 있으며 브라우저가이를 메모리에 저장하지 않은 경우 이것이 가능하지 않다는 메시지가 표시되거나 서버에 새로운 요청이 발생합니다. 따라서 no-store이러한 기능이 제대로 작동하지 않거나 빠르게 작동하지 않는 사용자 경험을 방해하는 것이 콘텐츠가 캐시에 저장되지 않도록하는 것의 중요성보다 더 중요한 경우에만 사용해야합니다.

내 현재 이해는 중간 캐시 서버 전용이라는 것입니다. "no-cache"가 응답하더라도 중간 캐시 서버는 여전히 콘텐츠를 비 휘발성 저장소에 저장할 수 있습니다.

이것은 올바르지 않습니다. HTTP 1.1과 호환되는 중간 캐시 서버는 no-cache및 must-revalidate지침 을 준수하여 콘텐츠가 캐시되지 않도록합니다. 이 명령을 사용하면 응답이 중간 캐시에 의해 캐시되지 않고 모든 후속 요청이 원본 서버로 다시 전송되는지 확인할 수 있습니다.

중간 캐시 서버가 HTTP 1.1을 지원하지 않으면 Pragma: no-cache최선을 다해 사용 하고 희망 해야합니다 . HTTP 1.1을 지원하지 않으면 no-store어쨌든 관련이 없습니다.

캐싱 시스템이 no-store를 올바르게 구현하면 no-cache가 필요하지 않습니다. 그러나 모두가 그렇지는 않습니다. 또한 일부 브라우저는 저장소가없는 것처럼 캐시를 구현하지 않습니다. 따라서 반드시 필요한 것은 아니지만 둘 다 포함하는 것이 가장 안전 할 것입니다.

버전 5에서 8까지의 Internet Explorer는 https 및 서버 전송 Cache-Control: no-cache또는 Pragma: no-cache헤더 를 통해 제공되는 파일을 다운로드하려고 할 때 오류를 발생시킵니다 .

참조 http://support.microsoft.com/kb/812935/en-us를

의 사용 Cache-Control: no-store과는 Pragma: private여전히 작동 가장 가까운 일이 될 것으로 보인다.

크롬의 경우 재 방문시 페이지를 다시로드하는 데 캐시 없음이 사용되지만 기록으로 돌아 가면 여전히 캐시합니다 (뒤로 버튼). 히스토리 백을 위해 페이지를 다시로드하려면 no-store를 사용하십시오. IE는 모든 경우에 작동하려면 반드시 재확인이 필요합니다.

그래서 제가 항상 사용하는 모든 버그와 오해를 피하기 위해

Cache-Control: no-store, no-cache, must-revalidate

다시로드되는지 확인하려면

원래 우리는 수년 전에 no-cache를 사용했고 특정 브라우저에서 오래된 콘텐츠에 문제가 발생했습니다 ... 안타깝게도 구체적인 내용을 기억하지 마세요.

우리는 그 이후로 노 점포를 사용하기로 결정했습니다. 그 이후로 브라우저 나 중개자가 오래된 콘텐츠에 대해 뒤돌아 보거나 한 가지 문제를 겪은 적이 없습니다.

이 공간은 구현의 현실과 다양한 RFC로 작성된 것에 의해 확실히 지배됩니다. 특히 많은 프록시는 준수해야하는 정책을 자신의 정책으로 대체하여 "성능 향상"을 더 잘 수행한다고 생각하는 경향이 있습니다.

상황을 더 악화시키기 위해 어떤 상황에서는 no-cache를 사용할 수 없지만 no-store는 다음과 같이 할 수 있습니다.

http://faindu.wordpress.com/2008/04/18/ie7-ssl-xml-flex-error-2032-stream-error/

OWASP는 이에 대해 설명합니다.

캐시 제어 지시문 (no-cache와 no-store)의 차이점은 무엇입니까?

응답의 no-cache 지시문은 응답이 후속 요청을 처리하는 데 사용되지 않아야 함을 나타냅니다. 즉, 캐시가 헤더에이 지시문이 설정된 응답을 표시해서는 안되지만 서버가 요청을 처리하도록해야합니다. no-cache 지시문은 일부 필드 이름을 포함 할 수 있습니다. 이 경우 서버에서 제공되어야하는 지정된 필드 이름을 제외하고 응답이 캐시에서 표시 될 수 있습니다. no-store 지시문은 전체 메시지에 적용되며 캐시가 응답의 일부 나이를 요청한 요청을 저장하지 않아야 함을 나타냅니다.

이 지침으로 완전히 안전합니까?

아니요. 그러나 일반적으로 Expires : 0 (또는 UNIX epoch와 같이 충분히 오래된 GMT 날짜) 외에 Cache-Control : no-cache, no-store 및 Pragma : no-cache를 모두 사용합니다. pdf, word 문서, Excel 스프레드 시트 등과 같은 비 HTML 콘텐츠 유형은 위의 캐시 제어 지시문이 설정되어 있어도 캐시되는 경우가 많습니다 (단, 버전 및 must-revalidate, pre-check = 0, post-check의 추가 사용에 따라 달라짐) 실제로 = 0, max-age = 0 및 s-maxage = 0은 브라우저의 단점 및 HTTP 구현으로 인해 일부 경우에 브라우저를 닫을 때 파일이 삭제되는 경우가 있습니다. 또한 '자동 완성'기능을 사용하면 사용자가 양식의 입력 필드에 입력하는 모든 내용을 브라우저에서 캐시 할 수 있습니다. 이를 확인하려면 양식 태그 또는 개별 입력 태그에 'Autocomplete = "Off"'속성이 포함되어야합니다. 하나,

여기에 소스 .