Cyber Security Academy · บทเรียน

SAML และการรวมศูนย์ข้อมูลประจำตัว

การลงชื่อเข้าใช้ครั้งเดียวสำหรับองค์กร

SAML และการรวมศูนย์ข้อมูลประจำตัว เป็นบทเรียน Cyber Security Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cyber Security Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cyber Security Academy มีบทเรียนทั้งหมด 4 บทเรียน

SAML คืออะไร

SAML (ภาษามาร์กอัปสำหรับข้อความยืนยันด้านความปลอดภัย) เป็นมาตรฐานบน XML สำหรับแลกเปลี่ยนข้อมูลการยืนยันตัวตนและการให้สิทธิ์ ซึ่งมีบทบาทสำคัญในการลงชื่อเข้าใช้ครั้งเดียวขององค์กร

ช่วยให้ผู้ให้บริการข้อมูลประจำตัวขององค์กรรับรองผู้ใช้กับแอปพลิเคชันจำนวนมากได้
SAML 2.0 มีมาก่อน OIDC และยังคงฝังแน่นในระบบข้อมูลประจำตัวระหว่างธุรกิจกับธุรกิจและของบุคลากร

การทำความเข้าใจ SAML เป็นสิ่งจำเป็นสำหรับการป้องกันการรวมศูนย์ข้อมูลประจำตัวระดับองค์กร เพราะข้อบกพร่องด้านความไว้วางใจเพียงจุดเดียวอาจเปิดเผยแอปที่เชื่อมต่อทั้งหมด

บทบาทของ IdP และ SP

การรวมศูนย์ข้อมูลประจำตัวด้วย SAML มีฝ่ายหลักอยู่สองฝ่าย

ผู้ให้บริการข้อมูลประจำตัว (IdP) ยืนยันตัวตนผู้ใช้และออกข้อความยืนยัน (Okta, Entra ID, Ping)
ผู้ให้บริการ (SP) คือแอปพลิเคชันที่เชื่อถือ IdP และอนุญาตให้เข้าถึง

ความไว้วางใจถูกจัดตั้งนอกช่องทางด้วยการแลกเปลี่ยนข้อมูลเมตา ซึ่งรวมถึงใบรับรองสำหรับลงลายมือชื่อและ URL ของจุดปลายทาง

IdP  -> authenticates user, signs assertion
SP   -> consumes assertion, grants access
Metadata exchange establishes trust (certs, ACS URLs)

ข้อความยืนยัน SAML

องค์ประกอบหลักคือข้อความยืนยัน ซึ่งเป็นเอกสาร XML ที่ระบุว่า IdP ได้ยืนยันตัวตนของหัวเรื่องแล้ว

Subject ระบุผู้ใช้ (NameID)
Conditions กำหนดช่วงเวลาที่ใช้ได้และผู้รับที่ตั้งใจไว้
AuthnStatement บันทึกวิธีการและเวลาที่เกิดการยืนยันตัวตน
AttributeStatement มีบทบาท อีเมล และข้อมูลยืนยันกลุ่ม

<saml:Assertion>
  <saml:Subject><saml:NameID>user@corp</saml:NameID></saml:Subject>
  <saml:Conditions NotOnOrAfter="2026-06-04T10:05:00Z"
     AudienceRestriction="https://sp.example"/>
  <saml:AuthnStatement .../>
</saml:Assertion>

กระบวนการ SSO ที่เริ่มโดย SP

รูปแบบที่พบบ่อยที่สุดคือ SSO ที่เริ่มโดย SP

ผู้ใช้เข้าถึง SP ซึ่งสร้าง AuthnRequest แล้วเปลี่ยนเส้นทางไปยัง IdP
IdP ยืนยันตัวตนผู้ใช้ แล้วส่ง Response ที่ลงลายมือชื่อกลับมายัง SP ผ่านบริการรับข้อความยืนยัน (ACS) ด้วยคำขอ POST
SP ตรวจสอบข้อความยืนยันและสร้างเซสชันภายในระบบ

1. SP -> AuthnRequest -> IdP (redirect)
2. user authenticates at IdP
3. IdP -> signed SAMLResponse -> SP ACS (HTTP POST)
4. SP validates -> session

ลายมือชื่อ XML เป็นหลักยึดของความไว้วางใจ

ความปลอดภัยของ SAML อาศัยลายมือชื่อดิจิทัล XML IdP ลงลายมือชื่อให้ข้อความยืนยันและ/หรือการตอบกลับด้วยกุญแจส่วนตัว ส่วน SP ตรวจสอบด้วยใบรับรองที่เชื่อถือได้

ลงลายมือชื่อให้กับข้อความยืนยันโดยตรง ไม่ใช่เพียงการตอบกลับภายนอก
ตรวจสอบลายมือชื่อกับใบรับรอง IdP ที่ตรึงไว้จากข้อมูลเมตา ไม่ใช่ใบรับรองที่ฝังอยู่ในข้อความ

การโจมตี SAML ส่วนใหญ่มุ่งเป้าไปที่ตรรกะการตรวจสอบลายมือชื่อ

การห่อหุ้มลายมือชื่อ XML (XSW)

การห่อหุ้มลายมือชื่อ XML คือรูปแบบการโจมตีลายมือชื่อของ SAML ผู้โจมตียังคงเก็บองค์ประกอบที่ลงลายมือชื่อถูกต้องไว้ แต่เพิ่มข้อความยืนยันปลอมอีกชุดที่ตรรกะของแอปพลิเคชันนำไปอ่านจริง

ลายมือชื่อยังคงตรวจสอบผ่านเมื่อเทียบกับส่วนข้อมูลต้นฉบับ
แต่ตรรกะทางธุรกิจกลับประมวลผลข้อความยืนยันที่ถูกแทรกและไม่มีลายมือชื่อ

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

Document after XSW:
  <Response>
    <Assertion id="evil">attacker claims</Assertion>  // read by app
    <Assertion id="orig" SIGNED>real user</Assertion>  // sig valid here
  </Response>

ข้อจำกัดด้านผู้รับและผู้รับข้อความ

ข้อความยืนยันต้องผูกกับ SP ที่ตั้งใจไว้ SAML จึงมีข้อจำกัดที่ระบุไว้อย่างชัดเจน

AudienceRestriction ระบุ entity ID ของ SP ที่ข้อความยืนยันใช้ได้
Recipient ใน SubjectConfirmation ต้องตรงกับ URL ของ ACS

SP ต้องบังคับใช้ข้อจำกัดเหล่านี้ การข้ามการตรวจสอบผู้รับทำให้ข้อความยืนยันที่สร้างขึ้นสำหรับแอปหนึ่งถูกนำไปใช้ซ้ำกับอีกแอปได้

การป้องกันการนำกลับมาใช้ซ้ำและการโจมตีด้านเวลา

ข้อความยืนยันเป็นข้อมูลรับรองอายุสั้นที่ใช้ได้เพียงครั้งเดียว SP ต้องบังคับใช้เงื่อนไขนี้

ปฏิบัติตาม NotBefore และ NotOnOrAfter โดยกำหนดความคลาดเคลื่อนของนาฬิกาให้แคบ
ติดตาม ID ของข้อความยืนยันและปฏิเสธการนำกลับมาใช้ซ้ำภายในช่วงเวลาที่ใช้ได้
กำหนดให้จุดปลายทาง ACS ใช้ TLS

หากไม่ติดตามการนำกลับมาใช้ซ้ำ ข้อความยืนยันที่ถูกดักจับอาจถูกส่งเข้ามาอีกครั้งก่อนหมดอายุ

SP checks:
  now in [NotBefore, NotOnOrAfter]  (+- small skew)
  assertion.ID not seen before -> store + reject reuse

เฟเดอเรชันและสายโซ่ความไว้วางใจ

เฟเดอเรชันช่วยขยาย SSO ข้ามขอบเขตองค์กร ซึ่งบางครั้งทำผ่านฮับหรือนายหน้าที่แปลงระหว่างโพรโทคอล

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

ใช้หลักสิทธิ์เท่าที่จำเป็นกับการจับคู่แอตทริบิวต์ และเฝ้าตรวจสอบการลงทะเบียน SP ใหม่ที่ไม่คาดคิด

จุดอ่อนทั่วไปของ SAML

รูปแบบความล้มเหลวของ SAML ที่เกิดซ้ำและควรตรวจสอบมีดังนี้

ไม่ได้ตรวจสอบลายเซ็น หรือมีการเซ็นการตอบกลับแต่ไม่ได้เซ็นคำยืนยัน
เสี่ยงต่อการห่อหุ้มลายเซ็นเอกซ์เอ็มแอล
ไม่มีการตรวจสอบกลุ่มเป้าหมายหรือผู้รับ
ไม่มีการป้องกันการเล่นซ้ำ หรือกำหนดช่วงเวลาที่มีผลไว้นานเกินไป
มีการแยกวิเคราะห์เอนทิตีภายนอกของเอกซ์เอ็มแอล (XXE) บน SP
เชื่อถือใบรับรองที่ฝังอยู่ในข้อความแทนข้อมูลเมทาดาทาที่ตรึงไว้

Disable external entities in the XML parser:
  parser.setFeature(
    "http://apache.org/xml/features/disallow-doctype-decl", true)

SAML เทียบกับ OIDC

ทั้งคู่ให้บริการ SSO แต่มีการออกแบบแตกต่างกัน

SAML ใช้เอกซ์เอ็มแอล การผูกโยงผ่าน POST/การเปลี่ยนเส้นทางของเบราว์เซอร์ ใช้แพร่หลายในองค์กรและระบบบุคลากร และมีเครื่องมือที่พัฒนามานาน
OIDC ใช้เจสัน/เจดับเบิลยูที เหมาะกับบริการแบบ REST และเหมาะกับอุปกรณ์เคลื่อนที่และ SPA มากกว่า

หลายองค์กรใช้งานทั้งสองแบบ ผู้ป้องกันระบบควรรู้กฎการตรวจสอบคำยืนยันของโพรโทคอลที่แอปนั้นใช้ เนื่องจากพื้นที่โจมตีแตกต่างกัน

ตรวจสอบอย่างรวดเร็ว: การเอาชนะ XSW

เลือกกลไกป้องกันที่ดีที่สุดสำหรับการโจมตีที่อธิบายไว้

ทบทวน: SAML และเฟเดอเรชัน

ประเด็นสำคัญที่ควรจำมีดังนี้

SAML คือ SSO ระดับองค์กรที่ใช้เอกซ์เอ็มแอลระหว่าง ผู้ให้บริการข้อมูลประจำตัวกับ SP โดยใช้ คำยืนยันที่มีลายเซ็น
ความปลอดภัยขึ้นอยู่กับการ ตรวจสอบลายเซ็นเอกซ์เอ็มแอล อย่างถูกต้องโดยเทียบกับใบรับรองที่ตรึงไว้
ป้องกัน การห่อหุ้มลายเซ็นเอกซ์เอ็มแอล การเล่นซ้ำ และ XXE
บังคับใช้ข้อจำกัดด้าน กลุ่มเป้าหมาย/ผู้รับ และช่วงเวลาที่มีผลเสมอ
เฟเดอเรชันช่วยขยายความไว้วางใจ แต่เพิ่มขอบเขตความเสียหายจากผู้ให้บริการข้อมูลประจำตัวที่ถูกเจาะระบบเป็นทวีคูณ

คำถามที่พบบ่อย

บทเรียน “SAML และการรวมศูนย์ข้อมูลประจำตัว” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “SAML และการรวมศูนย์ข้อมูลประจำตัว” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cyber Security Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cyber Security Academy มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “SAML และการรวมศูนย์ข้อมูลประจำตัว”

การลงชื่อเข้าใช้ครั้งเดียวสำหรับองค์กร คุณปฏิบัติ Cyber Security Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cyber Security Academy หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Cyber Security Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน

บทเรียน “SAML และการรวมศูนย์ข้อมูลประจำตัว” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Cyber Security Academy นี้ได้ไหม

ได้ บทเรียน Cyber Security Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

← กลับไปที่ Cyber Security Academy