เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ · ตัวถอดรหัส JWT
Base64 กับ Base64url: เหตุใด JWT ล้มเหลวในตัวถอดรหัส Base64 มาตรฐาน
· มันทำงานอย่างไร
jwt base64 การเข้ารหัส
วางส่วน JWT ลงในตัวถอดรหัส base64 ธรรมดา และอาจทำให้มีปัญหาเกี่ยวกับอักขระหรือช่องว่างภายใน โพสต์นี้จะอธิบายคำสั่งตัวแปร base64url JWS และวิธีการแปลงระหว่างทั้งสอง
อักขระไม่ถูกต้อง ช่องว่างภายในไม่ถูกต้อง — ข้อผิดพลาดที่ปรากฏขึ้นเมื่อ base64 ตรงกับ base64url
ข้อความ "อักขระที่ไม่ถูกต้อง" หรือ "ช่องว่างภายในที่ไม่ถูกต้อง" มักหมายความว่ามีการกำหนดเซ็กเมนต์ JWT ให้กับตัวถอดรหัสที่คาดว่าจะใช้ Base64 แบบธรรมดา โทเค็นอาจถูกคัดลอกอย่างถูกต้อง การแสดงเป็นไปตามแบบแผน base64url ในขณะที่ยูทิลิตีการรับยอมรับตัวอักษรที่เกี่ยวข้องแต่ไม่เหมือนกันหรือยืนยันในการเติมช่องว่างอย่างชัดเจน
ToolAcre หลีกเลี่ยงความไม่ตรงกันสำหรับส่วนหัวและเพย์โหลด ตัวถอดรหัสไบต์จะลบช่องว่าง แปลสัญลักษณ์ URL-safe คืนค่าช่องว่างที่ละเว้นเมื่อความยาวอนุญาต จากนั้นแปลงไบต์เป็น UTF-8 แบบเข้มงวด ความล้มเหลวในขั้นตอนใดๆ จะกลายเป็นข้อผิดพลาด INVALID_JWT แทนที่จะเป็นข้อยกเว้นดิบของเบราว์เซอร์
ตัวอักษรสองตัว — เครื่องหมายบวกและเครื่องหมายทับเทียบกับเครื่องหมายยัติภังค์และเครื่องหมายขีดล่าง และสาเหตุที่ URL บังคับให้ทำการเปลี่ยนแปลง
Standard Base64 ใช้เครื่องหมายบวกและเครื่องหมายทับสำหรับตำแหน่งตัวอักษรสองตัวสุดท้าย Base64url กำหนดยัติภังค์และขีดล่างให้กับตำแหน่งเดียวกันเหล่านั้น ค่าหกบิตพื้นฐานจะไม่เปลี่ยนแปลง ดังนั้นการแปล `-` เป็น `+` และ `_` เป็น `/` จะรักษาทุกไบต์ที่ถอดรหัสไว้ เฉพาะการเปลี่ยนแปลงการสะกดที่ปลอดภัยสำหรับการขนส่งเท่านั้น
การทดแทนเหล่านั้นมีความสำคัญในช่องที่เครื่องหมายบวกหรือเครื่องหมายทับมีไวยากรณ์อยู่แล้ว การสะกดแบบปลอดภัย URL ช่วยลดการตีความโดยไม่ตั้งใจโดยการประมวลผลแบบฟอร์มหรือเส้นทาง มันไม่ได้เพิ่มความลับ ความสมบูรณ์ หรือความถูกต้อง ใครก็ตามที่ได้รับเซ็กเมนต์สามารถย้อนกลับการทดแทนและกู้คืนไบต์เดียวกันได้โดยไม่ต้องใช้คีย์เข้ารหัส
การแพดดิ้ง — เหตุใด JWS จึงตัดเครื่องหมายเท่ากับ และวิธีคืนค่าเครื่องหมายเหล่านั้นสำหรับตัวถอดรหัสที่เข้มงวด
ToolAcre ยอมรับการเว้นวรรคที่ละเว้น หลังจากทำให้ตัวอักษรเป็นมาตรฐานแล้ว จะตรวจสอบความยาวเซ็กเมนต์แบบโมดูโล 4 ส่วนที่เหลือของสองต้องมีสองเครื่องหมายเท่ากับ และส่วนที่เหลือของสามต้องมีหนึ่ง ส่วนที่เหลือเป็นไปไม่ได้สำหรับค่า Base64 ที่สมบูรณ์ และจะถูกปฏิเสธเนื่องจากเป็นสตริงที่ถูกตัดทอน แทนที่จะเดาเป็นรูปร่าง
การกู้คืนการบุนวมเป็นการวางเฟรมแบบกลไก ไม่ใช่การซ่อมแซมโทเค็น การเพิ่มเครื่องหมายเท่ากับไม่สามารถกู้คืนอักขระที่หายไประหว่างการคัดลอก และการถอดรหัสไบต์ที่สำเร็จไม่ได้แสดงว่าไบต์นั้นมาจากผู้ออก การใช้งานเพียงสร้างความยาวตามรูปแบบบัญญัติที่ตัวถอดรหัสเบราว์เซอร์ต้องการก่อนที่จะเรียก `atob`
ถอดรหัสโทเค็นทั้งหมดพร้อมกัน — ความผิดพลาดที่ไม่แยกจุดก่อน
โทเค็นที่มีลายเซ็นขนาดเล็กจะต้องแยกออกตามจุดก่อนที่จะถอดรหัสส่วนใดๆ การส่ง `header.payload.signature` ไปยังฟังก์ชัน Base64 จะแนะนำจุดที่เป็นของ JWT การทำให้เป็นอนุกรม ไม่ใช่ตัวอักษร Base64 ตัวใดตัวหนึ่ง ToolAcre ต้องการสามส่วนพอดีสำหรับอินพุตรูปทรง JWS นี้ และรายงานจำนวนที่สังเกตได้เมื่อไม่มีโครงสร้างนั้น
กรณีห้าส่วนได้รับข้อความ JWE แยกต่างหาก เนื่องจากการทำให้ซีเรียลไลซ์แบบกระชับที่เข้ารหัสไม่ใช่อ็อบเจ็กต์เดียวกัน สองหรือสี่ส่วนแนะนำให้ตัดทอนหรือป้อนข้อมูลผิดแทน การตรวจสอบโครงสร้างนี้มาก่อนการตีความ JSON ทำให้ข้อผิดพลาดในการคัดลอกแตกต่างจากข้อความที่เข้ารหัสที่มีรูปแบบไม่ถูกต้องหรือ JSON ที่มีรูปแบบไม่ถูกต้อง
ตัวอย่างการทำงาน — การแปลงหนึ่งเซ็กเมนต์จาก base64url เป็น base64 เติมและถอดรหัสเป็น JSON
สำหรับการแปลงที่ได้ผล ให้ใช้ `eyJhbGciOiJIUzI1NiJ9` ไม่มีอักขระตัวอักษรที่แตกต่างกันระหว่างตัวแปรต่างๆ แต่ช่องว่างภายในที่ขาดหายไปยังคงแสดงให้เห็นไปป์ไลน์ ความยาวของมันช่วยให้สามารถฟื้นฟูช่องว่างภายในได้ การถอดรหัสให้ผล UTF-8 ไบต์สำหรับ `{"alg":"HS256"}` และการแยกวิเคราะห์ JSON จะสร้างวัตถุที่มีคุณสมบัติ `alg` หนึ่งรายการ
ส่วนที่มียัติภังค์หรือขีดล่างจะเรียงตามลำดับเดียวกันโดยเปลี่ยนสัญลักษณ์สองตัวก่อน ToolAcre ดำเนินการเหล่านี้ภายใน `base64ToBytes` จากนั้น `decodeSegment` แยกวิเคราะห์ข้อความผลลัพธ์ อัลกอริธึมที่แสดงคือสิ่งที่ส่วนหัวที่ไม่ได้รับการยืนยันประกาศ ไม่ได้ถูกเลือกให้เป็นนโยบายการตรวจสอบ
Unicode ในการอ้างสิทธิ์ - เหตุใดไบต์ที่ถอดรหัสจึงต้องอ่านเป็น UTF-8 เพื่อแสดงชื่ออย่างถูกต้อง
การอ้างสิทธิ์อาจมีสำเนียง อักขระ CJK ตัว หรืออีโมจิ Base64 ทำงานบนไบต์ ดังนั้นการประมวลผลแต่ละไบต์ที่ถอดรหัสเป็นอักขระอิสระจะทำให้ข้อความหลายไบต์เสียหาย เส้นทางที่ถูกต้องคือการเข้ารหัสสัญลักษณ์เป็นไบต์ จากนั้นจึงใช้ตัวถอดรหัส UTF-8 ToolAcre สร้าง `TextDecoder` ด้วยโหมดร้ายแรง ดังนั้น UTF-8 ที่ไม่ถูกต้องจึงล้มเหลวอย่างดัง
การทดสอบครอบคลุมเพย์โหลดที่มี `Zoë 世界 🙂` และคาดหวังสตริงที่แน่นอนหลังจากการถอดรหัส ผลลัพธ์ดังกล่าวพิสูจน์ว่าไปป์ไลน์แบบไบต์เป็นข้อความรักษาค่าทดสอบนี้ไว้ ยังไม่ได้บอกว่ามีบุคคลที่ระบุชื่อตาม payload อยู่หรือไม่ ไม่ว่าผู้ออกจะอนุมัติการอ้างสิทธิ์หรือมีการเปลี่ยนแปลงโทเค็นหรือไม่
สิ่งนี้ไม่ครอบคลุมถึง - ส่วนลายเซ็นซึ่งถอดรหัสเป็นไบต์แทนที่จะเป็นข้อความและต้องใช้คีย์เพื่อสื่อความหมาย
ส่วนลายเซ็นอยู่นอกเส้นทาง JSON ToolAcre เก็บรูปแบบการเข้ารหัสดั้งเดิมและพยายามวัดความยาวไบต์ที่ถอดรหัสเท่านั้น Base64 ลายเซ็นที่ไม่ถูกต้องจะสร้างคำเตือนแต่ไม่ได้ป้องกันการตรวจสอบส่วนหัวและเพย์โหลด ส่วนที่สามที่ว่างเปล่าจะสร้างคำเตือนที่แตกต่างออกไปว่าไม่มีไบต์ลายเซ็นอยู่
ผลลัพธ์ทั้งสองไม่ใช่ผลการตรวจสอบ การตรวจสอบลายเซ็นที่มีความหมายจำเป็นต้องมีเนื้อหาหลักที่เชื่อถือได้ อัลกอริธึมที่ได้รับอนุญาตซึ่งเลือกโดยอิสระจากอินพุตที่ผู้โจมตีควบคุม และการตรวจสอบแอปพลิเคชัน จำนวนไบต์มีประโยชน์เมื่อวิเคราะห์รูปร่าง แต่ไบต์ที่วัดได้เป็นศูนย์หรือสามสิบสองไบต์ไม่สามารถอนุญาตคำขอหรือสร้างผู้ออกได้
ประเด็นสำคัญ: ใช้ตัวถอดรหัสที่พูด base64url — ตัวถอดรหัส ToolAcre JWT จัดการตัวอักษรและช่องว่างภายในสำหรับส่วนหัวและเพย์โหลด
ใช้ตัวถอดรหัสที่เข้าใจ base64url เมื่องานเร่งด่วนกำลังตรวจสอบ JSON ToolAcre จัดการตัวอักษร ละเว้นช่องว่างภายใน UTF-8 แบบเข้มงวด และเฉพาะออบเจ็กต์ JSON สำหรับสองส่วนแรก นอกจากนี้ยังปฏิเสธความยาวที่เป็นไปไม่ได้และล้อมความล้มเหลวในการแยกวิเคราะห์ในข้อความที่ระบุว่าส่วนหัวหรือเพย์โหลดล้มเหลว
หยุดที่ขอบเขตนั้น การถอดรหัสที่ชัดเจนหมายความว่าสตริงมีไบต์ที่สามารถกู้คืนได้และอ็อบเจ็กต์ JSON ที่เหมาะสม ไม่ได้หมายความว่าการกล่าวอ้างมีความน่าเชื่อถือ มีการรับรองความถูกต้อง ได้รับอนุญาต หรือไม่ได้รับการแก้ไข มีเพียงผู้ตรวจสอบที่กำหนดค่าแยกต่างหากเท่านั้นที่สามารถตอบคำถามเหล่านั้นได้ และเครื่องมือเบราว์เซอร์นี้จงใจไม่เปิดเผยการดำเนินการตรวจสอบ