Tại sao cả no-cache và no-store nên được sử dụng trong phản hồi HTTP?

Tôi được yêu cầu để ngăn rò rỉ thông tin người dùng, chỉ phản hồi "no-cache" là không đủ. "no-store" cũng là cần thiết.

Cache-Control: no-cache, no-store

Sau khi đọc thông số này http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html , tôi vẫn không chắc tại sao.

Sự hiểu biết hiện tại của tôi là nó chỉ dành cho máy chủ bộ đệm trung gian. Ngay cả khi phản hồi "no-cache", máy chủ cache trung gian vẫn có thể lưu nội dung vào bộ nhớ không bay hơi. Máy chủ bộ đệm trung gian sẽ quyết định xem có sử dụng nội dung đã lưu cho yêu cầu sau hay không. Tuy nhiên, nếu phản hồi là "no-store", thì máy chủ cache trung gian không được phép lưu trữ nội dung. Vì vậy, nó là an toàn hơn.

Có lý do nào khác mà chúng ta cần cả "no-cache" và "no-store" không?

Tôi phải làm rõ điều no-cacheđó không có nghĩa là không lưu vào bộ nhớ cache . Trên thực tế, nó có nghĩa là "xác thực lại với máy chủ" trước khi sử dụng bất kỳ phản hồi nào được lưu trong bộ nhớ cache mà bạn có thể có, theo mọi yêu cầu.

must-revalidate, mặt khác, chỉ cần xác thực lại khi tài nguyên được coi là cũ.

Nếu máy chủ thông báo rằng tài nguyên vẫn hợp lệ thì bộ nhớ đệm có thể phản hồi với biểu diễn của nó, do đó giảm bớt nhu cầu máy chủ gửi lại toàn bộ tài nguyên.

no-storehiệu quả là chỉ thị không lưu bộ nhớ cache đầy đủ và nhằm ngăn chặn việc lưu trữ biểu diễn dưới bất kỳ hình thức bộ nhớ cache nào.

Tôi nói bất cứ điều gì, nhưng lưu ý điều này trong thông số HTTP RFC 2616:

Bộ đệm lịch sử CÓ THỂ lưu trữ các phản hồi như vậy như một phần của hoạt động bình thường của chúng

Nhưng điều này được bỏ qua khỏi thông số RFC 7234 HTTP mới hơn có khả năng là một nỗ lực để làm cho no-storemạnh hơn, hãy xem:

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

Trong một số trường hợp nhất định, IE6 sẽ vẫn lưu trữ các tệp trong bộ nhớ cache ngay cả khi Cache-Control: no-cacheở trong tiêu đề phản hồi.

Các W3C nói củano-cache :

Nếu lệnh no-cache không chỉ định tên trường, thì cache KHÔNG PHẢI sử dụng phản hồi để đáp ứng yêu cầu tiếp theo mà không cần xác thực lại thành công với máy chủ gốc.

Trong ứng dụng của tôi, nếu bạn truy cập một trang có no-cachetiêu đề, sau đó đăng xuất và sau đó truy cập lại trong trình duyệt của mình, IE6 sẽ vẫn lấy trang đó từ bộ nhớ cache (mà không có yêu cầu mới / xác thực đối với máy chủ). Thêm vào no-storetiêu đề ngăn nó làm như vậy. Nhưng nếu bạn sử dụng W3C theo lời của họ, thực sự không có cách nào để kiểm soát hành vi này:

Bộ đệm lịch sử CÓ THỂ lưu trữ các phản hồi như vậy như một phần của hoạt động bình thường của chúng.

Sự khác biệt chung giữa lịch sử trình duyệt và bộ đệm HTTP thông thường được mô tả trong phần phụ cụ thể của thông số kỹ thuật .

Từ đặc tả HTTP 1.1 :

không có cửa hàng :

Mục đích của cửa hàng khôngchỉ thị là để ngăn chặn việc vô tình phát hành hoặc lưu giữ thông tin nhạy cảm (ví dụ: trên các băng sao lưu). Chỉ thị không có cửa hàng áp dụng cho toàn bộ tin nhắn và CÓ THỂ được gửi trong một phản hồi hoặc trong một yêu cầu. Nếu được gửi trong một yêu cầu, bộ nhớ cache KHÔNG ĐƯỢC lưu trữ bất kỳ phần nào của yêu cầu này hoặc bất kỳ phản hồi nào đối với nó. Nếu được gửi trong một phản hồi, bộ nhớ cache KHÔNG ĐƯỢC lưu trữ bất kỳ phần nào của phản hồi này hoặc yêu cầu tạo ra nó. Chỉ thị này áp dụng cho cả bộ đệm không chia sẻ và bộ đệm được chia sẻ. "KHÔNG PHẢI lưu trữ" trong ngữ cảnh này có nghĩa là bộ đệm ẩn PHẢI cố ý lưu trữ thông tin trong bộ nhớ không bay hơi và PHẢI cố gắng hết sức để xóa thông tin khỏi bộ nhớ dễ bay hơi càng nhanh càng tốt sau khi chuyển tiếp. Ngay cả khi chỉ thị này được liên kết với một phản hồi, người dùng có thể lưu trữ một cách rõ ràng phản hồi như vậy bên ngoài hệ thống bộ nhớ đệm (ví dụ: với hộp thoại "Lưu dưới dạng"). Bộ đệm lịch sử CÓ THỂ lưu trữ các phản hồi như vậy như một phần của hoạt động bình thường của chúng. Mục đích của chỉ thị này là để đáp ứng các yêu cầu đã nêu của một số người dùng và tác giả dịch vụ nhất định lo ngại về việc vô tình phát hành thông tin qua các truy cập không lường trước đến cấu trúc dữ liệu bộ nhớ cache. Mặc dù việc sử dụng chỉ thị này có thể cải thiện quyền riêng tư trong một số trường hợp, nhưng chúng tôi lưu ý rằng nó KHÔNG phải là cơ chế đáng tin cậy hoặc đủ để đảm bảo quyền riêng tư theo bất kỳ cách nào. Đặc biệt, bộ nhớ đệm độc hại hoặc bị xâm nhập có thể không nhận ra hoặc không tuân theo chỉ thị này và các mạng truyền thông có thể dễ bị nghe trộm. Bộ đệm lịch sử CÓ THỂ lưu trữ các phản hồi như vậy như một phần của hoạt động bình thường của chúng. Mục đích của chỉ thị này là để đáp ứng các yêu cầu đã nêu của một số người dùng và tác giả dịch vụ nhất định lo ngại về việc vô tình phát hành thông tin qua các truy cập không lường trước đến cấu trúc dữ liệu bộ nhớ cache. Mặc dù việc sử dụng chỉ thị này có thể cải thiện quyền riêng tư trong một số trường hợp, nhưng chúng tôi lưu ý rằng nó KHÔNG phải là cơ chế đáng tin cậy hoặc đủ để đảm bảo quyền riêng tư theo bất kỳ cách nào. Đặc biệt, bộ nhớ đệm độc hại hoặc bị xâm nhập có thể không nhận ra hoặc không tuân theo chỉ thị này và các mạng truyền thông có thể dễ bị nghe trộm. Bộ đệm lịch sử CÓ THỂ lưu trữ các phản hồi như vậy như một phần của hoạt động bình thường của chúng. Mục đích của chỉ thị này là để đáp ứng các yêu cầu đã nêu của một số người dùng và tác giả dịch vụ nhất định lo ngại về việc vô tình phát hành thông tin qua các truy cập không lường trước đến cấu trúc dữ liệu bộ nhớ cache. Mặc dù việc sử dụng chỉ thị này có thể cải thiện quyền riêng tư trong một số trường hợp, nhưng chúng tôi lưu ý rằng nó KHÔNG phải là cơ chế đáng tin cậy hoặc đủ để đảm bảo quyền riêng tư theo bất kỳ cách nào. Đặc biệt, bộ nhớ đệm độc hại hoặc bị xâm nhập có thể không nhận ra hoặc không tuân theo chỉ thị này và các mạng truyền thông có thể dễ bị nghe trộm. Mặc dù việc sử dụng chỉ thị này có thể cải thiện quyền riêng tư trong một số trường hợp, nhưng chúng tôi lưu ý rằng nó KHÔNG phải là cơ chế đáng tin cậy hoặc đủ để đảm bảo quyền riêng tư theo bất kỳ cách nào. Đặc biệt, bộ nhớ đệm độc hại hoặc bị xâm nhập có thể không nhận ra hoặc không tuân theo chỉ thị này và các mạng truyền thông có thể dễ bị nghe trộm. Mặc dù việc sử dụng chỉ thị này có thể cải thiện quyền riêng tư trong một số trường hợp, nhưng chúng tôi lưu ý rằng nó KHÔNG phải là cơ chế đáng tin cậy hoặc đủ để đảm bảo quyền riêng tư theo bất kỳ cách nào. Đặc biệt, bộ nhớ đệm độc hại hoặc bị xâm nhập có thể không nhận ra hoặc không tuân theo chỉ thị này và các mạng truyền thông có thể dễ bị nghe trộm.

Nếu bạn muốn ngăn chặn tất cả bộ nhớ đệm (ví dụ: buộc tải lại khi sử dụng nút quay lại), bạn cần:

• no-cache cho IE

• no-store cho Firefox

Có thông tin của tôi về điều này ở đây:

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

no-storekhông cần thiết trong các tình huống bình thường, và có thể gây hại cho cả tốc độ và khả năng sử dụng. Nó được thiết kế để sử dụng khi phản hồi HTTP chứa thông tin nhạy cảm đến mức nó không bao giờ được ghi vào bộ nhớ cache trên đĩa, bất kể những tác động tiêu cực tạo ra cho người dùng.

Làm thế nào nó hoạt động:

• Thông thường, ngay cả khi tác nhân người dùng như trình duyệt xác định rằng phản hồi không nên được lưu vào bộ nhớ cache, nó vẫn có thể lưu nó vào bộ đệm ẩn đĩa vì những lý do bên trong tác nhân người dùng. Phiên bản này có thể được sử dụng cho các tính năng như "xem nguồn", "quay lại", "thông tin trang", v.v., trong đó người dùng không nhất thiết phải yêu cầu lại trang, nhưng trình duyệt không coi đó là một lần xem trang mới và sẽ có ý nghĩa nếu cung cấp cùng một phiên bản mà người dùng hiện đang xem.

• Việc sử dụng no-storesẽ ngăn phản hồi đó được lưu trữ, nhưng điều này có thể ảnh hưởng đến khả năng của trình duyệt cung cấp "nguồn xem", "quay lại", "thông tin trang", v.v. mà không đưa ra yêu cầu mới, riêng biệt cho máy chủ, điều này là không mong muốn. Nói cách khác, người dùng có thể thử xem nguồn và nếu trình duyệt không giữ nó trong bộ nhớ, họ sẽ được thông báo rằng điều này là không thể hoặc nó sẽ tạo ra một yêu cầu mới đến máy chủ. Do đó, no-storechỉ nên được sử dụng khi trải nghiệm người dùng bị cản trở của các tính năng này không hoạt động bình thường hoặc nhanh chóng vượt trội bởi tầm quan trọng của việc đảm bảo nội dung không được lưu trữ trong bộ nhớ cache.

Sự hiểu biết hiện tại của tôi là nó chỉ dành cho máy chủ bộ đệm trung gian. Ngay cả khi phản hồi "no-cache", máy chủ cache trung gian vẫn có thể lưu nội dung vào bộ nhớ không bay hơi.

Điều này là không đúng. Các máy chủ bộ đệm trung gian tương thích với HTTP 1.1 sẽ tuân theo các hướng dẫn no-cachevà must-revalidatechỉ dẫn, đảm bảo rằng nội dung không được lưu vào bộ đệm. Sử dụng các hướng dẫn này sẽ đảm bảo rằng phản hồi không được lưu vào bộ đệm ẩn bởi bất kỳ bộ đệm trung gian nào và tất cả các yêu cầu tiếp theo sẽ được gửi trở lại máy chủ gốc.

Nếu máy chủ cache trung gian không hỗ trợ HTTP 1.1, thì bạn sẽ cần sử dụng Pragma: no-cachevà hy vọng điều tốt nhất. Lưu ý rằng nếu nó không hỗ trợ HTTP 1.1 thì no-storedù sao cũng không liên quan.

Nếu một hệ thống bộ nhớ đệm thực hiện đúng cách không lưu trữ, thì bạn sẽ không cần bộ nhớ đệm. Nhưng không phải tất cả đều làm. Ngoài ra, một số trình duyệt triển khai no-cache giống như không có cửa hàng. Vì vậy, mặc dù không bắt buộc nghiêm ngặt, nhưng có lẽ an toàn nhất là bao gồm cả hai.

Lưu ý rằng Internet Explorer từ phiên bản 5 trở lên 8 sẽ gặp lỗi khi cố tải xuống tệp được phân phát qua https và máy chủ gửi Cache-Control: no-cachehoặc Pragma: no-cachetiêu đề.

Xem http://support.microsoft.com/kb/812935/en-us

Việc sử dụng Cache-Control: no-storevà Pragma: privatedường như là thứ gần nhất vẫn hoạt động.

Đối với chrome, no-cache được sử dụng để tải lại trang khi truy cập lại, nhưng nó vẫn lưu vào bộ nhớ cache nếu bạn quay lại lịch sử (nút quay lại). Để tải lại trang cũng như quay lại lịch sử, hãy sử dụng tính năng không cần lưu trữ. IE cần phải được xác thực lại để hoạt động trong mọi trường hợp.

Vì vậy, để đảm bảo tránh tất cả các lỗi và hiểu sai, tôi luôn sử dụng

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

nếu tôi muốn đảm bảo rằng nó sẽ tải lại.

Ban đầu, chúng tôi đã sử dụng no-cache nhiều năm trước và đã gặp phải một số vấn đề với nội dung cũ với một số trình duyệt nhất định ... Rất tiếc, không nhớ chi tiết cụ thể.

Kể từ đó, chúng tôi đã giải quyết CHỈ bằng việc sử dụng không có cửa hàng. Kể từ đó, chưa bao giờ nhìn lại hoặc gặp vấn đề với nội dung cũ bởi bất kỳ trình duyệt hoặc trung gian nào.

Không gian này chắc chắn bị chi phối bởi thực tế của việc triển khai so với những gì xảy ra đã được viết trong các RFC khác nhau. Đặc biệt, nhiều proxy có xu hướng nghĩ rằng họ làm tốt hơn công việc "cải thiện hiệu suất" bằng cách thay thế chính sách mà họ được cho là phải tuân theo bằng chính sách của chính họ.

Chỉ để làm cho mọi thứ tồi tệ hơn nữa, trong một số trường hợp, không thể sử dụng no-cache, nhưng no-store có thể:

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

OWASP thảo luận về điều này:

Sự khác biệt giữa các chỉ thị kiểm soát bộ nhớ cache: no-cache và no-store là gì?

Lệnh no-cache trong một phản hồi chỉ ra rằng phản hồi không được sử dụng để phục vụ yêu cầu tiếp theo, tức là bộ đệm không được hiển thị phản hồi có chỉ thị này được đặt trong tiêu đề nhưng phải để máy chủ phục vụ yêu cầu. Lệnh no-cache có thể bao gồm một số tên trường; trong trường hợp đó phản hồi có thể được hiển thị từ bộ nhớ cache ngoại trừ các tên trường được chỉ định sẽ được cung cấp từ máy chủ. Lệnh no-store áp dụng cho toàn bộ thông báo và chỉ ra rằng bộ đệm ẩn không được lưu trữ bất kỳ phần nào của phản hồi hoặc bất kỳ yêu cầu nào yêu cầu nó.

Tôi có hoàn toàn an toàn với những chỉ thị này không?

Không. Nhưng nói chung, hãy sử dụng cả Cache-Control: no-cache, no-store và Pragma: no-cache, ngoài Expires: 0 (hoặc một ngày GMT được cập nhật đầy đủ chẳng hạn như kỷ nguyên UNIX). Các loại nội dung không phải html như pdf, tài liệu word, bảng tính excel, v.v. thường được lưu vào bộ nhớ cache ngay cả khi các chỉ thị kiểm soát bộ nhớ cache ở trên được đặt (mặc dù điều này thay đổi theo phiên bản và việc sử dụng bổ sung phải xác thực lại, kiểm tra trước = 0, kiểm tra sau = 0, max-age = 0 và s-maxage = 0 trong thực tế đôi khi có thể dẫn đến việc xóa tệp ít nhất khi đóng trình duyệt trong một số trường hợp do các lỗi trình duyệt và triển khai HTTP). Ngoài ra, tính năng 'Tự động điền' cho phép trình duyệt lưu vào bộ đệm bất kỳ thứ gì người dùng nhập vào trường đầu vào của biểu mẫu. Để kiểm tra điều này, thẻ biểu mẫu hoặc các thẻ nhập riêng lẻ phải bao gồm thuộc tính 'Autocomplete = "Off"'. Tuy nhiên,

Nguồn tại đây .