ไทย

เครื่องมือสำหรับนักพัฒนา · ตัวแปลงการประทับเวลา Unix

เหตุใด JWT ของคุณจึงหมดอายุทันที: exp มีหน่วยเป็นวินาที ไม่ใช่มิลลิวินาที

· เหตุใดจึงสำคัญ

jwt การประทับเวลา ความปลอดภัย

นาฬิกาเพย์โหลด JWT สอดคล้องกับไม้บรรทัดยุควินาที
ภาพประกอบเวกเตอร์ต้นฉบับ ToolAcre

RFC 7519 กำหนด exp, iat และ nbf เป็นวินาทีนับตั้งแต่ยุค และการผสมสิ่งนั้นกับนาฬิกามิลลิวินาทีจะทำให้โทเค็นหมดอายุทันทีหรือไม่เลย โพสต์นี้จะอธิบายรูปแบบการอ้างสิทธิ์และวิธีการตรวจสอบเวลาของโทเค็น

ออกเมื่อ 10:00 หมดอายุเมื่อ 10:00 — โทเค็นถูกปฏิเสธในการใช้งานครั้งแรกและนาฬิกาเซิร์ฟเวอร์ที่ไม่ใช่ปัญหา

โทเค็นที่ถูกปฏิเสธในคำขอครั้งแรกทำให้เกิดข้อสงสัยว่าเซิร์ฟเวอร์บิดเบือน แต่ให้ตรวจสอบการอ้างสิทธิ์ดิบก่อนที่จะเปลี่ยนนาฬิกา หากองค์ประกอบหนึ่งสร้าง `exp` จากนาฬิกามิลลิวินาที ในขณะที่อีกองค์ประกอบหนึ่งเปรียบเทียบวินาที NumericDate ค่าจะแตกต่างกันตามขนาดสามลำดับ ไม่มีการปรับการซิงโครไนซ์แบบธรรมดาที่จะอธิบายช่องว่างนั้น

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

สิ่งที่ RFC 7519 พูด — NumericDate เป็นวินาทีตั้งแต่ 1970-01-01T00:00:00Z และเหตุใดจึงเป็นตัวเลขแทนที่จะเป็นสตริง

บทความ JWT ที่เผยแพร่ที่อยู่ติดกันระบุสัญญาที่สำคัญไว้แล้ว: `exp` NumericDate นับวินาทีจากยุค Unix การทำซ้ำคำอธิบายมาตรฐานจะไม่เพิ่มคุณค่าที่นี่ คำถามเชิงปฏิบัติก็คือ ผู้ผลิต เครื่องซีเรียลไลเซอร์ เครื่องตรวจสอบ และฟิกซ์เจอร์ทดสอบแต่ละรายให้เกียรติในระดับเดียวกันหรือไม่

มองหารหัสขอบเขตที่ชัดเจน: นาฬิกามิลลิวินาทีแบ่งออกเป็นวินาทีเมื่อออก และการเปรียบเทียบวินาทีเมื่อตรวจสอบ การอ้างสิทธิ์ควรยังคงเป็นตัวเลขแทนที่จะเป็นวันที่ที่มีการจัดรูปแบบซึ่งใช้สำหรับเลขคณิต UTC ที่มนุษย์สามารถอ่านได้เป็นการฉายภาพเพื่อการวินิจฉัย ไม่ใช่การแสดงที่เชื่อถือได้ของโทเค็น

ปักหมุดสัญญานี้ในการทดสอบของผู้ออกและผู้ตรวจสอบด้วยค่าที่ไม่ใช่ศูนย์ การทดสอบโดยใช้ศูนย์ยุคไม่สามารถบอกได้ว่าด้านใดหารหรือคูณด้วยหนึ่งพัน

บทความ JWT ที่มีอยู่กำหนด NumericDate วินาที; บทความนี้ใช้ข้อเท็จจริงดังกล่าวกับการดีบักที่หมดอายุ

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

หลีกเลี่ยงการ "แก้ไข" ที่ยอมรับทั้งสองรูปแบบโดยพิจารณาจากจำนวนหลัก ซึ่งเปลี่ยนโทเค็นที่มีรูปแบบไม่ถูกต้องให้เป็นโปรโตคอลสำรองถาวรและสามารถซ่อนการถดถอยของผู้ออกได้ ปฏิเสธค่าที่ละเมิดสัญญา NumericDate ของแอปพลิเคชัน การสร้างที่ถูกต้อง และเพิ่มตัวติดตั้งที่แยกวินาทีจากมิลลิวินาที

ข้อผิดพลาดในระดับมิลลิวินาทีสามารถสร้างการปฏิเสธได้ทันทีหรือการหมดอายุระยะไกลอย่างไม่น่าเชื่อ ขึ้นอยู่กับว่าฝ่ายใดผิด

ถอดรหัสเพย์โหลดเพื่อแสดง `exp`, `iat` และ `nbf` เป็นค่าดิบก่อนที่เฟรมเวิร์กจะแปลงค่าเหล่านั้น เปรียบเทียบ `exp − iat` กับอายุการใช้งานโทเค็นที่ต้องการในหน่วยวินาที ตรวจสอบ `nbf` แยกกัน โทเค็นสามารถยังไม่หมดอายุแต่ยังใช้ไม่ได้ อย่าอนุมานความถูกต้องจากเวลาที่ดูสมเหตุสมผล

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

ตัวอย่างการทำงาน: exp ของ 1700003600 — แปลงเป็น UTC และเวลาท้องถิ่น ตรวจสอบกับ iat และยืนยันอายุการใช้งานเป็นสิ่งที่คุณตั้งใจไว้

สำหรับ `iat = 1,700,000,000` และ `exp = 1,700,003,600` การลบจะให้ผล 3,600 วินาทีหรือหนึ่งชั่วโมง ตัวแปลงอ่านการหมดอายุอย่างชัดเจนเป็นวินาทีและส่งกลับ `2023-11-14T23:13:20.000Z`; เวลาออกคือ `2023-11-14T22:13:20.000Z`

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

ความแตกต่างหนึ่งชั่วโมงจะถูกคำนวณก่อนการจัดรูปแบบ ดังนั้นจึงเหลือหนึ่งชั่วโมงในทุกโซน จอแสดงผลในเครื่องอาจแตกต่างกัน แต่ `exp − iat` ไม่เป็นเช่นนั้น

ตัวอย่างการทำงาน: เปรียบเทียบ exp 1,700,003,600 กับ iat ใกล้เคียงโดยใช้วินาทีที่ชัดเจน

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

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

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

ค่าเผื่อไม่สามารถซ่อมแซมปัจจัยของ 1,000 ที่ไม่ตรงกันได้

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

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

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

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

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

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

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