เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ · ตัวถอดรหัส JWT
การตรวจสอบผู้ชมและผู้ออก: การหยุด JWT จากการเล่นซ้ำที่อื่น
· เหตุใดจึงสำคัญ
jwt การรับรองความถูกต้อง ความปลอดภัย
โทเค็นที่ออกสำหรับบริการหนึ่งสามารถนำเสนอให้กับอีกบริการหนึ่งที่ใช้ผู้ออกเดียวกันได้ โพสต์นี้จะอธิบายว่าการตรวจสอบของ aud และ iss หยุดสิ่งนั้นได้อย่างไร และวิธีอ่านการอ้างสิทธิ์ทั้งสองในโทเค็น
บริการ B ยอมรับโทเค็นที่มีไว้สำหรับบริการ A — การเล่นซ้ำข้ามบริการที่ลายเซ็นที่ถูกต้องไม่ได้ป้องกัน
ลายเซ็นสามารถใช้ได้กับโทเค็นที่ออกให้กับบริการอื่น หาก API หลายตัวเชื่อถือแพลตฟอร์มข้อมูลระบุตัวตนเดียวกันแต่เพิกเฉยต่อบริบทของผู้รับ ข้อมูลประจำตัวที่มีไว้สำหรับบริการ A อาจถูกเล่นซ้ำที่บริการ B ความสมบูรณ์ของการเข้ารหัสเพียงอย่างเดียวไม่สามารถตอบได้ว่าใครควรใช้ข้อมูลนั้น
ToolAcre สามารถเปิดเผย `iss` และ `aud` เพื่อให้นักพัฒนาซอฟต์แวร์มองเห็นความไม่ตรงกันที่ชัดเจน สตริงเหล่านั้นยังคงไม่ได้รับการยืนยันจนกว่าลายเซ็นจะสำเร็จ และเครื่องมือเบราว์เซอร์จะไม่ทำการตรวจสอบนั้น เซิร์ฟเวอร์ทรัพยากรจริงต้องบังคับใช้ทั้งความสัมพันธ์ของผู้ออกและกลุ่มเป้าหมาย
iss — การเชื่อมโยงโทเค็นกับผู้ออกที่บริการของคุณเชื่อถือ และเหตุใดการจับคู่สตริงจึงไม่เพียงพอหากไม่มีการเชื่อมโยงคีย์
`iss` ระบุเอนทิตีที่การอ้างสิทธิ์เพย์โหลดออกโทเค็น ผู้ตรวจสอบต้องการผู้ออกที่คาดหวังที่แน่นอนภายใต้การกำหนดค่าของตนเอง และต้องผูกข้อมูลประจำตัวนั้นกับความสัมพันธ์การค้นพบคีย์ที่ถูกต้อง การเปรียบเทียบข้อความโดยไม่มีการเชื่อมโยงการเข้ารหัสจะทำให้ผู้โจมตีสามารถคัดลอกสตริงที่คาดหวังได้
ตัวถอดรหัสอธิบายว่า `iss` เป็น "ใครเป็นผู้สร้างโทเค็น" แต่นั่นคือความหมายที่ลงทะเบียนไว้ ไม่ใช่การค้นพบเกี่ยวกับค่าที่วาง ข้อความของผู้ออกที่อ่านได้เป็นหลักฐานที่เป็นประโยชน์สำหรับการกำหนดค่าการแก้ไขจุดบกพร่อง ไม่สามารถเลือกแหล่งคีย์ที่กำหนดเองหรือรับรองความถูกต้องได้
aud — สตริงหรืออาร์เรย์ที่ตั้งชื่อผู้รับที่ต้องการ และกฎที่ผู้ตรวจสอบต้องพบในนั้น
`aud` ตั้งชื่อผู้รับที่ต้องการและอาจปรากฏเป็นสตริงเดียวหรือคอลเลกชัน นโยบายของเซิร์ฟเวอร์ทรัพยากรจะต้องพบว่าตัวเองอยู่ในค่าที่ผ่านการรับรองความถูกต้องโดยใช้กฎการเปรียบเทียบที่แน่นอนซึ่งโปรไฟล์กำหนด ไม่ควรยอมรับโทเค็นเพียงเพราะมีการระบุบริการที่คุ้นเคยอื่นๆ ไว้
ToolAcre นำอาร์เรย์เป็นข้อความ JSON ในตารางการอ้างสิทธิ์ โดยคงโครงสร้างที่มองเห็นได้ไว้สำหรับการตรวจสอบ ไม่ทราบตัวระบุของ API ปัจจุบัน และไม่สามารถตัดสินการจับคู่ได้ การขาดงานโดยเจตนาดังกล่าวจะป้องกันไม่ให้ตัวถอดรหัสทั่วไปสร้างบริบทการอนุญาตที่ตัวถอดรหัสนั้นไม่มี
azp และขอบเขต — OpenID Connect และ OAuth อ้างว่ากำหนดผู้ที่อาจใช้โทเค็นและเพื่ออะไร
`azp` และ `scope` สามารถเพิ่มบริบทเกี่ยวกับบุคคลที่ได้รับอนุญาตและขอสิทธิ์ในโปรไฟล์ที่กำหนดสิ่งเหล่านั้น พวกเขาไม่ได้แทนที่การตรวจสอบผู้ชม ผู้ออก หรือลายเซ็น ชื่อขอบเขตเป็นการยืนยัน ไม่ใช่การให้สิทธิ์จนกว่าเซิร์ฟเวอร์ทรัพยากรจะแมปค่าที่ผ่านการรับรองความถูกต้องกับนโยบายของตนเอง
ตัวถอดรหัสปัจจุบันถือว่าสิ่งเหล่านี้เป็นการกล่าวอ้างเฉพาะแอปพลิเคชัน เนื่องจากตารางคำอธิบายที่ลงทะเบียนไว้ครอบคลุมชื่อหลักเจ็ดชื่อ มันแสดงค่าของพวกเขา แต่ไม่มีการเชื่อมต่อ OpenID หรือซีแมนทิกส์ OAuth ศึกษาโปรไฟล์ที่เกี่ยวข้องและสัญญาของผู้ให้บริการก่อนนำไปใช้ในการตัดสินใจ
รูปแบบรองที่สับสน — โทเค็นที่ถูกต้องจะกลายเป็นการโจมตีได้อย่างไรเมื่อไม่ได้ตรวจสอบผู้ชม
รองผู้ว่าที่สับสนใช้อำนาจที่ถูกต้องตามกฎหมายในบริบทที่ไม่ได้ตั้งใจ โทเค็นที่บริการที่ไม่ถูกต้องยอมรับสามารถกระตุ้นรูปแบบนั้นได้อย่างแน่นอน แม้ว่าจะไม่มีใครปลอมแปลงลายเซ็นก็ตาม ขีดจำกัดการตรวจสอบผู้ชมในกรณีที่อาจใช้การอ้างสิทธิ์ที่มีการรับรองความถูกต้อง ในขณะที่เช็คของผู้ออกจะจำกัดการยืนยันที่บริการพิจารณา
นี่คือเหตุผลว่าทำไมการตั้งค่าสถานะ "ลายเซ็นที่ถูกต้อง" โดยทั่วไปจึงยังไม่เพียงพอ การอนุญาตขึ้นอยู่กับผู้รับและการดำเนินการ ToolAcre หลีกเลี่ยงความคลุมเครือนั้นโดยสิ้นเชิงโดยการรายงานผลการตรวจสอบที่ไม่มี ออกจากบริการที่สิ้นเปลืองเพื่อรวมการเข้ารหัสเข้ากับนโยบายเชิงบริบท
ตัวอย่างการทำงาน — การอ่าน iss และ aud จากโทเค็นสองตัวในตัวถอดรหัส ToolAcre JWT และตัดสินใจว่าบริการใดควรยอมรับแต่ละรายการ
สร้างโทเค็นที่ไม่เป็นอันตรายสองอันซึ่งมีเพย์โหลดที่ถอดรหัสแตกต่างกันเฉพาะใน `aud`: หนึ่งชื่อ `service-a` และอีกชื่อ `service-b`; ทั้งสองอ้างว่าเป็นผู้ออกเดียวกัน ToolAcre ทำให้มองเห็นความแตกต่างได้ บริการ-A ผู้ตรวจสอบไม่ควรยอมรับเพียงจากจอแสดงผลนี้เท่านั้น และควรปฏิเสธบริการ-B ผู้ชมที่ผ่านการรับรองความถูกต้อง
จากนั้นย้อนกลับการฝึกหัดด้วยสายผู้ออกสองสาย ข้อความที่คาดหวังเพียงอย่างเดียวนั้นไม่เพียงพอ เว้นแต่การยืนยันจะใช้คีย์ที่เชื่อถือได้สำหรับผู้ออกนั้น ตัวอย่างเหล่านี้แยกการตรวจสอบออกจากการยอมรับ และแสดงให้เห็นว่าเหตุใดการคัดลอกการกล่าวอ้างที่ดูถูกต้องลงในโทเค็นที่สร้างขึ้นจึงไม่เปลี่ยนแปลงนโยบายที่เชื่อถือได้
สิ่งนี้ไม่ครอบคลุมถึง — การตรวจสอบลายเซ็น ซึ่งตัวถอดรหัสไม่เคยดำเนินการ การตรวจสอบของ aud และ iss จะมีผลเฉพาะหลังจากที่ลายเซ็นถูกระงับแล้วเท่านั้น
การตรวจสอบผู้ชมและผู้ออกจะมีความสำคัญหลังจากการตรวจสอบการเข้ารหัสพบว่าไบต์ที่ได้รับการป้องกันนั้นสอดคล้องกับเนื้อหาหลักที่เชื่อถือได้ ToolAcre ไม่ดำเนินการยืนยันใดๆ เลย ผลลัพธ์ไม่สามารถระบุได้ว่าการอ้างสิทธิ์ยังคงอยู่ครบถ้วนหรือผู้ออกที่ทราบเป็นผู้เขียน
นอกจากนี้ยังไม่ดึงข้อมูลเมตา เลือกคีย์ หรือเปรียบเทียบผู้รับที่กำหนดค่าไว้ ใช้การทดสอบแบ็กเอนด์และบันทึกเพื่อพิสูจน์การปฏิเสธสำหรับผู้ออกที่ไม่ถูกต้องและผู้ชมที่ไม่ถูกต้อง การจับคู่ด้วยภาพในตัวถอดรหัสถือเป็นเบาะแสในการแก้ไขจุดบกพร่อง และไม่มีหลักฐานการให้สิทธิ์เพียงพอ
ประเด็นสำคัญ: ตรวจสอบว่าเหมาะสำหรับใคร ไม่ใช่แค่ใครเป็นผู้ลงนาม — ตัวถอดรหัส ToolAcre JWT จะแสดงการอ้างสิทธิ์ aud และ iss ที่คุณต้องเปรียบเทียบ
ตรวจสอบว่าโทเค็นนั้นมีไว้เพื่อใคร ไม่ใช่แค่ชื่อที่ลงนามเท่านั้น โฟลว์ที่มีประสิทธิภาพจะตรวจสอบสิทธิ์ไบต์ที่ได้รับการป้องกันภายใต้ความสัมพันธ์ของผู้ออกที่เชื่อถือได้อย่างเป็นอิสระ จากนั้นจำเป็นต้องมีผู้ชมที่ยอมรับได้ และใช้กฎการอนุญาตเฉพาะบริการ
ใช้ ToolAcre เพื่ออ่านค่าการทดสอบที่ปลอดภัยและกำหนดการตรวจสอบฝั่งเซิร์ฟเวอร์ครั้งถัดไป อย่าเลือกคีย์การยืนยันจากส่วนหัวที่ไม่น่าเชื่อถือหรือข้อมูลการอ้างสิทธิ์ และอย่าเปลี่ยน `iss`, `aud`, `azp` หรือ `scope` ที่แสดงเป็นการให้สิทธิ์โดยไม่มีขั้นตอนที่เชื่อถือได้เต็มรูปแบบ