การลดระดับ HTTP และความเสี่ยงจากเนื้อหาผสม

ส่วนหัว HTTP Strict Transport Security (HSTS) สั่งให้เบราว์เซอร์เชื่อมต่อกับเว็บไซต์ผ่าน HTTPS เท่านั้นเป็นระยะเวลาที่กำหนด เมื่อได้รับส่วนหัวนี้แล้ว เบราว์เซอร์จะปฏิเสธการเชื่อมต่อ HTTP และเปลี่ยน URL ที่ขึ้นต้นด้วย http:// เป็น https:// โดยอัตโนมัติ

ตัวอย่างส่วนหัว HSTS ทั่วไป: "Strict-Transport-Security: max-age=31536000; includeSubDomains; preload" ค่า max-age มีหน่วยเป็นวินาที (31536000 = 1 ปี) เมื่อแคชไว้แล้ว เบราว์เซอร์จะบังคับใช้ HTTPS เป็นเวลาหนึ่งปีโดยไม่ต้องติดต่อเซิร์ฟเวอร์อีก

พารามิเตอร์ max-age กำหนดระยะเวลาที่เบราว์เซอร์ควรบังคับใช้การเชื่อมต่อผ่าน HTTPS เท่านั้น โดยมีหน่วยเป็นวินาที สำหรับเว็บไซต์ที่ใช้งานจริง แนะนำให้กำหนดอย่างน้อยหนึ่งปี (31536000)

คำสั่ง includeSubDomains ขยายการบังคับใช้ HSTS ไปยังโดเมนย่อยทั้งหมด วิธีนี้ป้องกันการโจมตีที่ผู้โจมตีลดระดับการเชื่อมต่อของโดเมนย่อยเป็น HTTP แล้วใช้การเชื่อมต่อนั้นขโมยคุกกี้ที่ตั้งไว้โดยไม่มีแฟล็ก Secure บนโดเมนหลัก

เบราว์เซอร์มาพร้อมรายการโดเมนที่กำหนดไว้ตายตัวให้ใช้ HTTPS เท่านั้น แม้ในการเข้าชมครั้งแรกสุด รายการนี้ดูแลอยู่ที่ hstspreload.org และมีเว็บไซต์ขนาดใหญ่หลายพันแห่งรวมอยู่ด้วย

การโหลดล่วงหน้ากำจัดช่องโหว่ในการเข้าชมครั้งแรกได้ หากไม่มีการโหลดล่วงหน้า ผู้เข้าชมครั้งแรกอาจถูกดักไว้ก่อนที่จะได้รับส่วนหัว HSTS เว็บไซต์ที่อยู่ในรายการโหลดล่วงหน้าจะใช้ HTTPS เท่านั้นตั้งแต่คำขอแรก โดยไม่ขึ้นกับสถานะแคชของ HSTS

การถอด SSL ซึ่งเผยแพร่โดย Moxie Marlinspike ที่งาน Black Hat 2009 เป็นการโจมตีแบบ MITM ที่ลดระดับการเชื่อมต่อจาก HTTPS เป็น HTTP ผู้โจมตีดักคำขอ HTTP แรกเริ่มของผู้ใช้ ส่งคำขอ HTTPS ไปยังเซิร์ฟเวอร์จริงแทนผู้ใช้ แล้วส่งต่อเนื้อหากลับมายังผู้ใช้ผ่าน HTTP

ผู้เสียหายยังเห็นเนื้อหาตามปกติ แต่การเชื่อมต่อเป็น HTTP ข้อมูลยืนยันตัวตนที่กรอกจะถูกส่งไปยังผู้โจมตี ก่อนมี HSTS การโจมตีนี้มีประสิทธิภาพสูงมาก เพราะผู้ใช้ไม่ทันสังเกตว่าไม่มีไอคอนแม่กุญแจ

HSTS ป้องกันการถอด SSL เพราะเบราว์เซอร์จะปฏิเสธการเชื่อมต่อ HTTP ไปยังโดเมนที่ลงทะเบียนกับ HSTS แม้ผู้โจมตีจะพยายามให้บริการหน้าเว็บผ่าน HTTP เบราว์เซอร์ก็จะปฏิเสธการเชื่อมต่อและแสดงข้อผิดพลาด

เบราว์เซอร์บังคับใช้ HSTS ก่อนส่งคำขอเครือข่ายใด ๆ ดังนั้นผู้โจมตีจึงแทรกแซงไม่ได้ ช่องโหว่ที่เหลืออยู่เพียงอย่างเดียวคือการเข้าชมครั้งแรกก่อนที่จะได้รับ HSTS ซึ่งการโหลดล่วงหน้าจะกำจัดช่องโหว่นี้

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

เนื้อหาปะปนแบบทำงานประกอบด้วยสคริปต์ สไตล์ชีต iframe และ XMLHttpRequests ที่โหลดผ่าน HTTP สคริปต์ HTTP สามารถทำลายความปลอดภัยของหน้า HTTPS ได้อย่างสมบูรณ์ เพราะมีสิทธิ์เข้าถึง DOM ทั้งหมด และสามารถอ่านคุกกี้กับข้อมูลในแบบฟอร์มได้

เบราว์เซอร์สมัยใหม่จะบล็อกเนื้อหาปะปนแบบทำงาน (สคริปต์ สไตล์ชีต และ iframe ผ่าน HTTP) เป็นค่าเริ่มต้น เมื่อหน้าเว็บที่ครอบอยู่ใช้ HTTPS ระบบจะแสดงข้อผิดพลาดในคอนโซลและไม่โหลดทรัพยากรนั้น

ตั้งแต่ Chrome 81 (2020) เบราว์เซอร์เริ่มเปลี่ยนเนื้อหาปะปนแบบไม่ทำงานเป็น HTTPS โดยอัตโนมัติ หากมีทรัพยากรเวอร์ชัน HTTPS ระบบจะโหลดเวอร์ชันนั้น หากไม่มี ระบบจะบล็อกทรัพยากร

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

แผง Security ใน DevTools จะแสดงภาพรวมด้านความปลอดภัยอย่างครบถ้วน ได้แก่ รายละเอียดใบรับรอง ข้อมูลการเชื่อมต่อ และรายการทรัพยากรที่ไม่ปลอดภัยทั้งหมดบนหน้าเว็บ

คำสั่ง "upgrade-insecure-requests" ของ Content Security Policy (CSP) สั่งให้เบราว์เซอร์เปลี่ยนคำขอ HTTP ทั้งหมดจากหน้าเว็บเป็น HTTPS โดยอัตโนมัติ วิธีนี้ช่วยจัดการเนื้อหาเก่าที่มี URL HTTP กำหนดตายตัว

ต่างจากการบล็อกเนื้อหาปะปน คำสั่ง upgrade-insecure-requests จะพยายามเรียกทรัพยากรเวอร์ชัน HTTPS ก่อน คำสั่งนี้มีประโยชน์ระหว่างการย้ายจาก HTTP ไปยัง HTTPS เมื่อการแก้ไข URL ที่ฝังอยู่ทั้งหมดในเนื้อหาเก่าเป็นเรื่องที่ทำได้ยาก

หากไม่มี HTTPS ISP สามารถแทรกเนื้อหาลงในการตอบกลับ HTTP ได้ มีการตรวจพบ ISP หลายรายแทรกโฆษณาลงในหน้าเว็บที่เดิมไม่มีโฆษณา เพิ่มพิกเซลติดตาม หรือแทรกหน้าคำเตือนเมื่อผู้ใช้ใกล้ใช้ข้อมูลถึงขีดจำกัด

การแทรกเนื้อหารูปแบบนี้ไม่สามารถทำได้บนหน้า HTTPS เพราะการตอบกลับผ่านการยืนยันตัวตนและเข้ารหัสไว้ การแก้ไขใด ๆ จะทำให้การตรวจสอบ MAC ของ TLS ล้มเหลว ส่งผลให้เกิดข้อผิดพลาดในการเชื่อมต่อแทนที่จะให้บริการเนื้อหาที่ถูกแก้ไข

ก่อนที่เบราว์เซอร์จะเคยเห็นส่วนหัว HSTS ของโดเมน การเข้าชมครั้งแรกผ่าน HTTP จะมีช่องโหว่ ผู้โจมตีสามารถดักคำขอแรกเริ่มนี้และดำเนินการถอด SSL ได้โดยไม่ทำให้เบราว์เซอร์แสดงคำเตือน

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

ทดสอบความเข้าใจเกี่ยวกับความปลอดภัยการขนส่งแบบเคร่งครัดของ HTTP

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

การถอด SSL (Moxie Marlinspike, 2009) ลดระดับ HTTPS เป็น HTTP และ HSTS ป้องกันการโจมตีนี้ เบราว์เซอร์จะบล็อกเนื้อหาปะปนแบบทำงาน (สคริปต์ HTTP บนหน้า HTTPS) คำสั่ง upgrade-insecure-requests ของ CSP ช่วยย้ายเนื้อหาเก่าจาก HTTP ไปยัง HTTPS โดยอัตโนมัติ