การโจมตีโทเค็นและการเสริมความแข็งแกร่ง
ป้องกันโฟลว์การยืนยันตัวตนจากการนำไปใช้ในทางที่ผิด
การโจมตีโทเค็นและการเสริมความแข็งแกร่ง เป็นบทเรียน Cyber Security Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cyber Security Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cyber Security Academy มีบทเรียนทั้งหมด 4 บทเรียน
โทเค็นในฐานะข้อมูลรับรอง
ในการยืนยันตัวตนสมัยใหม่ โทเค็นคือข้อมูลรับรอง ผู้ใดก็ตามที่ถือโทเค็นแบบผู้ถือที่ถูกต้องจะได้รับการปฏิบัติเสมือนเป็นฝ่ายที่ผ่านการยืนยันตัวตนแล้ว จนกว่าโทเค็นจะหมดอายุหรือถูกเพิกถอน
- การขโมยโทเค็นจึงเทียบเท่ากับการขโมยข้อมูลรับรอง
- การเสริมความแข็งแกร่งมุ่งจำกัดอายุการใช้งานของโทเค็น ผูกโทเค็นกับผู้ถือ และเปิดให้เพิกถอนได้อย่างรวดเร็ว
บทเรียนนี้ครอบคลุมการโจมตีโทเค็นของ OAuth/OIDC/SAML และมาตรการป้องกันที่ใช้รับมือ
ความสับสนของอัลกอริทึม JWT
การโจมตี JWT แบบคลาสสิกอาศัยส่วนหัว alg
- alg: none หากระบบยอมรับ จะเปิดให้ผู้โจมตีสร้างโทเค็นที่ไม่มีลายเซ็นขึ้นมาได้
- ความสับสนจาก RS256 เป็น HS256 ผู้โจมตีจะเซ็นโทเค็นใหม่โดยใช้คีย์ RSA สาธารณะเป็นข้อมูลลับของ HMAC
การป้องกันคือกำหนดอัลกอริทึมที่คาดหวังไว้ตายตัวที่ฝั่งเซิร์ฟเวอร์ และอย่าให้โทเค็นเป็นผู้กำหนดว่าจะใช้เส้นทางการตรวจสอบใด
Vulnerable: verify(token, key) // alg taken from header
Hardened: verify(token, key, { algorithms: ["RS256"] })
// reject alg:none, reject HS* when RS* expectedการขโมยโทเค็นผ่าน XSS และบันทึกการทำงาน
การเจาะโทเค็นที่พบได้บ่อยที่สุดคือการขโมยโทเค็นที่ถูกต้องไปตรง ๆ
- XSS อ่านโทเค็นจาก
localStorageหรือหน่วยความจำได้ - โทเค็นใน ที่อยู่เว็บ อาจรั่วผ่านประวัติเบราว์เซอร์ ส่วนหัวผู้อ้างอิง และบันทึกของเซิร์ฟเวอร์
- การบันทึกส่วนหัว
Authorizationอย่างละเอียดเกินจำเป็น
ควรใช้คุกกี้ httpOnly, Secure, SameSite สำหรับเซสชันเบราว์เซอร์ และลบโทเค็นออกจากบันทึกการทำงานและที่อยู่เว็บ
Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax
// keeps JS (and thus XSS) from reading the tokenการโจมตีแบบเล่นซ้ำ
การโจมตีแบบเล่นซ้ำคือการนำโทเค็นที่ถูกต้องซึ่งถูกดักจับไว้กลับมาใช้ เพื่อดำเนินการในฐานะเหยื่อ
- ลดความเสี่ยงได้ด้วยการหมดอายุระยะสั้น ค่า
nonceที่ใช้ได้ครั้งเดียว (OIDC) และการติดตามรหัสคำยืนยัน (SAML) - TLS ป้องกันการดักจับข้อมูลบนเครือข่ายแบบพาสซีฟ
- โทเค็นที่ผูกกับผู้ส่งจะป้องกันการนำกลับมาใช้ซ้ำได้ แม้โทเค็นจะถูกขโมย
Replay defenses:
short exp + nonce/jti uniqueness
TLS everywhere
sender-constrained tokens (mTLS / DPoP)โทเค็นที่ผูกกับผู้ส่ง
โทเค็นแบบผู้ถือสามารถใช้ได้โดยทุกคนที่ถือโทเค็นนั้น โทเค็นที่ผูกกับผู้ส่งจะผูกโทเค็นเข้ากับ key ของไคลเอ็นต์ที่ระบุ
- โทเค็นที่ผูกกับ mTLS (RFC 8705) จะผูกโทเค็นเข้ากับใบรับรอง TLS ของไคลเอ็นต์
- ดีพีโอพี (RFC 9449) จะผูกโทเค็นเข้ากับ key สำหรับพิสูจน์การครอบครอง ซึ่งไคลเอ็นต์ใช้เซ็นในแต่ละคำขอ
ดังนั้นโทเค็นที่ถูกขโมยจะใช้การไม่ได้หากไม่มี key ส่วนตัวที่ตรงกัน
DPoP: each request carries a signed proof JWT
DPoP: <proof-jwt signed with client private key>
Authorization: DPoP <access_token>อายุการใช้งานสั้นและการหมุนโทเค็นรีเฟรช
จำกัดช่วงเวลาที่โทเค็นที่ถูกขโมยยังใช้ประโยชน์ได้
- กำหนดให้ โทเค็นเข้าถึงมีอายุสั้น (ระดับนาที)
- ใช้ การหมุนโทเค็นรีเฟรช โดยการรีเฟรชแต่ละครั้งจะออกโทเค็นรีเฟรชใหม่และทำให้โทเค็นเก่าใช้ไม่ได้
- ตรวจจับ การนำกลับมาใช้ซ้ำของโทเค็นรีเฟรชที่ผ่านการหมุนแล้วว่าเป็นสัญญาณการขโมย และเพิกถอนสายโซ่ทั้งหมด
On /token refresh:
issue new RT, invalidate old RT
if old RT presented again -> breach -> revoke familyการเพิกถอนและการตรวจสอบสถานะโทเค็น
เจดับเบิลยูทีแบบบรรจุข้อมูลในตัวเองจะยังใช้ได้จนกว่าจะหมดอายุ ทำให้การเพิกถอนทำได้ซับซ้อน ควรมีกลไกสำหรับตัดสิทธิ์การเข้าถึงอย่างรวดเร็ว
- ปลายทางการเพิกถอน (RFC 7009) ทำให้โทเค็นรีเฟรชและโทเค็นเข้าถึงใช้ไม่ได้
- การตรวจสอบสถานะ (RFC 7662) ช่วยให้เซิร์ฟเวอร์ทรัพยากรตรวจสอบสถานะโทเค็นแบบเรียลไทม์
- ดูแล รายการปฏิเสธตามค่า
jtiสำหรับการเพิกถอนที่สำคัญ
POST /introspect token=...
-> { "active": true, "sub": "...", "scope": "read" }
POST /revoke token=...การบังคับใช้กลุ่มเป้าหมายและขอบเขต
โทเค็นที่ถูกต้องไม่ได้หมายความว่าจะได้รับอนุญาตให้ใช้ API ของคุณโดยอัตโนมัติ ต้องบังคับใช้เจตนาการใช้งาน
- ตรวจสอบกลุ่มเป้าหมาย เพื่อไม่ให้โทเค็นที่ออกให้บริการอื่นถูกนำกลับมาใช้กับบริการของคุณ
- บังคับใช้ ขอบเขตแยกตามปลายทาง อย่าสรุปว่าโทเค็นที่ถูกต้องให้สิทธิ์เข้าถึงได้ทั้งหมด
- ตรวจสอบผู้ออก เพื่อป้องกันโทเค็นจากผู้ออกที่ไม่น่าเชื่อถือ
วิธีนี้ช่วยหยุดการนำโทเค็นกลับมาใช้ข้ามบริการและการใช้อำนาจแทนที่ผิดบริบท
การโจมตีแบบสับเปลี่ยนและข้ามผู้ให้บริการ
เมื่อไคลเอ็นต์รองรับผู้ให้บริการข้อมูลประจำตัวหลายราย การโจมตีแบบสับเปลี่ยนอาจหลอกให้ไคลเอ็นต์ส่งรหัสหรือโทเค็นที่ออกโดยผู้ให้บริการข้อมูลประจำตัวรายหนึ่งไปยังปลายทางอื่นที่ผู้โจมตีเลือก
- ไคลเอ็นต์จะจำไม่ได้ว่าการตอบกลับมาจาก AS รายใด
- การป้องกันคือผูกการตอบกลับเข้ากับผู้ออกโดยใช้พารามิเตอร์
iss(RFC 9207) และตรวจสอบstateแยกตามผู้ให้บริการ
/authorize ... &state=<provider-bound>
callback must include &iss=<expected-AS>
client verifies iss matches the AS it started withการจัดเก็บและการส่งผ่านอย่างปลอดภัย
สถานที่และวิธีจัดเก็บโทเค็นเป็นตัวกำหนดระดับการเปิดเผยความเสี่ยง
- เซสชันเบราว์เซอร์: ใช้คุกกี้ httpOnly, Secure, SameSite และหลีกเลี่ยง
localStorage - อุปกรณ์เคลื่อนที่: ใช้พวงกุญแจหรือคลัง key ของ OS และอย่าใช้ไฟล์ข้อความธรรมดา
- เซิร์ฟเวอร์: ใช้ตัวจัดการข้อมูลลับ เข้ารหัสข้อมูลขณะจัดเก็บ และกำหนดสิทธิ์เท่าที่จำเป็น
- ใช้ TLS ระหว่างการส่งข้อมูลเสมอ และอย่าฝังโทเค็นไว้ในสตริงคำค้น
รายการตรวจสอบการเสริมความแข็งแกร่งของโทเค็น
รวมมาตรการควบคุมต่าง ๆ ให้เป็นพื้นฐานการปฏิบัติงาน
- กำหนดอัลกอริทึมไว้ตายตัว ปฏิเสธ
alg: noneและการโจมตีแบบสับสน - ตรวจสอบ ผู้ออก กลุ่มเป้าหมาย วันหมดอายุ ลายเซ็น ค่าใช้ครั้งเดียว/สถานะ
- กำหนดอายุโทเค็นเข้าถึงให้สั้น พร้อมการหมุนโทเค็นรีเฟรชและการตรวจจับการนำกลับมาใช้ซ้ำ
- ควรใช้โทเค็นที่ผูกกับผู้ส่ง (ดีพีโอพี/mTLS) สำหรับ API ที่มีมูลค่าสูง
- รองรับการเพิกถอนและการตรวจสอบสถานะ
- จัดเก็บอย่างปลอดภัย และไม่ใส่โทเค็นไว้ในที่อยู่เว็บหรือบันทึกการทำงาน
Hardening baseline:
[ ] alg pinned, none rejected
[ ] iss/aud/exp/sig/nonce validated
[ ] short TTL + RT rotation + reuse detection
[ ] DPoP/mTLS for sensitive scopes
[ ] revoke + introspect availableตรวจสอบอย่างรวดเร็ว: การทำให้โทเค็นที่ถูกขโมยหมดผล
เลือกมาตรการควบคุมที่จำกัดความเสียหายจากการขโมยโทเค็นได้ดีที่สุด
ทบทวน: การโจมตีโทเค็นและการเสริมความแข็งแกร่ง
ประเด็นสำคัญที่ควรจำมีดังนี้
- โทเค็นคือข้อมูลรับรอง การขโมยจึงเท่ากับการยึดบัญชี
- ป้องกัน JWT ด้วยการ กำหนดอัลกอริทึมไว้ตายตัว และตรวจสอบ ผู้ออก กลุ่มเป้าหมาย วันหมดอายุ ลายเซ็น และค่าใช้ครั้งเดียว
- จำกัดการเปิดเผยความเสี่ยงด้วย อายุการใช้งานสั้น และ การหมุนโทเค็นรีเฟรชพร้อมตรวจจับการนำกลับมาใช้ซ้ำ
- โทเค็นที่ผูกกับผู้ส่ง (ดีพีโอพี/mTLS) ทำให้โทเค็นแบบผู้ถือที่ถูกขโมยหมดผล
- จัดให้มี การเพิกถอนและการตรวจสอบสถานะ และไม่นำโทเค็นไปไว้ในที่อยู่เว็บ บันทึกการทำงาน หรือ localStorage
คำถามที่พบบ่อย
บทเรียน “การโจมตีโทเค็นและการเสริมความแข็งแกร่ง” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “การโจมตีโทเค็นและการเสริมความแข็งแกร่ง” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cyber Security Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cyber Security Academy มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “การโจมตีโทเค็นและการเสริมความแข็งแกร่ง”
ป้องกันโฟลว์การยืนยันตัวตนจากการนำไปใช้ในทางที่ผิด คุณปฏิบัติ Cyber Security Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cyber Security Academy หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Cyber Security Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน
บทเรียน “การโจมตีโทเค็นและการเสริมความแข็งแกร่ง” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Cyber Security Academy นี้ได้ไหม
ได้ บทเรียน Cyber Security Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- โฟลว์ OAuth 2.0
- OpenID Connect (OIDC)
- SAML และการรวมศูนย์ข้อมูลประจำตัว
- การโจมตีโทเค็นและการเสริมความแข็งแกร่ง