นักวิจัยด้านความปลอดภัยจากบริษัท Searchlight Cyber ได้นำช่องโหว่ขนาดเล็กหลายจุดในฟีเจอร์ประมวลผลรูปภาพของ Cloudflare มาเชื่อมโยงเข้าด้วยกัน จนสามารถสั่งรันโค้ด JavaScript บนเว็บไซต์ที่ตั้งค่าความปลอดภัยเพื่อบล็อกการทำงานดังกล่าวได้สำเร็จ
Kevin Gervot และ Adam Kues ได้เผยแพร่ผลงานวิจัยนี้เมื่อวันที่ 28 ตุลาคม 2026 ในบทความวิเคราะห์ทางเทคนิคที่ใช้ชื่อว่า Cache Me If You Can โดยแสดงตัวอย่างช่องโหว่ประเภท Cross-Site Scripting (XSS) ที่สามารถโจมตีได้จริงผ่าน Endpoint /cdn-cgi/image/ บนโดเมน cloudflare[.]com ทั้งนี้ บทความดังกล่าวไม่ได้ระบุหมายเลข CVE หรือสถานะการออกแพตช์แก้ไขอย่างเป็นทางการ ผู้อ่านจึงควรตรวจสอบข้อมูลเพิ่มเติมกับทาง Cloudflare โดยตรง
ช่องโหว่ XSS ใน Cloudflare
Cloudflare ให้บริการครอบคลุมเว็บไซต์ทั้งหมดถึง 24.3% เมื่อเว็บไซต์ใดเปิดใช้งาน Cloudflare ระบบจะทำการเพิ่ม Path '/cdn-cgi/' เข้าไปยังโดเมนของเว็บไซต์นั้นโดยอัตโนมัติ ซึ่งฟีเจอร์ต่าง ๆ เช่น การตรวจสอบ Bot , การวิเคราะห์สถิติเว็บ, ระบบควบคุมการเข้าถึง และบริการปรับแต่งแปลงรูปภาพต่างทำงานอยู่ภายใต้ Path นี้ทั้งสิ้น
เนื่องจากหน้าเว็บเหล่านี้ถูกโหลดขึ้นมาจากโดเมนของลูกค้าเอง ข้อผิดพลาดใด ๆ ที่เกิดขึ้นภายในส่วนดังกล่าวจึงทำงานด้วยระดับความน่าเชื่อถือ เทียบเท่ากับเว็บไซต์นั้นทันที ซึ่งก่อนหน้านี้เคยมีนักวิจัยคนอื่นค้นพบช่องโหว่ที่สามารถหลบเลี่ยงระบบป้องกัน Content Security Policy (CSP) ภายใน Path นี้มาแล้ว โดย CSP เป็น Rule ของเบราว์เซอร์ที่ทำหน้าที่จำกัดสิทธิ์ว่าหน้าเว็บใดสามารถเรียกใช้สคริปต์ตัวใดได้บ้าง
Cloudflare ใช้เครื่องมือภาษา Rust ที่ชื่อว่า svg-hush ซึ่งพัฒนาขึ้นบนไลบรารี xml-rs ในการจัดการไฟล์รูปภาพ สำหรับคัดกรองความปลอดภัยของไฟล์ภาพ SVG โดยเครื่องมือดังกล่าวจะทำการตรวจสอบความถูกต้องของไฟล์ก่อนจะเขียนข้อมูลออกมาใหม่ อย่างไรก็ตาม นักวิจัยพบว่าไลบรารี xml-rs ทำการ Escape อักขระพิเศษเฉพาะค่าของแอตทริบิวต์ทั่วไป แต่กลับเขียนค่าของ Namespace เช่น การตั้งค่า xmlns ออกมาในรูปแบบข้อมูลดิบโดยไม่มีการแปลงอักขระ
ผู้โจมตีจึงสามารถซ่อนเครื่องหมายคำพูด (Quote Mark) ไว้ในค่าดังกล่าวเพื่อหลุดออกจากขอบเขตที่กำหนดไว้ ซึ่งในขั้นตอนนี้นั้น ระบบกรองได้ตรวจสอบและอนุมัติไฟล์ไปเรียบร้อยแล้ว ทำให้แท็กสคริปต์อันตรายสามารถผ่านออกไปได้ แม้ว่าโดยปกติ Cloudflare จะส่งไฟล์ภาพเหล่านี้พร้อมกำหนดนโยบาย default-src 'none' เพื่อบล็อกการทำงานของสคริปต์ทั้งหมดไว้ แต่ตัว Endpoint นี้กลับส่งต่อ Header 'Cache-Control' ที่มาจากรูปภาพต้นทางไปด้วย
ตามข้อกำหนดของมาตรฐาน HTTP นั้น อนุญาตให้ใช้รูปแบบคำสั่งอย่าง no-cache="Content-Security-Policy" ซึ่งเป็นการสั่งให้ระบบแคชตัด Header ที่มีชื่อดังกล่าวทิ้งไป โดยมีเพียงเบราว์เซอร์ตระกูล Chromium เท่านั้นที่ปฏิบัติตามกฎนี้ และยังยอมรับการระบุชื่อ Header ใด ๆ ก็ได้ ส่งผลให้นโยบาย CSP ยังคงมีผลบังคับใช้ในการโหลดหน้าเว็บครั้งแรก แต่หลังจากที่ Chromium บันทึกแคชของหน้านั้นไว้แล้ว นโยบายดังกล่าวจะหายไปทันที
จากนั้น ผู้โจมตีจะใช้เทคนิคขั้นสูงที่มักพบในการแข่งขัน CTF เพื่อบังคับให้ Chromium โหลดข้อมูลหน้าเว็บที่บันทึกไว้ในแคชกลับขึ้นมาทำงานใหม่ โดยการเปิดหน้าเว็บนั้นในหน้าต่างใหม่ ย้ายหน้าต่างดังกล่าวไปยังเว็บไซต์อื่น แล้วเรียกใช้คำสั่ง history[.]back() เพื่อย้อนกลับมา
ลิงก์เปิดหน้าต่างใหม่ที่มีการเชื่อมต่อกับหน้าต่างเดิมจะกันไม่ให้หน้าเว็บถูกเก็บไว้ใน Back/Forward Cache (bfcache) ส่งผลให้ Chromium ไปดึงข้อมูลจาก Disk Cache แทน และทำให้สคริปต์สามารถทำงานได้ ซึ่งการ Bypass ระบบป้องกัน CSP ที่ใช้แคชที่มีลักษณะคล้ายกัน และเคยได้รับการรายงานโดยสำนักข่าว Cyber Security News ก่อนหน้านี้ ก็อาศัยทำงานแบบเดียวกันคือการถอยกลับมาใช้ Disk Cache เมื่อหน้าเว็บไม่ถูกเก็บใน bfcache
การขยายผลการโจมตีไปยังระบบอื่น
ฟีเจอร์ Image Transformations จะดึงข้อมูลรูปภาพมาจากแหล่งที่ได้รับอนุญาตเท่านั้น โดยการตั้งค่าเริ่มต้นคือ 'This zone only' อย่างไรก็ตาม กลไกการดึงข้อมูลจะปฏิบัติตามคำสั่ง Redirect ต่อไปเรื่อย ๆ โดยไม่มีการตรวจสอบที่อยู่ปลายทางสุดท้าย ดังนั้นช่องโหว่ Open Redirect ใด ๆ บนเว็บไซต์ที่ได้รับอนุญาตจึงเปิดโอกาสให้ผู้โจมตีสามารถสั่งโหลดรูปภาพจากแหล่งใดก็ได้ตามต้องการ
ทางทีมวิจัยต้องการหาวิธีการโจมตีโดยไม่ต้องพึ่งพาช่องโหว่ Open Redirect และพบว่าทันทีที่มีการเปิดใช้งาน Cloudflare Access ให้กับโฮสต์ใด ๆ ในโซนแล้ว เอนด์พอยต์ /cdn-cgi/access/logout จะสามารถทำงานได้บนทุกโฮสต์ภายในโซนนั้นทันที โดยการตั้งค่า returnTo ของฟังก์ชันดังกล่าวสามารถยอมรับ Subdomain ใด ๆ ก็ได้ภายใต้ cloudflare[.]com
จากนั้นการเปลี่ยนเส้นทางบนโฮสต์สำหรับงานวิจัยของ Cloudflare จะส่งตัวดึงข้อมูลไปยังไฟล์ของผู้โจมตี ซึ่งช่วยให้กระบวนการ Exploit Chain เสร็จสมบูรณ์บนโซนที่มีการจำกัดแหล่งที่มาอย่างเข้มงวด จากนั้นทีมวิจัยได้ทดสอบเทคนิคแคชกับแพลตฟอร์มอื่น โดยบน Netlify Image CDN พวกเขาใช้เทคนิคนี้เพื่อตัดทั้งส่วนหัว CSP และ Content-Type ทิ้งไป ส่งผลให้ Chromium ทำการคาดเดาประเภทของไฟล์จากเนื้อหาภายใน (MIME Sniffing) และประมวลผลไฟล์ SVG ที่ขึ้นต้นด้วย <!DOCTYPE ...> เหมือนว่าเป็นไฟล์ HTML
คำสั่ง Processing Instruction ถูกนำมาใช้ซ่อนสคริปต์จากการตรวจจับของเครื่องมือล้างโค้ดอย่าง SVGO ซึ่งจะตรวจสอบเฉพาะโครงสร้าง Element เท่านั้น โดยนักวิจัยระบุว่าโค้ดที่รันอยู่บนระบบของ Netlify นั้น ไม่ได้เปิดเผยต่อสาธารณะ จึงไม่สามารถยืนยันได้ว่าตรงกับเวอร์ชันโอเพนซอร์สหรือไม่ นอกจากนี้ บริการอย่าง Amazon S3 และ Google Cloud Storage ยังอนุญาตให้ Signed Links สามารถแทนที่ Response Headers ได้ ซึ่งลิงก์ประเภทนี้สามารถกำหนดค่า response-content-type และ response-cache-control ได้โดยตรง
ประเด็นนี้มีความสำคัญอย่างยิ่งสำหรับ storage Buckets ที่ตั้งค่าอยู่เบื้องหลัง Custom Domains หรือพร็อกซีที่มีการส่งต่อพารามิเตอร์ Query Strings ซึ่งแนวคิดนี้พัฒนาต่อยอดมาจากงานวิจัยก่อนหน้านี้เกี่ยวกับการแทนที่ค่า Content-Type และการแทนที่ค่า GetObject บน S3
ข้อคิดและแนวทางป้องกัน
บทเรียนสำคัญจากกรณีนี้คือ ผู้ดูแลระบบไม่ควรไว้วางใจเฉพาะเนื้อหาภายในไฟล์เพียงอย่างเดียว Header ที่ถูกส่งผ่านระบบบริการประมวลผลรูปภาพหรือชั้นของการจัดเก็บข้อมูลถือเป็นส่วนหนึ่งของความปลอดภัยเช่นกัน ดังนั้น ทีมงานที่เกี่ยวข้องจึงควรหลีกเลี่ยงการส่งต่อ Header Cache-Control และ Header ตระกูล X-* ที่มาจากแหล่งที่ไม่น่าเชื่อถือ
นอกจากนี้ ควรตั้งค่า Header X-Content-Type-Options: nosniff และตรวจสอบอย่างละเอียดว่าเครื่องมือจัดการรูปภาพได้รับอนุญาตให้ดึงข้อมูลมาจากแหล่งใดบ้าง รวมถึงการปิดช่องโหว่ Open Redirect ที่เปิดอยู่ก็สามารถช่วยได้เช่นกัน ผลงานวิจัยที่ผ่านมาแสดงให้เห็นแล้วว่า แม้จะมีระบบคัดกรองที่เข้มงวดเพียงใดก็ยังมีโอกาสล้มเหลวได้ ดังที่พบในงานวิจัยการ Bypass ระบบ WAF ด้วย Payload XSS ดังนั้น การป้องกันแบบหลายชั้น จึงยังคงเป็นสิ่งที่มีความสำคัญสูงสุดเสมอ
ที่มา : Cybersecuritynews
You must be logged in to post a comment.