ไขปม SAML SSO: ถอดรหัส SAMLResponse และสาเหตุที่บางครั้งไม่ใช่ XML
เจาะลึกวิธีดีบักระบบล็อกอิน SAML SSO แยกแยะความแตกต่างระหว่าง HTTP-POST และ HTTP-Redirect พร้อมเทคนิคจัดการข้อมูลไบนารีและข้อผิดพลาด AADSTS750056
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- การดีบัก SAML SSO ต้องเข้าใจการเข้ารหัสผ่าน HTTP-POST และ HTTP-Redirect bindings
- HTTP-POST ใช้การแปลง Base64 เพียงชั้นเดียวเพื่อให้ได้ XML ตรงๆ
- HTTP-Redirect ใช้ซ้อน 3 ชั้น ได้แก่ DEFLATE, Base64 และ URLEncode ซึ่งใช้ raw DEFLATE ไม่มี zlib header
- ควรถอดรหัสแบบ client-side เสมอเพื่อป้องกันข้อมูลรั่วไหลเนื่องจาก SAML assertion ถือเป็นสิทธิ์การใช้งานจริง
เวลาที่คุณกำลังแก้ไขปัญหาระบบล็อกอิน SSO ที่พัง ตัวระบุตัวตนหรือ Identity Provider (IdP) จะทำการรีไดเรกต์กลับมายังแอปพลิเคชันของคุณ พร้อมกับแนบก้อนข้อมูลขนาดใหญ่ที่เรียกว่า SAMLResponse มาด้วย เมื่อคุณดึงข้อมูลนั้นมาทำการ Base64-decode แล้วคาดหวังว่าจะได้เห็นไฟล์ XML ที่อ่านง่ายสะอาดตา แต่บางครั้งผลลัพธ์ที่ได้กลับไม่ใช่ข้อความมาร์กอัป แต่เป็นข้อมูลไบนารีขยะที่ขึ้นต้นด้วยไบต์อย่าง 0x78 และ 0x9c
ผลลัพธ์ทั้งสองแบบนั้นถูกต้องตามกระบวนการ ความแตกต่างอยู่ที่ว่า IdP เลือกใช้ SAML binding แบบใด เมื่อคุณรู้จักห่วงโซ่การเข้ารหัสทั้งสองแบบนี้แล้ว การดีบัก SAML จะไม่ใช่การเดาอีกต่อไป โดย SAML จะส่งข้อความทั้ง SAMLResponse และ SAMLRequest ผ่าน HTTP bindings สองรูปแบบที่ทำการเข้ารหัสเพย์โหลดต่างกันดังนี้
- HTTP-POST binding: ข้อความจะอยู่ในฟอร์มฟิลด์ที่ซ่อนอยู่และส่งอัตโนมัติผ่านวิธี POST โดยมีค่าเป็น Base64(XML) ซึ่งเมื่อถอดรหัส Base64 แล้วจะได้ assertion XML ทันที มักใช้กับ Response ที่ส่งกลับมาจาก IdP
- HTTP-Redirect binding: ข้อความจะอยู่บน URL query string จึงต้องมีขนาดเล็กและปลอดภัยต่อ URL โดยมีค่าเป็น URLEncode( Base64( DEFLATE( XML ) ) ) ซึ่งมีถึงสามชั้น หากคุณถอดรหัสแค่ Base64 คุณจะพบกับผลลัพธ์ดิบของตัวบีบอัด DEFLATE และมักใช้กับ SAMLRequest และ Single Logout
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
การทำความเข้าใจเรื่อง HTTP bindings ถือเป็นหัวใจสำคัญในการพัฒนาเว็บแอปพลิเคชันยุคใหม่ที่ต้องเชื่อมต่อระบบยืนยันตัวตนกับองค์กรภายนอก (Enterprise SSO) ข้อผิดพลาดส่วนใหญ่มักเกิดจากการที่นักพัฒนาเข้าใจคลาดเคลื่อนว่าข้อมูลทั้งหมดเป็น XML ทันที ทั้งที่จริงแล้วกระบวนการบีบอัดและเข้ารหัสถูกออกแบบมาเพื่อความปลอดภัยและข้อจำกัดของขนาด URL การแยกระหว่าง POST และ Redirect จึงช่วยประหยัดเวลาในการวิเคราะห์ Log ได้อย่างมหาศาล
จุดที่นักพัฒนาผิดพลาดบ่อยที่สุดคือ Redirect binding จะใช้ raw DEFLATE ตามมาตรฐาน RFC 1951 โดยไม่มี zlib header และไม่มี checksum ทำให้เวลาที่ใช้ฟังก์ชัน zlib หรือ gzip inflate ทั่วไปเกิดสะดุดเพราะหา header ไม่เจอ แล้วสรุปไปเองว่าข้อมูลเสียหาย ทั้งที่จริงแค่ม้องการ raw inflate เท่านั้น หากคุณไม่แน่ใจว่ากำลังถือ binding แบบไหนอยู่ ให้ใช้หลักการง่ายๆ คือถ้าถอดรหัส Base64 แล้วเจอข้อความที่ขึ้นต้นด้วย <?xml หรือ <saml แสดงว่าเป็น POST แต่ถ้าได้ไบต์ประหลาด ให้ลองใช้ raw inflate ซึ่งเกือบจะฟันธงได้ว่าเป็น Redirect แน่นอน
เมื่อคุณได้ XML มาแล้ว อย่าเพิ่งแค่มองผ่าน เบาะแสการดีบักจะซ่อนอยู่ในฟิลด์เฉพาะ หากคุณใช้ IdP เป็น Azure AD หรือ Entra คุณจะต้องเคยพบกับข้อผิดพลาด AADSTS750056 ที่ระบุว่า SAMLResponse ต้องอยู่ในรูปแบบและการเข้ารหัส Base64 ที่ถูกต้อง แม้ข้อความจะบอกแบบนั้น แต่จริงๆ แล้ว assertion มักจะปกติ ส่วนใหญ่มักมีตัวกลางหรือ middleware บางตัวเข้าไปช่วยแก้ไขหรือจัดการเพย์โหลดระหว่างทางจนทำให้ข้อมูลเสียหาย ซึ่งแนวทางแก้ไขคือการรักษาความสมบูรณ์ของไบต์ต้นทางแบบ end-to-end และห้ามให้ระบบกลางเข้ามาดัดแปลงข้อมูลโดยเด็ดขาด
"What's the weirdest SAML failure you've had to decode your way out of? Share it in the comments."
PJ Anderson
พึงระลึกไว้เสมอว่า SAML assertion คือข้อมูลประจำตัว (credential) ในช่วงเวลาสั้นๆ ที่ยังมีผลใช้งาน ใครก็ตามที่ถือครองมันสามารถสวมรอยเป็นผู้ใช้งานคนนั้นได้ ดังนั้นเวลาที่คุณถอดรหัสเพื่อดีบัก จงทำมันบนฝั่งไคลเอนต์ (client-side) เท่านั้น ห้ามนำ production assertion ไปวางสุ่มสี่สุ่มห้าบนเครื่องมือถอดรหัสออนไลน์บนเซิร์ฟเวอร์ของบุคคลที่สามเด็ดขาด เพราะนั่นเท่ากับการส่งกุญแจเข้าสู่ระบบที่ใช้งานจริงไปให้เซิร์ฟเวอร์อื่นทันที สำหรับการถอดรหัสในเครื่องอย่างรวดเร็ว สามารถใช้เครื่องมือบนเบราว์เซอร์แบบฟรีที่ช่วยตรวจจับ binding อัตโนมัติ ทั้งถอด URL, ถอด Base64, ทำ raw DEFLATE, จัดรูปแบบ XML และดึงค่า claims ออกมาให้โดยทำงานบน client-side 100% ไม่มีข้อมูลส่งไปที่เซิร์ฟเวอร์ภายนอก
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น