ช่องโหว่ JWT: alg=none และความสับสนของคีย์

JWT ลงลายเซ็นด้วยวิทยาการเข้ารหัส แต่ไลบรารีจำนวนมากเคยมีช่องโหว่ร้ายแรง ช่องโหว่ที่ถูกใช้โจมตีมากที่สุด ได้แก่ การโจมตี alg=none การโจมตีแบบสับสนระหว่าง RS256→HS256 และการเดาคีย์ลับที่อ่อนแอ ทั้งหมดเกิดจากการเชื่อถือฟิลด์ในส่วนหัวที่ผู้โจมตีควบคุมได้

ข้อกำหนด JWT อนุญาตให้ใช้ alg:"none" สำหรับโทเค็นที่ไม่มีการรักษาความปลอดภัย ไลบรารีที่มีข้อบกพร่องยอมรับค่านี้และข้ามการตรวจสอบลายเซ็นทั้งหมด ผู้โจมตีแก้ไขเพย์โหลด (เช่น "role":"admin") ตั้งค่า alg:"none" ลบลายเซ็นออก แล้วเซิร์ฟเวอร์ยอมรับโทเค็นดังกล่าว

ต้นฉบับ: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyIn0.SIG การโจมตี: eyJhbGciOiJub25lIn0.eyJzdWIiOiJhZG1pbiJ9. (ลายเซ็นว่าง มีจุดปิดท้าย) เซิร์ฟเวอร์ที่มีช่องโหว่ตรวจสอบผ่านสำเร็จและมอบสิทธิ์เข้าถึงระดับผู้ดูแลระบบ

อย่ายอมรับ alg:"none" ในระบบจริง กำหนดรายการอัลกอริทึมที่อนุญาตไว้อย่างชัดเจน: jwt.decode(token, key, algorithms=["HS256"]) ไลบรารีสมัยใหม่ส่วนใหญ่ (PyJWT 2+, jsonwebtoken 9+) ปฏิเสธ alg=none เป็นค่าเริ่มต้น

หากเซิร์ฟเวอร์ใช้ RS256 แล้วไคลเอนต์เปลี่ยน alg เป็น HS256 เซิร์ฟเวอร์อาจใช้กุญแจสาธารณะ RSA ของตนเป็นคีย์ลับ HMAC เนื่องจากกุญแจสาธารณะนั้น... เป็นกุญแจสาธารณะ ผู้โจมตีจึงลงลายเซ็นเพย์โหลดใด ๆ ด้วยกุญแจดังกล่าว แล้วเซิร์ฟเวอร์ก็ตรวจสอบผ่าน

ขั้นตอน: 1) ดึงกุญแจสาธารณะจากปลายทาง JWKS 2) สร้างเพย์โหลดที่เป็นอันตราย 3) ลงลายเซ็นด้วย HMAC-SHA256 โดยใช้ไบต์ PEM ดิบของกุญแจสาธารณะเป็นคีย์ลับ HMAC 4) ตั้งค่า alg:"HS256" ในส่วนหัว 5) เส้นทาง HS256 ของเซิร์ฟเวอร์ตรวจสอบผ่านสำเร็จ

ระบุอัลกอริทึมที่คาดหวังไว้อย่างชัดเจนเสมอในการเรียกใช้การตรวจสอบ อย่าอนุมานอัลกอริทึมจากส่วนหัวโทเค็น ใช้เส้นทางโค้ดแยกกันสำหรับ RS256 และ HS256 ซึ่งผู้เรียกใช้ไม่สามารถสลับเปลี่ยนได้

HS256 ที่ใช้คีย์ลับอ่อนแอ (มีเอนโทรปีน้อยกว่า 256 บิต) สามารถถูกเดาแบบออฟไลน์ได้ เครื่องมืออย่าง hashcat รองรับการเจาะ JWT: hashcat -a 0 -m 16500 token.txt wordlist.txt ใช้คีย์ลับที่สุ่มด้วยวิทยาการเข้ารหัสและมีขนาดอย่างน้อย 32 ไบต์

ส่วนหัว kid (รหัสกุญแจ) ใช้เลือกกุญแจที่จะนำมาใช้ หากเซิร์ฟเวอร์ใช้ kid เป็นพารามิเตอร์คำสั่ง SQL หรือเส้นทางระบบไฟล์โดยไม่ทำความสะอาดข้อมูล: kid="../../dev/null" → HMAC ที่ใช้คีย์ว่าง → ยอมรับโทเค็นปลอมแปลง ให้ตรวจสอบและทำความสะอาด kid เสมอ

ส่วนหัว jwk ฝังกุญแจสาธารณะสำหรับการตรวจสอบ เซิร์ฟเวอร์ที่มีช่องโหว่อาจใช้กุญแจที่ฝังมาโดยตรง ทำให้ผู้โจมตีส่งคู่กุญแจของตนเอง ลงลายเซ็นโทเค็นด้วยกุญแจส่วนตัว แล้วฝังกุญแจสาธารณะไว้ ให้ตรวจสอบกับกุญแจที่ลงทะเบียนไว้เท่านั้น

การนำไปใช้งานบางแบบลืมตรวจสอบข้ออ้างสิทธิ์ exp หรือใช้เวลาของเซิร์ฟเวอร์ไม่สอดคล้องกัน ให้ตรวจสอบ exp, nbf และ iat อย่างชัดเจนเสมอ ใช้ไลบรารีที่ตรวจสอบค่าเหล่านี้เป็นค่าเริ่มต้น และอย่าปิดการตรวจสอบข้ออ้างสิทธิ์ในระบบจริง

ช่องโหว่ JWT เกิดจากการเชื่อถือส่วนหัว alg การยอมรับ alg=none และการใช้คีย์ลับที่อ่อนแอ วิธีแก้: กำหนดอัลกอริทึมตายตัวที่ผู้ตรวจสอบ ใช้คีย์ลับที่รัดกุม และทำความสะอาด kid ต่อไป: แนวทางการนำ JWT ไปใช้งานอย่างปลอดภัย