SAML Shield ที่เพิ่งเปิดตัวโดย Stytch ซึ่งเป็นเครื่องมือรักษาความปลอดภัยแบบโอเพนซอร์สที่ออกแบบมาเพื่อป้องกันช่องโหว่ SAML กำลังสร้างการถกเถียงในชุมชนนักพัฒนาเกี่ยวกับประสิทธิภาพและช่องโหว่ด้านความปลอดภัยที่อาจเกิดขึ้น เครื่องมือนี้มีเป้าหมายเพื่อให้ชั้นความปลอดภัยสำหรับการใช้งาน SAML แต่ผู้เชี่ยวชาญกำลังตั้งคำถามสำคัญเกี่ยวกับข้อจำกัดและความท้าทายในการติดตั้ง
ตัวเลือกการติดตั้ง SAML Shield
| ตัวเลือก | คุณสมบัติ | ข้อจำกัด |
|---|---|---|
| Open Source | • ไลบรารี Node.js ฟรี<br>• การผสานรวมโดยตรง<br>• ไม่ต้องพึ่งพาบริการภายนอก | • รองรับเฉพาะ Node.js <br>• จำกัดขนาด XML payload ที่ 1MB<br>• ต้องอัปเดตด้วยตนเอง |
| Managed | • รองรับ API หลายภาษา<br>• การผสานรวมแบบ Proxy ( NGINX , Istio )<br>• อัปเดตอัตโนมัติ<br>• วางแผนรองรับ backtesting | • ต้องสมัครสมาชิก<br>• ต้องพึ่งพาบริการภายนอก<br>• ไม่สามารถตรวจสอบ encrypted assertions ในโหมด proxy |
ความกังวลเรื่องช่องโหว่ Dual Parser
นักวิจัยด้านความปลอดภัยกำลังเน้นย้ำถึงความกังวลที่สำคัญเกี่ยวกับโหมดการติดตั้งแบบ proxy ของ SAML Shield ปัญหานี้เกิดจากการใช้ XML parser สองตัวที่แตกต่างกันในห่วงโซ่ความปลอดภัย คือ xmldom ใน SAML Shield และ parser อื่นๆ ที่แอปพลิเคชันเป้าหมายใช้ การตั้งค่านี้อาจทำให้ผู้โจมตีสามารถสร้างเอกสารที่เป็นอันตรายที่สามารถหลีกเลี่ยงการตรวจสอบของ SAML Shield ได้โดยการใช้ประโยชน์จากความแตกต่างในการตีความโครงสร้าง XML เดียวกันของแต่ละ parser ช่องโหว่ล่าสุดเช่น CVE-2025-25292 ได้แสดงให้เห็นว่าความแตกต่างของ parser สามารถถูกใช้ประโยชน์เพื่อหลีกเลี่ยงมาตรการรักษาความปลอดภัยได้
XML parsers เป็นส่วนประกอบซอฟต์แวร์ที่อ่านและตีความเอกสาร XML โดยแปลงให้เป็นรูปแบบที่แอปพลิเคชันสามารถทำงานด้วยได้
การป้องกัน Replay Attack ที่ไม่สมบูรณ์
แนวทางของเครื่องมือในการป้องกัน replay attack ได้รับการวิพากษ์วิจารณ์จากผู้เชี่ยวชาญด้านความปลอดภัย ปัจจุบัน SAML Shield พึ่งพาการตรวจสอบความถูกต้องตาม timestamp เป็นหลักมากกว่าการติดตาม unique assertion identifiers วิธีการนี้ทิ้งช่องโหว่ที่ผู้โจมตีที่มีความซับซ้อนสามารถใช้ประโยชน์ได้โดยการนำ valid assertions กลับมาใช้ใหม่ภายในช่วงเวลาที่กำหนด แม้ว่า Stytch จะยอมรับข้อจำกัดนี้และวางแผนที่จะใช้การติดตาม assertion ID ฝั่งเซิร์ฟเวอร์สำหรับเวอร์ชันที่มีการจัดการของพวกเขา แต่เวอร์ชันโอเพนซอร์สยังคงเผชิญกับความท้าทายในการรักษาข้อมูล state ที่จำเป็น
Replay attacks เกี่ยวข้องกับการนำข้อมูลการรับรองความถูกต้องที่จับได้ก่อนหน้านี้กลับมาใช้เพื่อเข้าถึงโดยไม่ได้รับอนุญาต
ช่องโหว่ของ SAML ที่ได้รับการแก้ไข
- การห่อหุ้มลายเซ็นดิจิทัล XML: การจัดการลายเซ็นดิจิทัล XML เพื่อหลีกเลี่ยงการตรวจสอบความถูกต้อง
- การแทรก Entity: การแทรกเอนทิตีที่เป็นอันตรายลงในเอกสาร XML
- การโจมตีแบบ Replay: การนำการยืนยันตัวตนที่ถูกต้องมาใช้ซ้ำ
- การยืนยันที่ไม่มีลายเซ็น: การประมวลผลการยืนยันโดยไม่มีลายเซ็นดิจิทัลที่เหมาะสม
จุดบอดของ Encrypted Assertion
เมื่อติดตั้งเป็น proxy SAML Shield ไม่สามารถตรวจสอบ encrypted SAML assertions ได้เพราะขาดการเข้าถึง decryption keys ข้อจำกัดนี้ลดประสิทธิภาพของเครื่องมืออย่างมีนัยสำคัญในสภาพแวดล้อมที่ใช้การเข้ารหัสสำหรับข้อมูลการรับรองความถูกต้องที่มีความละเอียดอ่อน องค์กรที่ใช้ encrypted assertions จะต้องใช้มาตรการรักษาความปลอดภัยเพิ่มเติมภายในแอปพลิเคชันของพวกเขา ซึ่งอาจทำให้ประโยชน์ด้านความสะดวกที่ SAML Shield สัญญาไว้หมดไป
ความพยายามในการร่วมมือของชุมชน
การเปิดตัวได้จุดประกายการถกเถียงในวงกว้างเกี่ยวกับการปรับปรุงความปลอดภัย SAML ทั่วทั้งระบบนิเวศ ผู้มีส่วนร่วมจาก SAML libraries ต่างๆ กำลังเรียกร้องให้มี repositories ที่แบ่งปันของ test cases การโจมตีที่ทราบแล้วที่ implementations ทั้งหมดสามารถใช้สำหรับการตรวจสอบได้ นักพัฒนาบางคนกำลังทำงานกับเครื่องมือเสริมแล้ว รวมถึง SAML attack testing frameworks และแนวทางทางเลือกที่ใช้ structural fingerprinting แทนการตรวจสอบช่องโหว่เฉพาะ
สิ่งที่ฉันอยากเห็นคือ public repo ของ SAML exploit test cases ที่ทราบแล้วที่ทุก lib สามารถตรวจสอบตัวเองได้
แม้จะมีความกังวลเหล่านี้ แต่ผู้เชี่ยวชาญด้านความปลอดภัยโดยทั่วไปมองว่า SAML Shield เป็นก้าวไปข้างหน้าในทางบวก เครื่องมือนี้จัดการกับช่องโหว่จริงใน SAML implementations และการตัดสินใจของ Stytch ที่จะเสนอทั้งเวอร์ชันโอเพนซอร์สและเวอร์ชันที่มีการจัดการให้ความยืดหยุ่นสำหรับความต้องการขององค์กรที่แตกต่างกัน อย่างไรก็ตาม ฉันทามติของชุมชนเน้นว่า SAML Shield ควรเป็นส่วนหนึ่งของกลยุทธ์ความปลอดภัยที่ครอบคลุมมากกว่าการเป็นโซลูชันแบบเดี่ยว
การถกเถียงที่กำลังดำเนินอยู่เน้นย้ำถึงความท้าทายที่ซับซ้อนของการรักษาความปลอดภัย SAML implementations และความจำเป็นในการร่วมมืออย่างต่อเนื่องระหว่างผู้ขายด้านความปลอดภัย ผู้มีส่วนร่วมโอเพนซอร์ส และชุมชนนักพัฒนาในวงกว้างเพื่อจัดการกับช่องโหว่ที่ยังคงอยู่เหล่านี้
อ้างอิง: Modernize your SAML SSO security.