เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ · ตัวถอดรหัส JWT
การโจมตี alg:none และความสับสนที่สำคัญ: เหตุใดผู้ตรวจสอบจึงต้องปักหมุดอัลกอริทึม
· เหตุใดจึงสำคัญ
jwt ความปลอดภัย การเข้ารหัส
หากผู้ตรวจสอบอนุญาตให้โทเค็นเลือกอัลกอริทึมของตนเอง ผู้โจมตีสามารถเลือกไม่มีหรือสลับ RSA สำหรับ HMAC ได้ โพสต์นี้จะอธิบายทั้งการโจมตีและกฎที่ป้องกัน
โทเค็นที่ยืนยันตัวเอง — วิธีที่ฟิลด์ส่วนหัวกลายเป็นพื้นผิวการโจมตี
ป้ายอัลกอริทึมจะอยู่ภายในอินพุตโทเค็นที่ควบคุมโดยผู้โจมตี หากผู้ตรวจสอบถือว่าป้ายกำกับนั้นเป็นสิทธิ์ในการเลือกโหมดการตรวจสอบที่มีอยู่ โทเค็นจะเริ่มมีอิทธิพลต่อกฎที่ใช้ในการตัดสินตัวเอง ToolAcre เปิดเผยป้ายกำกับอย่างแม่นยำเพื่อให้ผู้ตรวจสอบมองเห็นได้ แต่จะไม่ดำเนินการใดๆ กับป้ายกำกับนั้นด้วยการเข้ารหัส
ทิศทางที่ปลอดภัยคือสิ่งที่ตรงกันข้าม: การกำหนดค่าบริการที่เชื่อถือได้จะกำหนดกลุ่มอัลกอริธึมที่ยอมรับได้และคีย์ที่เกี่ยวข้อง จากนั้นส่วนหัวที่เข้ามาจะต้องตรงกับนโยบายนั้น แผงถอดรหัสไม่สามารถระบุนโยบายดังกล่าวได้ และต้องไม่เข้าใจผิดว่าเป็นการป้องกันเพียงเพราะมันเน้นค่าที่น่าสงสัย
พื้นที่เก็บข้อมูลจะตั้งค่าสถานะ alg:none แต่ไม่ได้สร้างประวัติข้อกำหนดเบื้องหลัง JWT ที่ไม่ปลอดภัย
การใช้งานถือว่า `alg: none` เป็นการประกาศที่ไม่ได้ลงนาม และเตือนว่าการยอมรับจะเป็นการยอมรับเนื้อหาที่กำหนดเอง นอกจากนี้ยังรายงานส่วนที่สามที่ว่างเปล่าแยกกันอีกด้วย หลักฐานที่เก็บข้อมูลสนับสนุนการปฏิเสธอินพุตดังกล่าวในเวิร์กโฟลว์ที่ผ่านการรับรองความถูกต้อง มันไม่ได้บันทึกว่าเหตุใด JWT ที่ไม่ปลอดภัยจึงถูกรวมไว้ในข้อกำหนดตั้งแต่แรก
ถ้อยคำทางประวัติศาสตร์นั้นจึงได้รับการแก้ไขแทนที่จะประดิษฐ์ขึ้น สิ่งสำคัญในการปฏิบัติงานมีความชัดเจน: บริการที่คาดหวังข้อมูลรับรองที่ลงนามจะต้องไม่อนุญาตให้ส่วนหัวโทเค็นปิดการใช้งานการตรวจสอบลายเซ็น ToolAcre เองไม่ได้ทำการตรวจสอบ ดังนั้นความสามารถในการแสดง `none` จึงเป็นการตรวจจับเพื่อการตรวจสอบเท่านั้น
การโจมตี alg:none — ตัดลายเซ็นและขอให้ผู้ตรวจสอบยอมรับลายเซ็นที่ว่างเปล่า
การโจมตีที่ไม่ได้ลงนามจะเปลี่ยนส่วนหัวเพื่อร้องขอ `none` เปลี่ยนแปลงการอ้างสิทธิ์หากต้องการ และไม่มีไบต์ลายเซ็น ทุกส่วนยังคงสามารถใช้ไวยากรณ์ได้ และสองส่วนแรกจะถอดรหัสเป็น JSON ที่ได้รับการขัดเกลา ผู้ตรวจสอบที่อนุญาตจะแปลงการตั้งค่าของผู้โจมตีเป็นการเลี่ยงการตรวจสอบสิทธิ์
ผู้ตรวจสอบที่เข้มงวดไม่มีสาขาที่อัปเกรดอินพุตนี้เป็นสถานะที่เชื่อถือได้เมื่อจำเป็นต้องใช้โทเค็นที่เซ็นชื่อ คำเตือนของ ToolAcre ช่วยระบุรูปร่างระหว่างการแก้ไขข้อบกพร่อง แต่การอ่านคำว่า `none` ไม่ได้หยุดแบ็กเอนด์จากการตัดสินใจที่ไม่ดี การบังคับใช้เป็นส่วนที่ข้อมูลประจำตัวถูกใช้ไป
ความสับสนของคีย์ — การแสดงคีย์สาธารณะเป็นความลับ HMAC ดังนั้นโทเค็น RS256 จึงได้รับการยืนยันว่าเป็น HS256
ความสับสนที่สำคัญเกิดขึ้นเมื่อผู้ตรวจสอบอนุญาตให้ตระกูลอัลกอริทึมที่มีบทบาทคีย์ที่เข้ากันไม่ได้ และไม่สามารถผูกแต่ละตัวเลือกเข้ากับประเภทคีย์ที่ถูกต้องได้ คีย์การยืนยัน RSA สาธารณะไม่ใช่ความลับ HMAC การปฏิบัติต่อไบต์เป็นหนึ่งเดียวหลังจากที่ผู้โจมตีเปลี่ยนป้ายกำกับอัลกอริทึมจะยุบการแยก public/private ที่ตั้งใจไว้
การป้องกันระดับข้อผิดพลาดนั้นต้องการมากกว่าการตรวจสอบส่วนที่มีรูปร่างเป็นลายเซ็น บริการจะต้องจับคู่อัลกอริธึมที่คาดหวัง ประเภทคีย์ ผู้ออกและโปรไฟล์โทเค็นผ่านการกำหนดค่าที่เชื่อถือได้ ตัวถอดรหัสที่แสดง RS256 หรือ HS256 ไม่สามารถบอกได้ว่าแบ็กเอนด์รักษาการเชื่อมโยงเหล่านั้นไว้หรือไม่
การแก้ไข — ปักหมุดอัลกอริธึมที่ยอมรับในตัวตรวจสอบ และไม่เคยได้รับมาจากโทเค็น
ปักหมุดอัลกอริธึมที่ยอมรับในการกำหนดค่าตัวตรวจสอบ และเก็บรายการให้แคบลงตามที่สัญญาของผู้ออกอนุญาต ปฏิเสธ `none` สำหรับโฟลว์ข้อมูลรับรองที่ลงนาม และปฏิเสธข้อมูลที่ไม่ตรงกันแทนที่จะลองใช้อัลกอริทึมอื่น อย่ารับรายการที่อนุญาตจากส่วนหัวที่ไม่ได้รับการยืนยันหรือจากการอ้างสิทธิ์เพย์โหลด
การค้นหาคีย์เป็นไปตามหลักการเดียวกัน `kid` สามารถเลือกจากผู้สมัครที่เชื่อถือได้อยู่แล้ว แต่ต้องไม่สร้างแหล่งที่เชื่อถือได้ใหม่ ไม่ควรติดตาม URL ส่วนหัวหรือคีย์ที่ฝังไว้เพียงเพราะโทเค็นร้องขอ ผู้ตรวจสอบจะตัดสินใจเลือกแหล่งที่มาอย่างเป็นอิสระ
ตัวอย่างการทำงาน — การอ่านส่วนหัวในตัวถอดรหัส ToolAcre JWT เพื่อระบุ alg:none และเหตุใดการตรวจพบจึงไม่เหมือนกับการป้องกัน
สร้างส่วนหัวโทเค็นที่ไม่เป็นอันตรายโดยประกาศ `none` และปล่อยส่วนที่สามว่างไว้ ToolAcre ถอดรหัส JSON รายงานอัลกอริทึมที่ประกาศ เตือนว่าไม่ได้ลงนาม และบันทึกลายเซ็นที่ขาดหายไป นี่เป็นพฤติกรรมที่คาดหวังจากเครื่องมือตรวจสอบอย่างแน่นอน
แบบฝึกหัดไม่ได้พิสูจน์ว่า API ปฏิเสธโทเค็น ยืนยันแยกกันด้วยการทดสอบเชิงลบที่มีการควบคุมกับเครื่องยืนยันและการกำหนดค่าจริง หาก API ยอมรับ การแก้ไขจะอยู่ในขอบเขตการยืนยันนั้น การเพิ่มคำเตือนที่ดังขึ้นให้กับตัวถอดรหัสจะไม่ปกป้องคำขอ
สิ่งนี้ไม่ครอบคลุม — การแก้ไขเฉพาะไลบรารีจำนวนมาก; ปรึกษา RFC 8725 และบันทึกการเปลี่ยนแปลงของห้องสมุดของคุณ
API ของไลบรารี ค่าเริ่มต้น และการแก้ไขประวัติจะแตกต่างกันไปตามผลิตภัณฑ์และเวอร์ชัน โมดูลนี้ไม่ได้กำหนดว่าชื่อตัวเลือกใดที่หมุดอัลกอริธึมในสแต็กของคุณและบทความนี้ไม่ได้ตั้งใจจะประดิษฐ์เลย อ่านเอกสารและบันทึกการเปลี่ยนแปลงในปัจจุบันของไลบรารีที่เลือก จากนั้นดำเนินการกรณีการปฏิเสธในชุดทดสอบของคุณเอง
นอกจากนี้ ทดสอบประเภทคีย์ที่ไม่ถูกต้อง ค่า `kid` ที่ไม่รู้จัก ลายเซ็นที่หายไป และโปรไฟล์โทเค็นที่ไม่คาดคิด เป้าหมายคือการแสดงให้เห็นว่าการกำหนดค่าชนะเหนือคำแนะนำโทเค็น การถอดรหัสที่ประสบความสำเร็จไม่มีอยู่ในการยืนยันการยอมรับเหล่านี้ เนื่องจากความสำเร็จทางไวยากรณ์เข้ากันได้กับตัวอย่างที่เป็นอันตรายทุกตัวอย่าง
ประเด็นสำคัญ: ผู้ตรวจสอบตัดสินใจ ไม่ใช่โทเค็น — ตัวถอดรหัสช่วยให้คุณเห็นส่วนหัว แต่มีเพียงการตรวจสอบที่ปักหมุดไว้เท่านั้นที่จะปกป้องคุณ
ผู้ตรวจสอบจะเป็นผู้ตัดสินใจ โทเค็นไม่ได้ ToolAcre สามารถเปิดเผยส่วนหัวที่ระบุว่า `none` ซึ่งเป็นอัลกอริทึมที่ไม่คุ้นเคยหรือตัวระบุคีย์ที่น่าประหลาดใจ การมองเห็นนั้นช่วยในการคัดแยก แต่มีเพียงนโยบายอัลกอริทึมที่ปักหมุดไว้และคีย์ที่เชื่อถือได้ที่ผูกไว้อย่างถูกต้องเท่านั้นที่จะป้องกันการยอมรับ
อย่าแนะนำให้เปิดใช้งาน `none` โดยเลือกคีย์การยืนยันจากส่วนหัวที่ไม่น่าเชื่อถือ หรือถือว่าความยาวของลายเซ็นที่แสดงเป็นการตรวจสอบ ถอดรหัสเพื่อตรวจสอบ จากนั้นพิสูจน์พฤติกรรมการปฏิเสธและการยอมรับที่ขอบเขตการเข้ารหัสจริงด้วยการทดสอบที่มีการควบคุม