เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ · ตัวถอดรหัส JWT
วิธีถอดรหัส JWT เพย์โหลดด้วยมือด้วย base64 และ jq
· มันทำงานอย่างไร
jwt บรรทัดคำสั่ง นักพัฒนาเวิร์กโฟลว์
ในกล่องที่ไม่มีหัว คุณยังคงสามารถอ่านโทเค็นที่มี cut, tr, base64 และ jq ได้ โพสต์นี้ให้คำสั่ง อธิบายการแปลง base64url ที่แต่ละรายการทำ และแสดงรายการข้อผิดพลาด
การอ่านโทเค็นบน SSH — เมื่อเบราว์เซอร์ไม่ใช่ตัวเลือก
เซิร์ฟเวอร์ที่ไม่มีส่วนหัวอาจทำให้คุณมีสตริงรูปโทเค็นและไม่มี UI ของเบราว์เซอร์ งานตรวจสอบที่จำเป็นยังคงมีขนาดเล็ก: แยกหนึ่งส่วน แปลการสะกด URL ของ base64 คืนค่าช่องว่างภายใน ถอดรหัสไบต์ และแยกวิเคราะห์ JSON อันตรายเกิดขึ้นได้จากการปฏิบัติการมากกว่าการคำนวณ เนื่องจากประวัติเชลล์สามารถรักษาข้อมูลประจำตัวที่มีอยู่ได้
ใช้โทเค็นที่หมดอายุหรือโทเค็นสังเคราะห์ทุกครั้งที่เป็นไปได้ หากการตอบสนองต่อเหตุการณ์จำเป็นต้องตรวจสอบมูลค่าที่แท้จริง ให้ปฏิบัติตามการควบคุมการจัดการข้อมูลรับรองขององค์กรของคุณ ป้องกันไม่ให้เข้าสู่ประวัติหรือบันทึกที่แชร์ และหมุนเวียนหลังจากเปิดเผย การถอดรหัสบรรทัดคำสั่งยังคงตรวจสอบเท่านั้น ไม่มีรหัสยืนยันหรือนโยบายความน่าเชื่อถือ
การแยกจุด — ตัดหรือ awk เพื่อแยกส่วนของเพย์โหลด
JWS รูปทรงกะทัดรัด JWT มีฟิลด์ที่คั่นด้วยจุดสามช่อง เพย์โหลดเป็นครั้งที่สอง เชลล์สามารถแยกมันด้วยเครื่องมือที่รับรู้ถึงตัวคั่น แต่อ้างอิงตัวแปรเพื่อให้เชลล์ไม่ขยายอักขระหรือแยกช่องว่าง ลบป้ายกำกับ `Bearer ` นำหน้าออกก่อนที่จะเลือกฟิลด์ เนื่องจากคำนำหน้านั้นเป็นของไวยากรณ์ HTTP
นับฟิลด์แทนที่จะสุ่มสี่สุ่มห้าในฟิลด์ที่สอง ToolAcre ปฏิเสธสิ่งอื่นใดนอกเหนือจากสามส่วนและระบุอินพุตที่เข้ารหัสห้าส่วนแยกกัน ไปป์ไลน์เชลล์ควรใช้ความระมัดระวังด้านโครงสร้างแบบเดียวกัน การรับเซ็กเมนต์จากอินพุตที่มีรูปแบบไม่ถูกต้องสามารถสร้าง JSON ที่น่าเชื่อถือได้ในขณะที่ปกปิดว่าโทเค็นดั้งเดิมถูกตัดทอน
การแปลงตัวอักษร — tr เพื่อเปลี่ยนยัติภังค์และขีดเส้นใต้กลับเป็นเครื่องหมายบวกและเครื่องหมายทับ
การใช้งาน Base64 ของบรรทัดคำสั่งมาตรฐานมักคาดหวังเครื่องหมายบวกและเครื่องหมายทับ โดยที่เซ็กเมนต์ JWT อาจมียัติภังค์และขีดล่าง การแปล `-` เป็น `+` และ `_` เป็น `/` จะจับคู่สัญลักษณ์ URL-safe กลับไปยังตำแหน่งมาตรฐาน โดยไม่ต้องเปลี่ยนค่าหกบิตที่แสดง
ใช้คำสั่งการแปลซึ่งการแยกวิเคราะห์ตัวเลือกจะต้องไม่เข้าใจผิดว่ายัติภังค์นำหน้าเป็นแฟล็ก และเก็บข้อมูลไว้ในตัวแปรที่ยกมาหรืออินพุตมาตรฐาน การแปลงตัวอักษรเป็นงานการเข้ารหัสแบบย้อนกลับได้ ไม่ได้ถอดรหัสการอ้างสิทธิ์ และความสำเร็จไม่ได้พิสูจน์ว่าโทเค็นมาจากผู้ออกที่ระบุชื่อ
การคืนค่าช่องว่างภายใน — เลขคณิตที่บวกจำนวนเครื่องหมายเท่ากับที่ถูกต้อง
หลังจากแปลแล้ว ให้คำนวณความยาวแบบโมดูโลสี่ เลขศูนย์ที่เหลือไม่จำเป็นต้องมีเครื่องหมายเท่ากับ สองตัวที่เหลือต้องมีสอง และที่เหลือสามต้องมีเครื่องหมายหนึ่ง ส่วนที่เหลือบ่งบอกถึงการตัดทอนและควรหยุดไปป์ไลน์ การต่อเติมช่องว่างภายในโดยพลการจนกว่ายูทิลิตี้จะหยุดบ่นสามารถซ่อนความเสียหายแทนที่จะวินิจฉัยได้
ToolAcre ใช้กฎความยาวนี้ทุกประการใน `base64ToBytes` และปฏิเสธเศษที่เป็นไปไม่ได้ ยูทิลิตี้เชลล์จะแตกต่างกันไปขึ้นอยู่กับว่ายอมรับการเว้นช่องว่างหรือไม่ ดังนั้นการทำให้อินพุตเป็นมาตรฐานก่อนจะทำให้ไปป์ไลน์ชัดเจนและพกพาได้ในแนวคิด แม้ว่าแฟล็กคำสั่งจะยังคงแตกต่างกันระหว่างระบบปฏิบัติการก็ตาม
การถอดรหัสและการพิมพ์แบบสวย - base64 -d ไพพ์ลงใน jq
ไพพ์ค่าเบาะไปยังตัวถอดรหัส Base64 ของแพลตฟอร์ม จากนั้นไปที่ `jq` คำสั่งแรกกู้คืนไบต์ ส่วนที่สองต้องการไบต์เหล่านั้นเพื่อสร้าง JSON คำสั่ง Base64 ที่ประสบความสำเร็จตามด้วยข้อผิดพลาดในการแยกวิเคราะห์ jq หมายความว่าการเข้ารหัสสามารถถอดรหัสได้ในเชิงโครงสร้าง แต่เนื้อหาไม่ใช่เพย์โหลด JSON
ความแตกต่างดังกล่าวสะท้อนเส้นทางข้อผิดพลาดของ ToolAcre ขั้นแรกจะรายงาน base64url หรือ UTF-8 ที่ไม่ถูกต้อง จากนั้นแยกรายงาน JSON ที่ไม่ถูกต้อง จากนั้นปฏิเสธค่าว่าง อาร์เรย์ และค่าพื้นฐาน เนื่องจากส่วนหัว JWT หรือเพย์โหลดจะต้องเป็นออบเจ็กต์สำหรับเครื่องมือนี้ การแยกขั้นตอนออกจากกันทำให้สามารถดำเนินการล้มเหลวได้
ตัวอย่างการทำงาน — ไปป์ไลน์แบบเต็มบนโทเค็นตัวอย่าง โดยมีเอาต์พุตในแต่ละขั้นตอน
สำหรับตัวอย่างสังเคราะห์ ส่วนเพย์โหลด `eyJzdWIiOiJkZW1vIiwicm9sZSI6InJlYWRlciJ9` ไม่จำเป็นต้องแปลตัวอักษรหรือเติมช่องว่าง การถอดรหัสให้ผล `{"sub":"demo","role":"reader"}` และรูปแบบ jq ที่ข้ามบรรทัด บทบาทที่มองเห็นได้เป็นเพียงสตริงที่จัดทำโดยโทเค็น
ตอนนี้แก้ไข JSON เข้ารหัสอีกครั้งและแนบส่วนที่สาม ไปป์ไลน์ยังคงพิมพ์วัตถุที่เปลี่ยนแปลง นี่เป็นการพิสูจน์ว่าเหตุใดคำสั่งถอดรหัสจึงไม่สามารถใช้เป็นการตรวจสอบความถูกต้องได้: ทั้งการอ้างสิทธิ์ที่ถูกต้องและที่ประดิษฐ์ขึ้นจะข้ามการแปลงสาธารณะเดียวกัน เว้นแต่ผู้ตรวจสอบที่แยกต่างหากจะตรวจสอบลายเซ็น
ข้อผิดพลาด — ประวัติเชลล์ที่ดักจับโทเค็น การใช้งาน base64 ที่ปฏิเสธการเติมที่ขาดหายไป และโทเค็นที่มี 'ผู้ถือ' ชั้นนำ
ความล้มเหลวทั่วไป ได้แก่ การคงคำนำหน้า HTTP ไว้ การเลือกช่องที่คั่นด้วยจุดผิด การสูญเสียอักขระต่อท้ายระหว่างการคัดลอก และการใช้ Base64 ที่ต้องมีช่องว่างภายใน ข้อผิดพลาดอีกประการหนึ่งคือการวางโทเค็นทั้งหมดโดยตรงบนบรรทัดคำสั่ง ซึ่งรายการกระบวนการหรือประวัติอาจยังคงอยู่
ต้องการอินพุตมาตรฐานและตัวแปรชั่วคราวภายใต้การควบคุมที่เหมาะสม และอย่าวางโทเค็นที่ใช้งานจริงลงในแชท ตั๋ว หรือเทอร์มินัลที่ใช้ร่วมกันเพื่อความสะดวก นอกจากนี้ โปรดจำไว้ว่าส่วนที่สามเป็นเนื้อหาลายเซ็นไบนารีมากกว่า JSON ดังนั้นการส่งผ่าน jq ไม่น่าจะล้มเหลวและไม่แจ้งให้คุณทราบเกี่ยวกับความถูกต้องของลายเซ็น
ประเด็นสำคัญ: การถอดรหัสเดียวกัน ทุกสภาพแวดล้อม — เมื่อคุณมีเบราว์เซอร์ ตัวถอดรหัส ToolAcre JWT จะทำสิ่งนี้ในเครื่องโดยไม่มีการอัปโหลดใดๆ
ไปป์ไลน์เชลล์และ ToolAcre ดำเนินการลำดับการถอดรหัสเท่านั้นที่เหมือนกันในสภาพแวดล้อมที่แตกต่างกัน: แยก, ทำให้เป็นมาตรฐาน, แพด, ถอดรหัส UTF-8 และแยกวิเคราะห์ JSON ใช้สภาพแวดล้อมใดก็ตามที่คุณสามารถตรวจสอบและควบคุมได้ โดยมีข้อมูลที่ไม่ละเอียดอ่อนเป็นค่าเริ่มต้น
ไม่มีเส้นทางใดที่จะตรวจสอบความถูกต้องหรือให้สิทธิ์ผู้โทร หลังจากอ่านรูปแบบเพย์โหลดแล้ว ให้ย้ายไปยังตัวตรวจสอบที่เชื่อถือได้ของบริการและบันทึกสำหรับการตัดสินใจเกี่ยวกับการเข้ารหัสและนโยบาย คำสั่งที่สร้าง JSON สวยได้เสร็จสิ้นงานการจัดรูปแบบแล้ว ไม่ใช่การพิจารณาด้านความปลอดภัย