ในเหตุการณ์หลังจาก CVE-2023-36035 ซึ่งเป็นช่องโหว่ร้ายแรงประเภท HTTP request smuggling ใน .NET ที่ได้รับคะแนนความรุนแรงสูงถึง 9.9 จาก 10 กลุ่มชุมชนนักพัฒนาได้มีส่วนร่วมในการอภิปรายที่ร้อนระอุเกี่ยวกับหลักการความปลอดภัยพื้นฐาน ช่องโหว่ซึ่งส่งผลกระทบต่อหลายเวอร์ชันของ ASP.NET Core และเซิร์ฟเวอร์ Kestrel ได้เปิดเผยคำถามที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับวิธีการจัดการโปรโตคอลเว็บ และการที่ระบบยอมรับคำขอที่มีรูปแบบไม่ถูกต้องมากเกินไปอาจสร้างความเสี่ยงด้านความปลอดภัยให้กับระบบหรือไม่
 |
|---|
| ข้อความสำรองที่แสดงในเว็บเบราว์เซอร์ เน้นย้ำถึงความสำคัญของการจัดการคำขอที่เหมาะสมในการพัฒนาเว็บ |
ช่องโหว่ที่สั่นสะเทือนระบบนิเวศ .NET
การค้นพบ CVE-2023-36035 เมื่อไม่นานมานี้ เปิดเผยว่าเฟรมเวิร์ก .NET ของ Microsoft มีข้อบกพร่องร้ายแรงในวิธีการประมวลผลคำขอ HTTP/1.1 ช่องโหว่นี้อนุญาตให้ผู้โจมตีสามารถดำเนินการโจมตีแบบ request smuggling ซึ่งอาจทำให้สามารถเข้าถึงข้อมูลสำคัญโดยไม่ได้รับอนุญาตและเกิดการละเมิดความปลอดภัยร้ายแรงอื่นๆ ได้ ปัญหานี้มีสาเหตุมาจากการแยกวิเคราะห์ส่วนหัว HTTP ใน System.Net.Http.dll ที่ไม่เหมาะสม โดยเฉพาะอย่างยิ่งในวิธีการที่เฟรมเวิร์กจัดการกับส่วนหัว Content-Length และ Transfer-Encoding
สิ่งที่ทำให้ช่องโหว่นี้น่ากังวลเป็นพิเศษคือผลกระทบที่กว้างขวาง across หลายเวอร์ชันของ .NET ตั้งแต่เวอร์ชันเก่าที่หมดอายุการสนับสนุนแล้ว จนถึงเวอร์ชันล่าสุดอย่าง .NET 9 ชุมชนตระหนักอย่างรวดเร็วว่านี่ไม่ใช่เพียงบั๊กทั่วไปที่ต้องแพตช์ แต่เป็นข้อบกพร่องพื้นฐานในวิธีการที่เว็บเซิร์ฟเวอร์ตีความคำขอ HTTP ที่คลุมเครือ
เวอร์ชัน .NET ที่ได้รับผลกระทบ:
- ASP.NET Core: >= 6.0.0 <= 6.0.36
- ASP.NET Core: >= 8.0.0 <= 8.0.20
- ASP.NET Core: >= 9.0.0 <= 9.0.9
- ASP.NET Core: <= 10.0.0-rc.1
- Microsoft.AspNetCore.Server.Kestrel.Core: <= 2.3.0
กฎของ Postel: หลักการความแข็งแกร่ง หรือ ฝันร้ายด้านความปลอดภัย?
การอภิปรายได้เปลี่ยนไปสู่กฎของ Postel หรือที่รู้จักในชื่อหลักการความแข็งแกร่ง ซึ่งระบุว่า: จงระมัดระวังในสิ่งที่คุณส่งออกไป และจงเปิดกว้างในสิ่งที่คุณรับเข้ามา หลักการนี้ได้ชี้นำการออกแบบโปรโตคอลอินเทอร์เน็ตมาหลายทศวรรษ แต่หลายคนในชุมชนตอนนี้ตั้งคำถามว่ามันยังมีประโยชน์ในบริบทความปลอดภัยสมัยใหม่หรือไม่
ฉันมักจะโต้แย้งกับผู้คนเกี่ยวกับว่ากฎของ Postel นั้นเป็นแนวทางที่ผิด การเปิดกว้างในสิ่งที่คุณรับมานั้นมีต้นทุนที่มหาศาลสำหรับระบบนิเวศทั้งหมด และมีวิธีที่ดีกว่ามากในการออกแบบความยืดหยุ่นเข้าไปในโปรโตคอล
ความรู้สึกนี้สะท้อนไปทั่วทั้งการอภิปรายในชุมชน โดยมีผู้แสดงความคิดเห็นหลายคนชี้ให้เห็นว่าการแยกวิเคราะห์ที่ยืดหยุ่นเกินไปสร้างสายโซ่การพึ่งพาที่ไคลเอ็นต์เริ่มอาศัยพฤติกรรมที่ไม่เป็นมาตรฐาน เมื่อพฤติกรรมนี้กลายเป็นสิ่งที่คาดหวัง มันก็แทบจะเป็นไปไม่ได้ที่จะแก้ไขปัญหาด้านความปลอดภัยโดยไม่ทำลายความเข้ากันได้ สงครามการแยกวิเคราะห์ HTML ระหว่างเบราว์เซอร์ต่างๆ ทำหน้าที่เป็นเรื่องเล่าเพื่อเตือนสติ – เมื่อเบราว์เซอร์หนึ่งยืดหยุ่นในการแยกวิเคราะห์มากขึ้น เบราว์เซอร์อื่นๆ ทั้งหมดก็ต้องทำตามเพื่อให้สามารถแข่งขันได้ ส่งผลให้เกิดการแข่งขันเพื่อลดมาตรฐานด้านความปลอดภัย
ปัญหาเกี่ยวกับพร็อกซี่และความท้าทายด้านสภาพแวดล้อม
หัวข้อหลักอีกประการหนึ่งในการอภิปรายของชุมชนเกี่ยวข้องกับความท้าทายของสภาพแวดล้อมการทดสอบและการปรับใช้งาน ผู้แสดงความคิดเห็นหลายคนตั้งข้อสังเกตว่าสภาพแวดล้อมการผลิตมักแตกต่างอย่างมีนัยสำคัญจากสภาพแวดล้อมการพัฒนาและสเตจจิ่ง โดยเฉพาะอย่างยิ่งในวิธีการกำหนดค่าพร็อกซี่และโหลดบาลานเซอร์ สิ่งนี้สร้างสถานการณ์ที่ช่องโหว่อาจไม่ปรากฏขึ้นระหว่างการทดสอบ แต่สามารถถูกโจมตีได้ในสภาพแวดล้อมการผลิต
ปัญหานี้ทวีความรุนแรงขึ้นในสภาพแวดล้อมองค์กรที่ข้อจำกัดด้านต้นทุนป้องกันไม่ให้รักษาสภาพแวดล้อมสเตจจิ่งและการผลิตที่เหมือนกันทุกประการ ดังที่ผู้แสดงความคิดเห็นหนึ่งระบุ แพลตฟอร์มธนาคารขนาดใหญ่ที่มีมูลค่าการดำเนินงานหลายสิบหรือหลายร้อยล้านดอลลาร์สหรัฐ ไม่สามารถทำซ้ำเพื่อวัตถุประสงค์ในการทดสอบได้ นอกจากนี้ ข้อกำหนดทางกฎหมายในภาคส่วนต่างๆ เช่น การดูแลสุขภาพและการเงิน มักห้ามใช้ข้อมูลการผลิตในสภาพแวดล้อมการพัฒนา ทำให้การทดสอบที่แม่นยำเป็นเรื่องที่ท้าทายยิ่งขึ้น
กลยุทธ์การบรรเทาผลกระทบเชิงปฏิบัติและความเป็นจริงของการปรับใช้งาน
ในขณะที่วิธีแก้ไขปัญหาในทันทีเกี่ยวข้องกับการแพตช์ความปลอดภัย การอภิปรายในชุมชนเผยให้เห็นความกังวลที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับกลไกการอัปเดต ซึ่งแตกต่างจากแอปพลิเคชัน Windows แบบดั้งเดิมที่ได้รับการอัปเดตอัตโนมัติผ่าน Windows Update, .NET applications ที่ปรับใช้งานในคอนเทนเนอร์หรือเป็น executable แบบสแตนด์อโลน ต้องการการ build ใหม่และปรับใช้งานใหม่ด้วยตนเองเพื่อรับการแก้ไขด้านความปลอดภัย
การให้คะแนนช่องโหว่นี้ที่ 9.9/10 ก่อให้เกิดการถกเถียงเกี่ยวกับว่าสิ่งนี้สะท้อนถึงความเสี่ยงจริงสำหรับการปรับใช้งานส่วนใหญ่หรือไม่ หลายคนแย้งว่าแอปพลิเคชันที่อยู่หลังพร็อกซี่สมัยใหม่อย่าง nginx, Cloudflare, หรือ AWS ALB มีแนวโน้มที่จะได้รับการป้องกันอยู่แล้ว เนื่องจากพร็อกซี่เหล่านี้จะปฏิเสธคำขอที่มีรูปแบบไม่ถูกต้องซึ่งใช้ในการโจมตีช่องโหว่ อย่างไรก็ตาม แอปพลิเคชันที่เปิดเผยสู่สาธารณะโดยตรงหรืออยู่หลังการกำหนดค่าพร็อกซี่รุ่นเก่ายังคงมีความเสี่ยงอย่างมีนัยสำคัญ
กลยุทธ์การลดความเสี่ยง:
- ติดตั้งแพตช์ความปลอดภัยสำหรับ CVE-2023-36035
- ปิดการใช้งาน HTTP/1.1 ในกรณีที่เป็นไปได้
- ใช้พร็อกซีสมัยใหม่ (nginx, Cloudflare, AWS ALB)
- ใช้การตรวจสอบคำขอที่เข้มงวด
- พิจารณาปิดการใช้งาน HTTP/2 ในการกำหนดค่าที่มีช่องโหว่
- ตรวจสอบให้แน่ใจว่ามีการแยกวิเคราะห์ที่สอดคล้องกันระหว่างเซิร์ฟเวอร์ front-end และ back-end
การเปลี่ยนแปลงทางวัฒนธรรมในการพัฒนาเว็บ
เหนือไปจากรายละเอียดทางเทคนิค ช่องโหว่นี้ได้กระตุ้นให้เกิดการทบทวนวัฒนธรรมการพัฒนา ผู้แสดงความคิดเห็นระบุถึงความแตกต่างระหว่างแนวปฏิบัติการพัฒนา .NET ระดับองค์กร ซึ่งการตรวจสอบความถูกต้องของอินพุตอย่างเข้มงวดเป็นเรื่องที่พบได้บ่อยกว่า และแนวปฏิบัติการพัฒนาเว็บในวงกว้างซึ่งการแยกวิเคราะห์ที่ยืดหยุ่นกลายเป็นบรรทัดฐาน การย้ายไปใช้ .NET Core และฐานผู้ใช้ของเฟรมเวิร์กที่ขยายตัวขึ้น หมายความว่าความเชื่อทางวัฒนธรรมจากชุมชนนักพัฒนาที่แตกต่างกันกำลังมาปะทะกัน
การอภิปรายยังกล่าวถึงช่องว่างทักษะในอุตสาหกรรม โดยผู้แสดงความคิดเห็นหนึ่งระบุอย่างตรงไปตรงมาว่า ส่วนใหญ่แล้วเรื่องเหล่านี้มัก归结 ลงที่ปัญหาทักษะ ซึ่งสะท้อนถึงความกังวลว่าความรู้พื้นฐานเกี่ยวกับโปรโตคอลอาจลดลง เนื่องจากนักพัฒนาพึ่งพาเฟรมเวิร์กและ abstraction มากขึ้น แทนที่จะเข้าใจโปรโตคอลพื้นฐานที่พวกเขากำลังทำงานอยู่
ประเภทของ HTTP Request Smuggling ที่พบบ่อย:
- CL.TE: ฝั่ง Front-end ใช้ Content-Length ส่วนฝั่ง Back-end ใช้ Transfer-Encoding
- TE.CL: ฝั่ง Front-end ใช้ Transfer-Encoding ส่วนฝั่ง Back-end ใช้ Content-Length
- TE.TE: ทั้งสองฝั่งรองรับ Transfer-Encoding แต่สามารถชักจูงให้ฝั่งใดฝั่งหนึ่งไม่ประมวลผลได้
มองไปข้างหน้า: การออกแบบโปรโตคอลและความปลอดภัย
เหตุการณ์ CVE-2023-36035 ทำหน้าที่เป็นสัญญาณเตือนสำหรับอุตสาหกรรมซอฟต์แวร์ทั้งหมด แม้ว่าการแพตช์ในทันทีจะเป็นสิ่งจำเป็น แต่การสนทนาในวงกว้างชี้ให้เห็นว่าเราจำเป็นต้องพิจารณาหลักการพื้นฐานของการออกแบบและใช้งานโปรโตคอลใหม่ ดูเหมือนว่าชุมชนกำลังไปสู่ฉันทามติว่าการแยกวิเคราะห์ที่เข้มงวดและการปฏิเสธคำขอที่มีรูปแบบไม่ถูกต้อง แม้อาจทำให้ระบบรุ่นเก่าบางระบบใช้งานไม่ได้ แต่ให้ความปลอดภัยในระยะยาวที่ดีกว่าการดำเนินต่อไปด้วยการใช้งานที่ยืดหยุ่น
ในขณะที่อุตสาหกรรมก้าวไปสู่โปรโตคอลใหม่ๆ เช่น HTTP/2 และ HTTP/3 มีโอกาสที่จะเรียนรู้จากข้อผิดพลาดเหล่านี้และสร้างรากฐานที่ปลอดภัยยิ่งขึ้น อย่างไรก็ตาม การคงอยู่ของ HTTP/1.1 ในสภาพแวดล้อมหลายแห่ง หมายความว่าช่องโหว่เหล่านี้จะยังคงมีความเกี่ยวข้องไปอีกหลายปีข้างหน้า ซึ่งต้องการความตื่นตัวอย่างต่อเนื่องจากทีมนักพัฒนาและทีมปฏิบัติการ
การตอบสนองของชุมชน .NET ต่อช่องโหว่นี้แสดงให้เห็นถึงทั้งวุฒิภาวะของระบบนิเวศซอฟต์แวร์สมัยใหม่ในการจัดการเหตุการณ์ด้านความปลอดภัย และความท้าทายอย่างต่อเนื่องในการสร้างสมดุลระหว่างความเข้ากันได้กับความปลอดภัย ดังที่ผู้แสดงความคิดเห็นหนึ่งกล่าวไว้อย่างรวบรัด ช่องโหว่นี้เป็นตัวแทนของต้นทุนของการเปิดกว้างในสิ่งที่คุณรับมา – ต้นทุนที่อุตสาหกรรมอาจไม่ยินดีจ่ายอีกต่อไป
อ้างอิง: Understanding the worst .NET vulnerability ever: request smuggling and CVE-2023-36035