ชุมชนนักพัฒนา JavaScript กำลังเผชิญกับการโจมตี supply chain ที่มุ่งเป้าไปที่ตัวจัดการแพ็กเกจ NPM อีกครั้ง ทำให้เกิดคำถามที่จริงจังเกี่ยวกับความปลอดภัยของ code repository ที่ใหญ่ที่สุดในโลก เหตุการณ์ที่เกิดขึ้นเมื่อเร็วๆ นี้ได้บุกรุกแพ็กเกจยอดนิยมที่นักพัฒนาหลายพันคนใช้งานทุกวัน โดยขโมยข้อมูลที่ละเอียดอ่อนรวมถึง AWS keys และ authentication tokens
บทบาทของ Microsoft ถูกตรวจสอบอย่างใกล้ชิด
ตั้งแต่ที่ Microsoft เข้าซื้อกิจการ NPM ผ่าน GitHub ในปี 2020 บริษัทเทคโนโลยียักษ์ใหญ่แห่งนี้ได้เผชิญกับการวิพากษ์วิจารณ์ที่เพิ่มขึ้นเรื่อยๆ จากการล้มเหลวในการแก้ไขช่องโหว่ด้านความปลอดภัยพื้นฐาน บริษัทนี้ในปัจจุบันควบคุมระบบนิเวศ JavaScript ทั้งหมด - ตั้งแต่ code repository ( GitHub ) ไปจนถึงการกระจายแพ็กเกจ ( NPM ) และสภาพแวดล้อมการพัฒนาหลัก ( VS Code ) แม้จะมีเงินทุนมากมายและทรัพยากรที่กว้างขวาง แต่ Microsoft ก็มีความก้าวหน้าเพียงเล็กน้อยในการรักษาความปลอดภัยของแพลตฟอร์มจากผู้ไม่หวังดี
ปัญหาหลักอยู่ที่การตัดสินใจในการออกแบบของ NPM ที่เกิดขึ้นเมื่อกว่าทศวรษที่แล้ว ฟีเจอร์อย่าง postinstall scripts และ npx อนุญาตให้แพ็กเกจสามารถรันโค้ดใดๆ ก็ได้ระหว่างการติดตั้ง ทำให้เกิดช่องทางการโจมตีที่ง่าย เมื่อรวมกับวัฒนธรรมการอัปเดตอย่างก้าวร้าวของ NPM และแนวโน้มของระบบนิเวศในการรวม dependencies หลายร้อยหรือหลายพันตัว พื้นผิวการโจมตีจึงกลายเป็นขนาดใหญ่มหาศาล
ช่องโหว่ด้านความปลอดภัยหลักใน NPM
- Postinstall Scripts: อนุญาตให้มีการเรียกใช้โค้ดแบบไม่จำกัดระหว่างการติดตั้งแพ็กเกจ
- เครื่องมือ NPX: สามารถเรียกใช้โมดูลใดๆ จากแหล่งเว็บใดๆ โดยไม่ต้องมีการโต้ตอบจากผู้ใช้
- การอัปเดตอัตโนมัติ: วัฒนธรรมการอัปเกรดแบบก้าวร้าวด้วย semver ranges (^) เป็นค่าเริ่มต้น
- ไม่มีการลงลายเซ็นโค้ด: แพ็กเกจไม่ได้รับการลงลายเซ็นหรือตรวจสอบด้วยการเข้ารหัส
- ข้อกำหนด 2FA ที่อ่อนแอ: มีเพียงแพ็กเกจ 100 อันดับแรกเท่านั้นที่ต้องใช้การยืนยันตัวตนสองขั้นตอน
การต่อต้านของชุมชนและการแก้ไขที่เสนอ
นักพัฒนามีความหงุดหงิดเพิ่มขึ้นเรื่อยๆ กับการขาดการปรับปรุงด้านความปลอดภัยที่มีความหมาย หลายคนชี้ไปที่ตัวจัดการแพ็กเกจทางเลือกอย่าง pnpm ซึ่งปิดการใช้งาน post-install scripts โดยค่าเริ่มต้นและรวมฟีเจอร์อย่างนโยบายอายุการเผยแพร่ขั้นต่ำเพื่อชะลอการอัปเดตอัตโนมัติของแพ็กเกจที่เผยแพร่ใหม่
เครื่องมือที่เราใช้ในการสร้างซอฟต์แวร์ไม่ปลอดภัยโดยค่าเริ่มต้น และเกือบตลอดเวลา บริษัทที่ให้เครื่องมือเหล่านี้ไม่ได้รับผิดชอบต่อความปลอดภัยของผลิตภัณฑ์ของพวกเขา
ผู้เชี่ยวชาญด้านความปลอดภัยแนะนำการปรับปรุงทันทีหลายประการ: การยืนยันตัวตนแบบสองปัจจัยที่บังคับสำหรับผู้ดูแลแพ็กเกจทุกคน ข้อกำหนดการลงนามโค้ด และการสแกนอัตโนมัติเพื่อหาเนื้อหาที่เป็นอันตรายก่อนการเผยแพร่ นักพัฒนาบางคนได้ใช้มาตรการป้องกันของตนเอง รวมถึงการตรึง dependency การติดตั้งแบบ sandbox และการตรวจสอบโค้ดด้วยตนเองสำหรับการอัปเดต
มาตรการรักษาความปลอดภัยที่แนะนำ
- ใช้ pnpm แทน npm เพื่อความปลอดภัยเริ่มต้นที่ดีกว่า
- กำหนดเวอร์ชันที่แน่นอน แทนการใช้ช่วง semver
- ใช้ระยะเวลารอ สำหรับแพ็กเกจเวอร์ชันใหม่ (24-72 ชั่วโมง)
- แยกการติดตั้งในสภาพแวดล้อมปลอดภัย โดยใช้เครื่องมืออย่าง bubblewrap บน Linux
- ตรวจสอบ dependency ด้วยตนเอง สำหรับโปรเจ็กต์ที่สำคัญ
- ใช้ npm audit และเครื่องมือสแกน dependency อย่างสม่ำเสมอ
ปัญหาระบบนิเวศที่กว้างขึ้น
วิกฤตความปลอดภัยของ NPM สะท้อนถึงปัญหาที่ลึกซึ้งกว่าภายในโมเดลซอฟต์แวร์โอเพนซอร์ส บริษัท Fortune 500 พึ่งพาซอฟต์แวร์ฟรีที่ดูแลโดยอาสาสมัครที่ไม่ได้รับค่าตอบแทนเป็นอย่างมาก แต่กลับมีส่วนร้อยกลับคืนสู่โครงการสำคัญเหล่านี้เพียงเล็กน้อย สิ่งนี้สร้างสถานการณ์ที่ไม่ยั่งยืนซึ่งโครงสร้างพื้นฐานที่จำเป็นขาดการกำกับดูแลด้านความปลอดภัยที่เหมาะสม
ไม่เหมือนกับตัวจัดการแพ็กเกจอื่นๆ ที่ได้ใช้มาตรการรักษาความปลอดภัย - PyPI มี attestation และ trusted publishers, Ruby มี signed gems ตั้งแต่เวอร์ชัน 2 - NPM ได้หารือเกี่ยวกับการลงนามแพ็กเกจตั้งแต่ปี 2013 โดยมีความก้าวหน้าที่เป็นรูปธรรมเพียงเล็กน้อย ความนิยมของแพลตฟอร์มทำให้เป็นเป้าหมายที่น่าสนใจ แต่ปรัชญาการออกแบบของมันให้ความสำคัญกับความง่ายในการใช้งานมากกว่าความปลอดภัย
Package Manager ทางเลือกที่มีความปลอดภัยดีกว่า
| Package Manager | คุณสมบัติด้านความปลอดภัย |
|---|---|
| pnpm | ปิดการใช้งาน postinstall scripts โดยค่าเริ่มต้น, นโยบายอายุการเผยแพร่ขั้นต่ำ |
| PyPI | รองรับการรับรอง, ระบบผู้เผยแพร่ที่เชื่อถือได้ |
| RubyGems | รองรับ signed gems ตั้งแต่เวอร์ชัน 2 |
| Maven | กระบวนการอนุมัติทางกฎหมาย, การอัปเดตที่ได้รับการตรวจสอบอย่างละเอียดในองค์กร |
มองไปข้างหน้า
เมื่อการโจมตี supply chain กลายเป็นเรื่องที่ซับซ้อนและเกิดขึ้นบ่อยมากขึ้น ชุมชน JavaScript เผชิญกับจุดตัดสินใจที่สำคัญ นักพัฒนาบางคนสนับสนุนมาตรการรักษาความปลอดภัยที่เข้มงวดมากขึ้นแม้ว่าจะทำให้กระบวนการพัฒนาซับซ้อนขึ้น ในขณะที่คนอื่นๆ ต่อต้านการเปลี่ยนแปลงที่อาจทำให้วัฒนธรรมการทำซ้ำอย่างรวดเร็วที่กำหนดการพัฒนา JavaScript ช้าลง
สถานการณ์ปัจจุบันเน้นย้ำถึงความจำเป็นในการเปลี่ยนแปลงทั้งอุตสาหกรรมต่อความปลอดภัยของ supply chain ซอฟต์แวร์ หากไม่มีการดำเนินการที่ประสานงานกันจากเจ้าของแพลตฟอร์ม ผู้ดูแลแพ็กเกจ และองค์กรผู้บริโภค การโจมตีเหล่านี้น่าจะยังคงเพิ่มขึ้นทั้งในด้านความถี่และความซับซ้อน
อ้างอิง: Oh no, not again... a meditation on NPM supply chain attacks