เจาะลึกช่องโหว่ JWT: ความเสี่ยงที่ทำให้ใครก็กลายเป็นผู้ดูแลระบบได้

ในโลกดิจิทัลที่ขับเคลื่อนด้วยเว็บแอปพลิเคชันมากมาย การยืนยันตัวตนและการอนุญาตเป็นสิ่งสำคัญอย่างยิ่ง JSON Web Token (JWT) ได้กลายมาเป็นมาตรฐานยอดนิยมที่ใช้ในการแลกเปลี่ยนข้อมูลอย่างปลอดภัยระหว่างไคลเอนต์และเซิร์ฟเวอร์ มันเป็นเหมือนบัตรผ่านดิจิทัลที่บอกว่า “คุณคือใคร และคุณทำอะไรได้บ้าง” แต่หากบัตรผ่านนี้ถูกสร้างหรือตรวจสอบอย่างไม่รัดกุม ความปลอดภัยของระบบก็อาจตกอยู่ในอันตรายร้ายแรง

JWT ทำงานอย่างไร: กุญแจสู่การยืนยันตัวตน

ก่อนอื่น มาทำความเข้าใจโครงสร้างของ JWT กันเล็กน้อย JWT ประกอบด้วยสามส่วนหลักที่คั่นด้วยจุด:

Header (ส่วนหัว): ระบุประเภทของโทเค็น (เช่น JWT) และอัลกอริทึมการเข้ารหัสที่ใช้ในการสร้างลายเซ็น (เช่น HS256, RS256)
Payload (ส่วนข้อมูล): เก็บข้อมูลจริงที่เราต้องการส่ง เช่น ID ผู้ใช้, บทบาท, หรือข้อมูลอื่นๆ ที่จำเป็น
Signature (ลายเซ็น): ส่วนสำคัญที่สุดที่ใช้ยืนยันความถูกต้องและความสมบูรณ์ของโทเค็น ลายเซ็นถูกสร้างขึ้นจาก Header, Payload และ Secret Key ที่รู้กันเฉพาะเซิร์ฟเวอร์เท่านั้น หากข้อมูลใน Header หรือ Payload ถูกแก้ไข ลายเซ็นจะใช้ไม่ได้ทันที

ช่องโหว่ JWT ที่อาจนำไปสู่หายนะ

แม้ JWT จะออกแบบมาอย่างดี แต่การนำไปใช้งานที่ผิดพลาดเพียงเล็กน้อยก็สามารถเปิดประตูสู่ช่องโหว่ร้ายแรงได้ หนึ่งในช่องโหว่ที่พบบ่อยและอันตรายคือการ บายพาสลายเซ็น (Signature Bypass) ซึ่งหมายถึงการที่เซิร์ฟเวอร์ไม่สามารถตรวจสอบความถูกต้องของลายเซ็นได้อย่างเหมาะสม ทำให้ผู้โจมตีสามารถแก้ไขข้อมูลในโทเค็นได้อย่างอิสระโดยที่เซิร์ฟเวอร์ยังคงยอมรับโทเค็นนั้น

เจาะลึกกลไกการโจมตี: เปลี่ยนรหัสผ่านผู้ดูแลระบบได้ง่ายๆ

ลองจินตนาการถึงสถานการณ์ที่แอปพลิเคชันมีการทำงานเกี่ยวกับการเปลี่ยนรหัสผ่าน ซึ่งอาจใช้ JWT ในการยืนยันตัวตนของผู้ใช้ที่ร้องขอการเปลี่ยนรหัสผ่าน หรือใช้ JWT ในกระบวนการรีเซ็ตรหัสผ่าน

ผู้โจมตีเริ่มจากการดักจับ JWT ที่ถูกส่งมาระหว่างการใช้งานปกติ หรือในขั้นตอนการเปลี่ยนรหัสผ่านของผู้ใช้ทั่วไป หลังจากนั้นจึงทำการถอดรหัส (decode) JWT เพื่อดูข้อมูลที่อยู่ใน Payload ซึ่งมักจะประกอบด้วย ID ผู้ใช้ หรือข้อมูลระบุตัวตนอื่นๆ

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

จากนั้น สิ่งที่ควรเกิดขึ้นคือลายเซ็นควรจะไม่ถูกต้อง เพราะข้อมูลใน Payload ถูกเปลี่ยนไปแล้ว แต่ในกรณีที่เกิดช่องโหว่ เซิร์ฟเวอร์กลับ ยอมรับ JWT ที่ถูกแก้ไขนั้น อาจเป็นเพราะไม่ได้ตรวจสอบลายเซ็นเลย หรือตรวจสอบอย่างไม่สมบูรณ์ เช่น ยอมรับโทเค็นที่มีลายเซ็นว่างเปล่า หรือรับการอ้างอิงอัลกอริทึมที่ไม่ปลอดภัยจากฝั่งไคลเอนต์

เมื่อเซิร์ฟเวอร์หลงเชื่อ JWT ที่ถูกปลอมแปลง ผู้โจมตีก็สามารถดำเนินขั้นตอนการเปลี่ยนรหัสผ่านต่อไปได้ ราวกับว่าเป็นเจ้าของบัญชีนั้นจริง ๆ และผลลัพธ์คือ การเข้ายึดบัญชี (Account Takeover) โดยเฉพาะบัญชีผู้ดูแลระบบ ซึ่งอาจนำไปสู่การควบคุมระบบทั้งหมดได้

การป้องกันตนเองจากช่องโหว่ JWT

เพื่อหลีกเลี่ยงช่องโหว่อันตรายเช่นนี้ การใช้งาน JWT อย่างปลอดภัยจึงเป็นสิ่งสำคัญสูงสุด:

ตรวจสอบลายเซ็นเสมอ: เซิร์ฟเวอร์ต้อง ยืนยันลายเซ็น JWT อย่างเคร่งครัด สำหรับทุกโทเค็นที่ได้รับ หากลายเซ็นไม่ถูกต้อง โทเค็นนั้นต้องถูกปฏิเสธทันที
อย่าเชื่อ Header จากไคลเอนต์: อัลกอริทึมการเข้ารหัส (alg) ที่ระบุใน Header ควรถูกกำหนดและตรวจสอบจากฝั่งเซิร์ฟเวอร์ ไม่ใช่ปล่อยให้ไคลเอนต์เป็นผู้กำหนด
ใช้ Secret Key ที่แข็งแกร่ง: คีย์ลับ (Secret Key) ที่ใช้ในการสร้างและตรวจสอบลายเซ็นต้องมีความซับซ้อน ปลอดภัย และไม่ควรเปิดเผยสู่สาธารณะ
ระมัดระวัง Payload: ไม่ควรใส่ข้อมูลที่อ่อนไหวเกินไปใน Payload โดยไม่จำเป็น
อัปเดตไลบรารี: ใช้ไลบรารี JWT ที่เป็นปัจจุบันและได้รับการดูแลอย่างดี

ความมั่นคงปลอดภัยของเว็บแอปพลิเคชันขึ้นอยู่กับความใส่ใจในทุกรายละเอียด การทำความเข้าใจช่องโหว่และวิธีการป้องกันเป็นก้าวแรกที่สำคัญในการสร้างระบบที่แข็งแกร่งและไว้วางใจได้