เพิ่มความปลอดภัยและความเป็นส่วนตัวด้วยการอัปเดตแคช HTTP

การลืมหรือการใช้ส่วนหัว Cache-Control ในทางที่ผิดอาจส่งผลเสียต่อความปลอดภัยของเว็บไซต์และความเป็นส่วนตัวของผู้ใช้

Arthur Sonzogni
Arthur Sonzogni

โดยค่าเริ่มต้น ระบบจะอนุญาตให้แคชทรัพยากรโดยแคชทุกประเภทเสมอ การไม่ใช้หรือการใช้ส่วนหัว Cache-Control ในทางที่ผิดอาจส่งผลเสียต่อความปลอดภัยของเว็บไซต์และความเป็นส่วนตัวของผู้ใช้

สำหรับคำตอบที่ปรับเปลี่ยนในแบบของคุณซึ่งคุณต้องการเก็บไว้เป็นส่วนตัว เราขอแนะนำให้คุณดำเนินการอย่างใดอย่างหนึ่งต่อไปนี้

  • ป้องกันไม่ให้สื่อกลางแคชทรัพยากร ตั้งค่า Cache-Control: private
  • ตั้งค่าคีย์แคชรองที่เหมาะสม หากการตอบกลับแตกต่างกันเนื่องจากคุกกี้ ซึ่งอาจเกิดขึ้นเมื่อคุกกี้จัดเก็บข้อมูลเข้าสู่ระบบ ให้ตั้งค่า Vary: Cookie

อ่านต่อเพื่อดูว่าเหตุใดเรื่องนี้จึงสำคัญและดูข้อมูลต่อไปนี้

  1. ปัญหาด้านความปลอดภัยและความเป็นส่วนตัวที่คุณอาจไม่รู้
  2. แคช HTTP ประเภทต่างๆ และความเข้าใจผิดที่พบบ่อย
  3. การดำเนินการที่แนะนำสำหรับเว็บไซต์ที่มีมูลค่าสูง

ทรัพยากรที่รั่วไหลจากช่องโหว่ Spectre

ช่องโหว่ Spectre อนุญาตให้หน้าเว็บอ่านหน่วยความจำของกระบวนการของระบบปฏิบัติการ ซึ่งหมายความว่าผู้โจมตีสามารถรับสิทธิ์เข้าถึงข้อมูลข้ามแหล่งที่มาโดยไม่ได้รับอนุญาต ด้วยเหตุนี้ เบราว์เซอร์สมัยใหม่จึงจำกัดการใช้ฟีเจอร์บางอย่าง เช่น SharedArrayBuffer หรือตัวจับเวลาความละเอียดสูง ไว้สำหรับหน้าเว็บที่มีการแยกแหล่งที่มา

เว็บเบราว์เซอร์สมัยใหม่บังคับใช้นโยบายเครื่องมือฝังแบบข้ามต้นทาง (COEP) วิธีนี้ช่วยให้มั่นใจว่าทรัพยากรข้ามแหล่งที่มาจะมีลักษณะดังนี้

  • ทรัพยากรสาธารณะที่ขอโดยไม่มีคุกกี้
  • ทรัพยากรที่อนุญาตให้แชร์ข้ามโดเมนอย่างชัดเจนผ่าน CORS หรือส่วนหัว CORP

การตั้งค่า COEP ไม่ได้ป้องกันไม่ให้ผู้โจมตีใช้ประโยชน์จาก Spectre อย่างไรก็ตาม นโยบายนี้ช่วยให้มั่นใจว่าทรัพยากรข้ามแหล่งที่มาจะไม่มีคุณค่าต่อผู้โจมตี (เมื่อเบราว์เซอร์โหลดทรัพยากรดังกล่าวเป็นทรัพยากรสาธารณะ) หรืออนุญาตให้แชร์กับผู้โจมตี (เมื่อแชร์กับ CORP: cross-origin)

การแคช HTTP ส่งผลต่อ Spectre อย่างไร

หากตั้งค่าส่วนหัว Cache-Control ไม่ถูกต้อง ผู้โจมตีอาจทำการโจมตีได้ เช่น

  1. ระบบจะแคชทรัพยากรที่มีข้อมูลเข้าสู่ระบบ
  2. ผู้โจมตีโหลดหน้าเว็บที่มีการแยกแบบข้ามต้นทาง
  3. ผู้โจมตีขอทรัพยากรอีกครั้ง
  4. COEP:credentialless ตั้งค่าโดยเบราว์เซอร์ จึงดึงข้อมูลโดยไม่ใช้คุกกี้ อย่างไรก็ตาม แคชอาจแสดงผลลัพธ์ที่มีการให้สิทธิ์แทน
  5. จากนั้นผู้โจมตีจะอ่านทรัพยากรที่ปรับเปลี่ยนในแบบของคุณได้โดยใช้การโจมตี Spectre

แม้ว่าแคช HTTP ของเว็บเบราว์เซอร์จะไม่อนุญาตให้เกิดเหตุการณ์โจมตีประเภทนี้ขึ้นจริง แต่ก็มีแคชเพิ่มเติมที่อยู่นอกเหนือการควบคุมโดยตรงของเบราว์เซอร์ ซึ่งอาจทำให้การโจมตีนี้ประสบความสําเร็จ

ความเข้าใจผิดที่พบบ่อยเกี่ยวกับแคช HTTP

1. เบราว์เซอร์จะแคชทรัพยากรเท่านั้น

โดยมักจะมีแคชหลายเลเยอร์ แคชบางรายการมีไว้สำหรับผู้ใช้คนเดียว ส่วนบางรายการมีไว้สำหรับผู้ใช้หลายคน บางรายการควบคุมโดยเซิร์ฟเวอร์ บางรายการควบคุมโดยผู้ใช้ และบางรายการควบคุมโดยสื่อกลาง

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

2. SSL ป้องกันไม่ให้สื่อกลางแคชทรัพยากร HTTPS

ผู้ใช้จํานวนมากใช้พร็อกซีที่กําหนดค่าในเครื่องเป็นประจำ ไม่ว่าจะเป็นเพื่อวัตถุประสงค์ในการเข้าถึง (เช่น การแชร์การเชื่อมต่อแบบมีจํากัด) การตรวจสอบไวรัส หรือเพื่อวัตถุประสงค์ในการป้องกันข้อมูลรั่วไหล (DLP) แคชสื่อกลางกำลังทำการสกัดกั้น TLS

แคชสื่อกลางมักจะติดตั้งไว้ในเวิร์กสเตชันของพนักงานบริษัท เว็บเบราว์เซอร์ได้รับการกําหนดค่าให้เชื่อถือใบรับรองของพร็อกซีในเครื่อง

ท้ายที่สุดแล้ว พร็อกซีในเครื่องเหล่านี้อาจแคชทรัพยากร HTTPS บางรายการไว้

วิธีการทำงานของแคช HTTP

  • ระบบจะอนุญาตให้แคชทรัพยากรโดยนัยโดยค่าเริ่มต้น
  • คีย์แคชหลักประกอบด้วย URL และเมธอด (URL, วิธีการ)
  • คีย์แคชรองคือส่วนหัวที่รวมอยู่ในส่วนหัว Vary Vary: Cookie บ่งชี้ว่าคําตอบขึ้นอยู่กับ Cookie
  • ส่วนส่วนหัว Cache-Control จะให้การควบคุมที่ละเอียดยิ่งขึ้น

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

ความเสี่ยงที่ใหญ่ที่สุดเกิดขึ้นเมื่อการเข้าถึงทรัพยากรแตกต่างกันไปโดยขึ้นอยู่กับคุกกี้ แคชสื่อกลางอาจแสดงผลลัพธ์ที่ขอพร้อมคุกกี้สําหรับคําขอที่ไม่ได้ขอหากไม่มีการดําเนินการป้องกัน

เราขอแนะนําให้คุณทําตามขั้นตอนใดขั้นตอนหนึ่งต่อไปนี้

  • ป้องกันไม่ให้สื่อกลางแคชทรัพยากร ตั้งค่า Cache-Control: private
  • ตั้งค่าคีย์แคชรองที่เหมาะสม หากการตอบกลับแตกต่างกันเนื่องจากคุกกี้ ซึ่งอาจเกิดขึ้นเมื่อคุกกี้จัดเก็บข้อมูลเข้าสู่ระบบ ให้ตั้งค่า Vary: Cookie

โดยเฉพาะอย่างยิ่ง ให้เปลี่ยนลักษณะการทำงานเริ่มต้น: กําหนด Cache-Control หรือ Vary เสมอ

ข้อควรพิจารณาเพิ่มเติม

การโจมตีประเภทอื่นๆ ที่คล้ายกันซึ่งใช้แคช HTTP ก็มี แต่การโจมตีเหล่านั้นอาศัยกลไกที่แตกต่างจากการแยกแหล่งที่มาหลายแหล่ง ตัวอย่างเช่น Jake Archibald อธิบายการโจมตีบางอย่างในวิธีชนะที่ CORS

การโจมตีเหล่านี้ได้รับการบรรเทาโดยเว็บเบราว์เซอร์บางรุ่นซึ่งแยกแคช HTTP ออก โดยขึ้นอยู่กับว่ามีการขอคำตอบของทรัพยากรด้วยข้อมูลเข้าสู่ระบบหรือไม่ ตั้งแต่ปี 2022 เป็นต้นไป Firefox จะแยกแคช ส่วน Chrome และ Safari จะไม่แยก Chrome อาจแยกแคชในอนาคต โปรดทราบว่าการโจมตีเหล่านี้แตกต่างกันและช่วยเสริมการแยกตามต้นทางระดับบนสุด

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

รูปภาพส่วนหัวโดย Ben Pattinson ใน Unsplash