ชุมชนนักพัฒนาเว็บกำลังต่อสู้กับปัญหาความปลอดภัยร้ายแรงเกี่ยวกับการใช้งาน HTTP/1.1 หลังจากผู้เชี่ยวชาญเปิดเผยว่าแม้แต่ parser ที่ผ่านการทดสอบมาอย่างดียังคงมีความเห็นไม่ตรงกันในการตีความคำขอ ความไม่ลงรอยกันนี้กลายเป็นอันตรายอย่างยิ่งเมื่อรวมกับ reverse proxy และ pipelined request ทำให้เกิดช่องโหว่ที่อาจส่งผลต่อความปลอดภัยของเว็บแอปพลิเคชัน
ความท้าทายในการใช้งาน Parser สร้างความเสี่ยงด้านความปลอดภัย
ปัญหาหลักเกิดจากความซับซ้อนของการ parse HTTP/1.1 ที่การใช้งานต่างๆ จัดการกับกรณีขอบเขตได้แตกต่างกัน เมื่อคำขอผ่าน reverse proxy ไปยัง origin server ความแตกต่างในการ parse เหล่านี้อาจนำไปสู่การโจมตีแบบ request desynchronization ปัญหานี้รุนแรงมากจนนักวิจัยด้านความปลอดภัยบางคนเรียกร้องให้ยกเลิกการใช้ HTTP/1.1 ทั้งหมดเพื่อหันไปใช้เวอร์ชันโปรโตคอลที่ใหม่กว่า
การสนทนาในชุมชนเผยให้เห็นว่าแม้ HTTP parser อาจดูเหมือนเป็นปัญหาที่แก้ไขได้แล้ว แต่อันตรายอยู่ที่นักพัฒนาที่พยายามสร้าง parser ของตัวเองโดยไม่เข้าใจความซับซ้อนของโปรโตคอลอย่างเต็มที่ ลักษณะที่ดูเรียบง่ายของ HTTP/1.1 มักทำให้ประเมินความซับซ้อนที่เกี่ยวข้องในการสร้าง parser ที่ปลอดภัยและเป็นไปตามมาตรฐานต่ำเกินไป
Parser: ซอฟต์แวร์ที่อ่านและตีความคำขอ HTTP ตามข้อกำหนดของโปรโตคอล Request desynchronization: เมื่อเซิร์ฟเวอร์ต่างๆ ตีความคำขอ HTTP เดียวกันแตกต่างกัน ซึ่งอาจทำให้ผู้โจมตีสามารถแอบแฝงคำขอที่เป็นอันตรายได้
ไทม์ไลน์วิวัฒนาการของโปรโตคอล HTTP
- HTTP/1.0: โปรโตคอลแบบง่ายที่มีฟังก์ชันการทำงานพื้นฐาน
- HTTP/1.1: เพิ่มฟีเจอร์ต่างๆ เช่น การเชื่อมต่อแบบถาวร การส่งคำขอแบบ pipelining และการเข้ารหัสแบบ chunked
- HTTP/2: นำเสนอ multiplexing และ binary framing
- HTTP/3: สร้างขึ้นบนโปรโตคอล QUIC เพื่อปรับปรุงประสิทธิภาพ
ข้อกังวลด้านความปลอดภัยที่สำคัญ
- การโจมตีแบบ request desynchronization ผ่านความไม่ตรงกันของ parser
- คำขอ HTTP แบบ pipelined ที่สร้างช่องโหว่กับ reverse proxy
- ความแตกต่างในการจัดการกรณีพิเศษระหว่างการใช้งานต่างๆ
- การใช้งาน parser แบบกำหนดเองที่ขาดการพิจารณาด้านความปลอดภัยที่เหมาะสม
ความเรียบง่ายที่หลอกลวงของ HTTP/1.0 เทียบกับความซับซ้อนสมัยใหม่
ในขณะที่ HTTP/1.0 พร้อมการสนับสนุน Host header พื้นฐานยังคงค่อนข้างตรงไปตรงมาในการใช้งาน แต่การพัฒนาไปสู่ HTTP/1.1 ได้นำความซับซ้อนที่สำคัญเข้ามา ชุมชนยอมรับว่าความเรียบง่ายของ HTTP/1.0 ทำให้มันสวยงามและเข้าถึงได้ แต่ข้อจำกัดของมันผลักดันให้ต้องมีฟีเจอร์ที่ซับซ้อนมากขึ้นในเวอร์ชันต่อมา
การเปลี่ยนผ่านจาก HTTP/1.1 ไปสู่ HTTP/2 และ HTTP/3 ได้ขยายความท้าทายเหล่านี้เพิ่มขึ้นเท่านั้น การใช้งานสมัยใหม่มักต้องสนับสนุน HTTP หลายเวอร์ชันพร้อมกัน ทำให้ความซับซ้อนสะสมมากกว่าการแทนที่ วิธีการแบบชั้นๆ นี้หมายความว่าแม้แต่การใช้งาน HTTP/3 ที่ล้ำสมัยก็มักต้องรักษาการสนับสนุน HTTP/1.1 ไว้ ซึ่งสืบทอดความท้าทายในการ parse ทั้งหมดมา
ผลกระทบในทางปฏิบัติต่อการพัฒนาเว็บ
ผลกระทบด้านความปลอดภัยขยายไปไกลกว่าความกังวลเชิงทฤษฎี การใช้งานในโลกจริงเผชิญกับความเสี่ยงที่แท้จริงเมื่อส่วนประกอบต่างๆ ในโครงสร้างพื้นฐานเว็บของพวกเขาตีความคำขอ HTTP ไม่สอดคล้องกัน สิ่งนี้เป็นปัญหาโดยเฉพาะในสถาปัตยกรรมที่ซับซ้อนที่เกี่ยวข้องกับ load balancer, reverse proxy และ origin server จากผู้ขายต่างๆ
แม้แต่การใช้งานที่ได้รับความนิยมและผ่านการทดสอบมาอย่างดียังคงมีความเห็นไม่ตรงกันในการตีความคำขอ ซึ่งทำให้เกิดช่องโหว่เมื่อส่งต่อไปยัง origin server
แม้จะมีความท้าทายเหล่านี้ ชุมชนนักพัฒนาเว็บยังคงพึ่งพา HTTP/1.1 อย่างมากเนื่องจากการยอมรับอย่างแพร่หลายและความพร้อมใช้งานของไลบรารีที่เป็นผู้ใหญ่ นักพัฒนาส่วนใหญ่หลีกเลี่ยงการใช้งาน parser แบบกำหนดเอง แต่ใช้ประโยชน์จากไลบรารีที่ผ่านการทดสอบดีซึ่งมีให้ใช้งานในภาษาโปรแกรมและแพลตฟอร์มเกือบทุกตัว
การสนทนาที่กำลังดำเนินอยู่เน้นย้ำถึงความตึงเครียดพื้นฐานในการพัฒนาโปรโตคอลเว็บ: ความต้องการความเข้ากันได้แบบย้อนหลังและการยอมรับในระดับสากลมักขัดแย้งกับเป้าหมายด้านความปลอดภัยและความเรียบง่าย ขณะที่เว็บยังคงพัฒนาต่อไป การแก้ไขความไม่สอดคล้องกันของ parser เหล่านี้กลายเป็นสิ่งสำคัญสำหรับการรักษาโครงสร้างพื้นฐานอินเทอร์เน็ตที่ปลอดภัย
อ้างอิง: HTTP IS NOT SIMPLE