เหตุใดจึงควรใช้ทั้ง no-cache และ no-store ในการตอบสนอง HTTP

ฉันได้รับคำสั่งให้ป้องกันการรั่วไหลของข้อมูลผู้ใช้การตอบสนองเพียง "ไม่มีแคช" นั้นไม่เพียงพอ "no-store" ก็จำเป็นเช่นกัน

Cache-Control: no-cache, no-store

หลังจากอ่านข้อมูลจำเพาะhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec14.htmlแล้วฉันก็ยังไม่แน่ใจว่าทำไม

ความเข้าใจในปัจจุบันของฉันคือมันมีไว้สำหรับเซิร์ฟเวอร์แคชระดับกลางเท่านั้น แม้ว่า "ไม่มีแคช" จะตอบสนอง แต่เซิร์ฟเวอร์แคชระดับกลางก็ยังสามารถบันทึกเนื้อหาลงในพื้นที่จัดเก็บที่ไม่ลบเลือนได้ เซิร์ฟเวอร์แคชระดับกลางจะตัดสินใจว่าจะใช้เนื้อหาที่บันทึกไว้สำหรับคำขอต่อไปนี้หรือไม่ อย่างไรก็ตามหาก "ไม่มีการจัดเก็บ" อยู่ในการตอบกลับเซิร์ฟเวอร์แคชระดับกลางไม่ควรจัดเก็บเนื้อหา ดังนั้นจึงปลอดภัยกว่า

มีเหตุผลอื่นอีกไหมที่เราต้องการทั้ง "no-cache" และ "no-store"?

ผมต้องชี้แจงว่าno-cacheไม่ได้หมายความว่าทำไม่ได้แคช ในความเป็นจริงมันหมายถึง "ตรวจสอบความถูกต้องกับเซิร์ฟเวอร์อีกครั้ง" ก่อนที่จะใช้การตอบกลับแคชที่คุณอาจมีในทุกคำขอ

must-revalidateในทางกลับกันจะต้องตรวจสอบอีกครั้งเมื่อทรัพยากรถือว่าเก่าเท่านั้น

หากเซิร์ฟเวอร์แจ้งว่าทรัพยากรยังคงถูกต้องแคชจะสามารถตอบสนองด้วยการเป็นตัวแทนได้ดังนั้นจึงช่วยลดความจำเป็นที่เซิร์ฟเวอร์จะต้องส่งทรัพยากรทั้งหมดอีกครั้ง

no-storeมีประสิทธิภาพคำสั่งdo not cacheแบบเต็มและมีจุดมุ่งหมายเพื่อป้องกันการจัดเก็บการเป็นตัวแทนในรูปแบบของแคชใด ๆ ก็ตาม

ฉันพูดอะไรก็ได้ แต่สังเกตสิ่งนี้ในข้อมูลจำเพาะ HTTP RFC 2616:

บัฟเฟอร์ประวัติอาจเก็บคำตอบดังกล่าวไว้เป็นส่วนหนึ่งของการทำงานปกติ

แต่สิ่งนี้ถูกละเว้นจากข้อมูลจำเพาะ HTTP RFC 7234 ที่ใหม่กว่าซึ่งอาจเป็นความพยายามที่จะทำให้no-storeแข็งแกร่งขึ้นโปรดดู:

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

ภายใต้สถานการณ์บางอย่าง IE6 จะยังคงแคชไฟล์แม้ว่าจะ Cache-Control: no-cacheจะอยู่ในส่วนหัวของการตอบกลับก็ตาม

W3C สหรัฐอเมริกาno-cache :

หากคำสั่ง no-cache ไม่ได้ระบุชื่อฟิลด์แคชจะต้องไม่ใช้การตอบสนองเพื่อตอบสนองคำขอที่ตามมาโดยไม่ต้องทำการตรวจสอบซ้ำกับเซิร์ฟเวอร์ต้นทาง

ในแอปพลิเคชันของฉันหากคุณเยี่ยมชมหน้าที่มีno-cacheส่วนหัวจากนั้นออกจากระบบแล้วกลับเข้ามาในเบราว์เซอร์ของคุณ IE6 จะยังคงดึงหน้าจากแคช (โดยไม่มีคำขอใหม่ / ตรวจสอบความถูกต้องไปยังเซิร์ฟเวอร์) การเพิ่มในno-storeส่วนหัวจะหยุดการดำเนินการดังกล่าว แต่ถ้าคุณใช้ W3C ตามคำพูดของพวกเขาไม่มีทางที่จะควบคุมพฤติกรรมนี้ได้:

บัฟเฟอร์ประวัติอาจเก็บคำตอบดังกล่าวไว้เป็นส่วนหนึ่งของการทำงานปกติ

ความแตกต่างระหว่างทั่วไปประวัติเบราเซอร์และแคช HTTP ปกติจะมีการอธิบายในเฉพาะส่วนย่อยของข้อมูลจำเพาะ

จากข้อกำหนดHTTP 1.1 :

ไม่มีร้านค้า :

วัตถุประสงค์ของ ไม่มีร้านค้าคำสั่งคือการป้องกันการเผยแพร่หรือการเก็บรักษาข้อมูลที่ละเอียดอ่อนโดยไม่ได้ตั้งใจ (ตัวอย่างเช่นในเทปสำรอง) คำสั่งห้ามเก็บมีผลกับข้อความทั้งหมดและอาจถูกส่งไปในการตอบกลับหรือคำขอ หากส่งคำขอแคชจะต้องไม่จัดเก็บส่วนใดส่วนหนึ่งของคำขอนี้หรือการตอบสนองใด ๆ หากส่งการตอบกลับแคชจะต้องไม่เก็บส่วนใดส่วนหนึ่งของการตอบกลับนี้หรือคำขอที่เรียกมา คำสั่งนี้ใช้กับทั้งแคชที่ไม่แชร์และแชร์ "ต้องไม่จัดเก็บ" ในบริบทนี้หมายความว่าแคชต้องไม่จงใจจัดเก็บข้อมูลไว้ในที่จัดเก็บข้อมูลที่ไม่ลบเลือนและต้องพยายามอย่างเต็มที่เพื่อลบข้อมูลออกจากที่จัดเก็บข้อมูลที่ระเหยได้โดยเร็วที่สุดหลังจากส่งต่อ แม้ว่าคำสั่งนี้จะเชื่อมโยงกับคำตอบ ผู้ใช้อาจจัดเก็บการตอบกลับดังกล่าวไว้อย่างชัดเจนนอกระบบแคช (เช่นด้วยกล่องโต้ตอบ "บันทึกเป็น") บัฟเฟอร์ประวัติอาจเก็บคำตอบดังกล่าวไว้เป็นส่วนหนึ่งของการทำงานปกติ วัตถุประสงค์ของคำสั่งนี้คือเพื่อให้เป็นไปตามข้อกำหนดที่ระบุไว้ของผู้ใช้และผู้เขียนบริการบางรายที่กังวลเกี่ยวกับการเผยแพร่ข้อมูลโดยไม่ได้ตั้งใจผ่านการเข้าถึงโครงสร้างข้อมูลแคชโดยไม่คาดคิด แม้ว่าการใช้คำสั่งนี้อาจปรับปรุงความเป็นส่วนตัวในบางกรณีเราขอเตือนว่าไม่มีกลไกที่เชื่อถือได้หรือเพียงพอในการรับรองความเป็นส่วนตัวในทางใดทางหนึ่ง โดยเฉพาะอย่างยิ่งแคชที่เป็นอันตรายหรือถูกบุกรุกอาจไม่รู้จักหรือปฏิบัติตามคำสั่งนี้และเครือข่ายการสื่อสารอาจเสี่ยงต่อการดักฟัง บัฟเฟอร์ประวัติอาจเก็บคำตอบดังกล่าวไว้เป็นส่วนหนึ่งของการทำงานปกติ วัตถุประสงค์ของคำสั่งนี้คือเพื่อให้เป็นไปตามข้อกำหนดที่ระบุไว้ของผู้ใช้และผู้เขียนบริการบางรายที่กังวลเกี่ยวกับการเผยแพร่ข้อมูลโดยไม่ได้ตั้งใจผ่านการเข้าถึงโครงสร้างข้อมูลแคชโดยไม่คาดคิด แม้ว่าการใช้คำสั่งนี้อาจปรับปรุงความเป็นส่วนตัวในบางกรณีเราขอเตือนว่าไม่มีกลไกที่เชื่อถือได้หรือเพียงพอในการรับรองความเป็นส่วนตัวในทางใดทางหนึ่ง โดยเฉพาะอย่างยิ่งแคชที่เป็นอันตรายหรือถูกบุกรุกอาจไม่รู้จักหรือปฏิบัติตามคำสั่งนี้และเครือข่ายการสื่อสารอาจเสี่ยงต่อการดักฟัง บัฟเฟอร์ประวัติอาจเก็บคำตอบดังกล่าวไว้เป็นส่วนหนึ่งของการทำงานปกติ วัตถุประสงค์ของคำสั่งนี้คือเพื่อให้เป็นไปตามข้อกำหนดที่ระบุไว้ของผู้ใช้และผู้เขียนบริการบางรายที่กังวลเกี่ยวกับการเผยแพร่ข้อมูลโดยไม่ได้ตั้งใจผ่านการเข้าถึงโครงสร้างข้อมูลแคชโดยไม่คาดคิด แม้ว่าการใช้คำสั่งนี้อาจปรับปรุงความเป็นส่วนตัวในบางกรณีเราขอเตือนว่าไม่มีกลไกที่เชื่อถือได้หรือเพียงพอในการรับรองความเป็นส่วนตัวในทางใดทางหนึ่ง โดยเฉพาะอย่างยิ่งแคชที่เป็นอันตรายหรือถูกบุกรุกอาจไม่รู้จักหรือปฏิบัติตามคำสั่งนี้และเครือข่ายการสื่อสารอาจเสี่ยงต่อการดักฟัง แม้ว่าการใช้คำสั่งนี้อาจปรับปรุงความเป็นส่วนตัวในบางกรณีเราขอเตือนว่าไม่มีกลไกที่เชื่อถือได้หรือเพียงพอในการรับรองความเป็นส่วนตัวในทางใดทางหนึ่ง โดยเฉพาะอย่างยิ่งแคชที่เป็นอันตรายหรือถูกบุกรุกอาจไม่รู้จักหรือปฏิบัติตามคำสั่งนี้และเครือข่ายการสื่อสารอาจเสี่ยงต่อการดักฟัง แม้ว่าการใช้คำสั่งนี้อาจปรับปรุงความเป็นส่วนตัวในบางกรณีเราขอเตือนว่าไม่มีกลไกที่เชื่อถือได้หรือเพียงพอในการรับรองความเป็นส่วนตัวในทางใดทางหนึ่ง โดยเฉพาะอย่างยิ่งแคชที่เป็นอันตรายหรือถูกบุกรุกอาจไม่รู้จักหรือปฏิบัติตามคำสั่งนี้และเครือข่ายการสื่อสารอาจเสี่ยงต่อการดักฟัง

หากคุณต้องการป้องกันการแคชทั้งหมด (เช่นบังคับให้โหลดซ้ำเมื่อใช้ปุ่มย้อนกลับ) คุณต้อง:

• ไม่มีแคชสำหรับ IE

• ไม่มีร้านค้าสำหรับ Firefox

มีข้อมูลของฉันเกี่ยวกับเรื่องนี้ที่นี่:

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

no-storeไม่จำเป็นในสถานการณ์ปกติและอาจเป็นอันตรายต่อทั้งความเร็วและการใช้งาน มีไว้สำหรับใช้ในกรณีที่การตอบสนอง HTTP มีข้อมูลที่ละเอียดอ่อนมากจึงไม่ควรเขียนลงในดิสก์แคชเลยโดยไม่คำนึงถึงผลกระทบเชิงลบที่สร้างขึ้นสำหรับผู้ใช้

มันทำงานอย่างไร:

• โดยปกติแม้ว่าตัวแทนผู้ใช้เช่นเบราว์เซอร์จะกำหนดว่าการตอบกลับไม่ควรถูกแคช แต่ก็ยังอาจเก็บไว้ในแคชของดิสก์ด้วยเหตุผลภายในตัวแทนผู้ใช้ เวอร์ชันนี้อาจใช้สำหรับคุณลักษณะต่างๆเช่น "แหล่งที่มาของการดู" "ย้อนกลับ" "ข้อมูลหน้า" และอื่น ๆ โดยที่ผู้ใช้ไม่จำเป็นต้องร้องขอหน้าเว็บอีกครั้ง แต่เบราว์เซอร์จะไม่พิจารณาว่าเป็นการดูหน้าใหม่ และควรให้บริการเวอร์ชันเดียวกับที่ผู้ใช้กำลังดูอยู่

• การใช้no-storeจะป้องกันไม่ให้มีการจัดเก็บการตอบกลับ แต่อาจส่งผลต่อความสามารถของเบราว์เซอร์ในการให้ "แหล่งที่มาของการดู" "ย้อนกลับ" "ข้อมูลหน้า" และอื่น ๆ โดยไม่ต้องร้องขอใหม่แยกต่างหากสำหรับเซิร์ฟเวอร์ซึ่งเป็นสิ่งที่ไม่พึงปรารถนา กล่าวอีกนัยหนึ่งผู้ใช้อาจลองดูแหล่งที่มาและหากเบราว์เซอร์ไม่ได้เก็บไว้ในหน่วยความจำพวกเขาจะได้รับแจ้งว่าเป็นไปไม่ได้หรือจะทำให้เกิดการร้องขอใหม่ไปยังเซิร์ฟเวอร์ ดังนั้นno-storeควรใช้เฉพาะเมื่อประสบการณ์การใช้งานที่ถูกขัดขวางของคุณลักษณะเหล่านี้ทำงานไม่ถูกต้องหรือรวดเร็วเกินดุลจากความสำคัญของการตรวจสอบว่าเนื้อหาไม่ได้ถูกเก็บไว้ในแคช

ความเข้าใจในปัจจุบันของฉันคือมันมีไว้สำหรับเซิร์ฟเวอร์แคชระดับกลางเท่านั้น แม้ว่า "ไม่มีแคช" จะตอบสนอง แต่เซิร์ฟเวอร์แคชระดับกลางก็ยังสามารถบันทึกเนื้อหาลงในพื้นที่จัดเก็บที่ไม่ลบเลือนได้

สิ่งนี้ไม่ถูกต้อง เซิร์ฟเวอร์แคชระดับกลางที่เข้ากันได้กับ HTTP 1.1 จะปฏิบัติตามno-cacheและmust-revalidateคำแนะนำเพื่อให้แน่ใจว่าเนื้อหาจะไม่ถูกแคช การใช้คำแนะนำเหล่านี้จะช่วยให้มั่นใจได้ว่าการตอบกลับไม่ได้ถูกแคชไว้โดยแคชกลางใด ๆ และคำขอที่ตามมาทั้งหมดจะถูกส่งกลับไปยังเซิร์ฟเวอร์ต้นทาง

หากเซิร์ฟเวอร์แคชระดับกลางไม่รองรับ HTTP 1.1 คุณจะต้องใช้Pragma: no-cacheและหวังว่าจะดีที่สุด โปรดทราบว่าหากไม่รองรับ HTTP 1.1 ก็no-storeไม่เกี่ยวข้องอยู่ดี

หากระบบแคชใช้การไม่จัดเก็บอย่างถูกต้องคุณก็ไม่จำเป็นต้องไม่มีแคช แต่ไม่ใช่ทั้งหมด นอกจากนี้เบราว์เซอร์บางตัวใช้การไม่มีแคชเหมือนไม่มีการจัดเก็บ ดังนั้นแม้ว่าจะไม่จำเป็นอย่างเคร่งครัด แต่ก็อาจปลอดภัยที่สุดที่จะรวมทั้งสอง

โปรดทราบว่า Internet Explorer ตั้งแต่เวอร์ชัน 5 ถึง 8 จะเกิดข้อผิดพลาดเมื่อพยายามดาวน์โหลดไฟล์ที่ให้บริการผ่าน https และเซิร์ฟเวอร์ที่ส่งCache-Control: no-cacheหรือPragma: no-cacheส่วนหัว

โปรดดูhttp://support.microsoft.com/kb/812935/en-us

การใช้ Cache-Control: no-storeและPragma: privateดูเหมือนจะเป็นสิ่งที่ใกล้เคียงที่สุดที่ยังใช้งานได้

สำหรับ chrome จะไม่มีการใช้แคชเพื่อโหลดหน้าซ้ำในการเยี่ยมชมซ้ำ แต่จะยังคงแคชไว้หากคุณย้อนกลับไปในประวัติ (ปุ่มย้อนกลับ) หากต้องการโหลดหน้าซ้ำเพื่อย้อนกลับด้วยให้ใช้ no-store IE จำเป็นต้องตรวจสอบใหม่เพื่อให้ทำงานได้ในทุกโอกาส

ดังนั้นเพื่อให้แน่ใจว่าจะหลีกเลี่ยงข้อบกพร่องและการตีความผิด ๆ ที่ฉันใช้เสมอ

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

ถ้าฉันต้องการให้แน่ใจว่าโหลดซ้ำ

เดิมทีเราใช้ no-cache เมื่อหลายปีก่อนและพบปัญหาบางอย่างเกี่ยวกับเนื้อหาเก่าในเบราว์เซอร์บางตัว ... อย่าจำข้อมูลจำเพาะไปอย่างน่าเสียดาย

ตั้งแต่นั้นมาเราได้ตัดสินเพียงแค่การใช้ไม่มีร้านค้า ไม่เคยย้อนกลับไปดูหรือมีปัญหาเกี่ยวกับเนื้อหาเก่าโดยเบราว์เซอร์หรือตัวกลางใด ๆ เลยตั้งแต่นั้นมา

พื้นที่นี้ถูกครอบงำอย่างแน่นอนโดยความเป็นจริงของการใช้งานเทียบกับสิ่งที่เกิดขึ้นจากการเขียนใน RFC ต่างๆ โดยเฉพาะผู้รับมอบฉันทะจำนวนมากมักคิดว่าตนทำงานได้ดีขึ้นในการ "ปรับปรุงประสิทธิภาพ" โดยการแทนที่นโยบายที่ควรจะปฏิบัติตามด้วยตนเอง

เพื่อให้สิ่งต่างๆแย่ลงในบางสถานการณ์ไม่สามารถใช้ no-cache ได้ แต่ไม่มีร้านค้าสามารถ:

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

OWASP กล่าวถึงสิ่งนี้:

อะไรคือความแตกต่างระหว่างคำสั่งควบคุมแคช: ไม่มีแคชและไม่มีร้านค้า?

คำสั่ง no-cache ในการตอบกลับบ่งชี้ว่าต้องไม่ใช้การตอบกลับเพื่อตอบสนองคำขอที่ตามมากล่าวคือแคชจะต้องไม่แสดงการตอบสนองที่มีชุดคำสั่งนี้ในส่วนหัว แต่ต้องปล่อยให้เซิร์ฟเวอร์ตอบสนองคำขอ คำสั่งไม่มีแคชสามารถรวมชื่อฟิลด์บางชื่อ ในกรณีนี้การตอบกลับสามารถแสดงได้จากแคชยกเว้นชื่อฟิลด์ที่ระบุซึ่งควรให้บริการจากเซิร์ฟเวอร์ คำสั่ง no-store ใช้กับข้อความทั้งหมดและระบุว่าแคชต้องไม่เก็บส่วนใด ๆ ของการตอบกลับหรือคำขอใด ๆ ที่ขอ

ฉันปลอดภัยกับคำสั่งเหล่านี้หรือไม่?

ไม่ แต่โดยทั่วไปให้ใช้ทั้ง Cache-Control: no-cache, no-store และ Pragma: no-cache นอกเหนือจาก Expires: 0 (หรือวันที่ GMT ที่ล้าสมัยอย่างเพียงพอเช่น UNIX epoch) ประเภทเนื้อหาที่ไม่ใช่ html เช่น pdf, เอกสารคำ, สเปรดชีต excel ฯลฯ มักจะถูกแคชแม้ว่าจะมีการตั้งค่าคำสั่งการควบคุมแคชด้านบนก็ตาม (แม้ว่าสิ่งนี้จะแตกต่างกันไปตามรุ่นและการใช้งานเพิ่มเติมที่ต้องตรวจสอบซ้ำ, pre-check = 0, post-check = 0, max-age = 0 และ s-maxage = 0 ในทางปฏิบัติบางครั้งอาจส่งผลอย่างน้อยในการลบไฟล์เมื่อปิดเบราว์เซอร์ในบางกรณีเนื่องจากพฤติกรรมของเบราว์เซอร์และการใช้งาน HTTP) นอกจากนี้คุณลักษณะ 'เติมข้อความอัตโนมัติ' ยังช่วยให้เบราว์เซอร์สามารถแคชสิ่งที่ผู้ใช้พิมพ์ในช่องป้อนข้อมูลของแบบฟอร์ม ในการตรวจสอบสิ่งนี้แท็กฟอร์มหรือแท็กอินพุตแต่ละรายการควรมีแอตทริบิวต์ "การเติมข้อความอัตโนมัติ =" ปิด " อย่างไรก็ตาม

แหล่งที่มาที่นี่