8 คะแนน โดย GN⁺ 2024-06-26 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • Polyfill.js เป็นไลบรารีโอเพนซอร์สสำหรับรองรับเบราว์เซอร์รุ่นเก่า และมีการใช้งานอยู่ในมากกว่า 100,000 เว็บไซต์
  • เมื่อเดือนกุมภาพันธ์ปีนี้ บริษัทจากจีนได้เข้าซื้อโดเมนและบัญชี Github ของ Polyfill.js จากนั้นก็เริ่มฉีดมัลแวร์ผ่านโดเมนดังกล่าวไปยังอุปกรณ์มือถือ
  • อัปเดตวันที่ 25 มิถุนายน: Google เริ่มบล็อกโฆษณา Google Ads ของเว็บไซต์อีคอมเมิร์ซที่ยังใช้งาน polyfill.io แล้ว
  • วิธีการโจมตี: โค้ดที่สร้างแบบไดนามิกโดยอิงจาก HTTP header จะทำงานเฉพาะบนอุปกรณ์มือถือบางประเภทและในบางช่วงเวลาเท่านั้น และหากตรวจพบผู้ใช้ที่เป็นผู้ดูแลระบบหรือบริการวิเคราะห์เว็บ ก็จะหน่วงการทำงานออกไป
  • ตัวอย่างมัลแวร์: รีไดเร็กต์ผู้ใช้มือถือไปยังเว็บไซต์พนันกีฬาผ่านโดเมน Google Analytics ปลอม (www. googie-anaiytics .com)
  • แนวทางรับมือ: ผู้สร้างดั้งเดิมของ Polyfill.js แนะนำว่าไม่ควรใช้ไลบรารีนี้อีกต่อไป เพราะเบราว์เซอร์สมัยใหม่ไม่จำเป็นต้องใช้แล้ว และ Fastly กับ Cloudflare ก็มีทางเลือกที่เชื่อถือได้ให้ใช้งาน
  • เหตุการณ์นี้เป็นตัวอย่างคลาสสิกของการโจมตีแบบซัพพลายเชน
  • เครื่องมือเพิ่มเติม: Sansec Watch บริการเฝ้าระวัง CSP ฟรีของ Sansec และเครื่องสแกนแบ็กเอนด์ eComscan รองรับการตรวจจับ Polyfill.io

ความเห็นของ GN⁺

  • ความเสี่ยงของการโจมตีซัพพลายเชน: เป็นกรณีตัวอย่างที่แสดงให้เห็นชัดเจนถึงความเสี่ยงด้านความปลอดภัยที่อาจเกิดขึ้นเมื่อโครงการโอเพนซอร์สถูกซื้อกิจการ โดยเฉพาะไลบรารีที่มีการใช้งานอย่างแพร่หลาย ยิ่งถูกใช้ในหลายเว็บไซต์ ความเสียหายก็ยิ่งมากได้
  • การใช้ไลบรารีทางเลือก: การเลือกใช้ทางเลือกที่เชื่อถือได้อย่าง Fastly และ Cloudflare เป็นเรื่องสำคัญ นอกจากนี้ หากการรองรับเบราว์เซอร์สมัยใหม่เพียงพอแล้ว ก็ควรพิจารณาหยุดใช้ Polyfill.js
  • ความจำเป็นของการมอนิเตอร์ความปลอดภัย: การใช้เครื่องมือด้านความปลอดภัย เช่น บริการมอนิเตอร์ CSP เพื่อตรวจสอบการเปลี่ยนแปลงของโค้ดแบบเรียลไทม์ เป็นสิ่งสำคัญ
  • การตรวจจับผู้ดูแลระบบและการหน่วงการทำงาน: วิธีที่มัลแวร์ตรวจจับผู้ดูแลระบบหรือบริการวิเคราะห์แล้วหน่วงการทำงาน เป็นความพยายามในการหลบเลี่ยงโซลูชันด้านความปลอดภัย ซึ่งจำเป็นต้องมีแนวทางรับมือ
  • การศึกษาและการสร้างการตระหนักรู้: เป็นเรื่องสำคัญที่นักพัฒนาและผู้ดูแลระบบต้องตระหนักถึงความเสี่ยงของการโจมตีแบบซัพพลายเชน พร้อมทั้งมีการอบรมด้านความปลอดภัยอย่างสม่ำเสมอและติดตามแนวโน้มความปลอดภัยล่าสุด

3 ความคิดเห็น

 
xguru 2024-06-30

ไม่เพียงแต่โดเมน polyfill.io เท่านั้น แต่ยังควรบล็อก bootcdn.net, bootcss.com, staticfile.net, staticfile.org, unionadjs.com, xhsbpza.com, union.macoms.la และ newcrbpc.com ด้วย

 
humblebee 2024-06-26

https://th.news.hada.io/topic?id=15118
เมื่อประมาณหนึ่งเดือนก่อน เห็นว่า GN เคยพูดถึงประเด็นนี้ ก็เลยติดตามด้วยความสนใจอยู่ครับ แม้จะพอทราบสาเหตุของปัญหานี้มากขึ้นในระดับหนึ่งแล้ว แต่ก็ยังรู้สึกว่าในช่วงเวลาที่ต้องใช้ในการรับมือและดำเนินมาตรการติดตามแก้ไข เว็บไซต์จำนวนมากคงหลีกเลี่ยงไม่ได้ที่จะยังคงเปิดช่องให้ถูกโจมตีต่อไป โครงสร้างมันดูเป็นแบบนั้นจริง ๆ ครับ ทั้งเหตุการณ์การละเมิดก็เพิ่มขึ้นต่อเนื่อง ขณะที่ผู้เชี่ยวชาญด้านความปลอดภัยกลับยิ่งขาดแคลน เลยอดกังวลไม่ได้ว่าสถานการณ์นี้น่าจะรุนแรงขึ้นไปอีกสักระยะหนึ่ง

 
GN⁺ 2024-06-26
ความเห็นจาก Hacker News
  • ความเสี่ยงของการใช้ CDN สาธารณะ: การใช้ CDN สาธารณะอาจทำให้มีการฝังมัลแวร์ลงในอุปกรณ์มือถือได้ เพื่อลดความเสี่ยงนี้สามารถใช้ SRI (Subresource Integrity) ได้ แต่ทางออกที่ดีที่สุดคือโฮสต์ไฟล์ผ่านบริการ CDN ของตนเองโดยตรง

  • มุมมองเชิงทฤษฎีเกม: การบำรุงรักษาซอฟต์แวร์โอเพนซอร์สต้องรองรับเว็บไซต์จำนวนมากโดยไม่ได้รับผลตอบแทน ซึ่งท้ายที่สุดอาจนำไปสู่ปัญหาด้านความปลอดภัย

  • คอนเทนต์ภายนอกของ The Washington Post และ Fox News: ทั้งสองเว็บไซต์มีคอนเทนต์ภายนอกจำนวนมากรวมอยู่ และสิ่งนี้อาจกลายเป็นเป้าหมายของการโจมตีได้

  • การคาดการณ์ของ Cloudflare: Cloudflare คาดการณ์ปัญหาลักษณะนี้ไว้แล้ว และมีโซลูชันเพื่อลดความเสี่ยงดังกล่าว

  • ความเห็นของผู้ก่อตั้งบริการ Polyfill: เขาเป็นผู้สร้างโปรเจกต์ Polyfill service แต่ไม่ได้ถือครองกรรมสิทธิ์โดเมน และตอนนี้โดเมนดังกล่าวกำลังฝังมัลแวร์อยู่ จึงแนะนำให้หยุดใช้งานทันที

  • ปัญหาที่คาดการณ์ไว้ล่วงหน้า: เป็นปัญหาที่คาดไว้ตั้งแต่ 4 เดือนก่อน และควรมีผู้คนตระหนักรู้และรับมือกับมันมากกว่านี้

  • การรีไดเรกต์ไปยังเว็บพนันกีฬา: มีกรณีที่ผู้ใช้ถูกรีไดเรกต์ไปยังเว็บไซต์ที่ไม่ต้องการ และวิธีนี้อาจได้ผลกับผู้ใช้บางส่วน

  • การไม่กล่าวถึง SRI มากพอ: น่าแปลกที่บทความไม่ได้กล่าวถึง SRI ซึ่งเป็นวิธีแก้ปัญหาที่ต้นทุนต่ำแต่มีประสิทธิภาพสูง

  • การพูดคุยกับนักพัฒนา: นักพัฒนาจำนวนมากไม่ใส่ใจกับการถูกไฮแจ็ก CDN ซึ่งอาจนำไปสู่ปัญหาด้านความปลอดภัยได้

  • แนะนำให้โฮสต์เอง: โดยทั่วไปควรโฮสต์ dependency ต่าง ๆ ด้วยตนเองเสมอ และยังช่วยปกป้องความเป็นส่วนตัวของผู้ใช้ได้ด้วย