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

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

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 แต่การโจมตีเหล่านั้นใช้กลไกที่แตกต่างจากการแยกแบบข้ามต้นทาง เช่น เจค อาร์จิบาลด์ อธิบายการโจมตีบางอย่างใน วิธีเอาชนะที่ CORS

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

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

---

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