أدوات المطور · وحدة فك التشفير JWT
هجوم alg:none وارتباك المفاتيح: لماذا يجب على القائمين على التحقق تثبيت الخوارزميات
· لماذا يهم
jwt حماية التشفير
إذا سمح برنامج التحقق للرمز المميز باختيار الخوارزمية الخاصة به، فيمكن للمهاجم اختيار لا شيء أو تبديل RSA بـ HMAC. يشرح هذا المنشور كلاً من الهجمات والقاعدة التي تمنعها.
الرمز المميز الذي أثبت نفسه – كيف أصبح حقل الرأس سطحًا للهجوم
توجد تسمية خوارزمية داخل إدخال الرمز المميز الذي يتحكم فيه المهاجم. إذا تعامل المدقق مع هذه التسمية كإذن لتحديد أي وضع تحقق متاح، يبدأ الرمز المميز في التأثير على القاعدة المستخدمة للحكم على نفسه. يعرض ToolAcre التصنيف بدقة حتى يتمكن المراجعون من رؤيته، ولكن لا يتم التعامل معه مطلقًا بطريقة مشفرة.
الاتجاه الآمن هو العكس: يحدد تكوين الخدمة الموثوقة عائلات الخوارزمية المقبولة والمفاتيح المرتبطة بها، ثم يجب أن تتطابق الرؤوس الواردة مع تلك السياسة. لا يمكن أن توفر لوحة فك التشفير هذه السياسة ويجب ألا يتم الخلط بينها وبين الحماية لمجرد أنها تسلط الضوء على قيمة مشبوهة.
يشير المستودع إلى alg:none ولكنه لا ينشئ سجل المواصفات خلف JWTs غير الآمنة
يعامل التنفيذ `alg: none` كإعلان غير موقع ويحذر من أن قبوله سيقبل محتوى عشوائيًا. كما يُبلغ عن جزء ثالث فارغ بشكل منفصل. تدعم أدلة المستودع رفض مثل هذه المدخلات في سير العمل المصادق عليه؛ ولا يوثق سبب إدراج JWTs غير المؤمنة في المواصفات في الأصل.
ومن ثم، فقد تم تصحيح هذه الصياغة التاريخية بدلا من اختراعها. ما يهم من الناحية التشغيلية واضح: الخدمة التي تتوقع بيانات اعتماد موقعة يجب ألا تسمح لرأس الرمز المميز بتعطيل التحقق من التوقيع. لا يقوم 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 وسجل التغييرات في مكتبتك
تختلف واجهات برمجة تطبيقات المكتبة والإعدادات الافتراضية والإصلاحات التاريخية حسب المنتج والإصدار. لا تحدد هذه الوحدة اسم الخيار الذي يثبت الخوارزميات في مكدسك، وهذه المقالة لا تخترع أي شيء عمدًا. اقرأ الوثائق الحالية وسجل التغييرات للمكتبة المحددة، ثم مارس حالات الرفض في مجموعة الاختبار الخاصة بك.
اختبر أيضًا أنواع المفاتيح الخاطئة، وقيم `kid` غير المعروفة، والتوقيعات المفقودة وملفات تعريف الرموز المميزة غير المتوقعة. الهدف هو إظهار أن التكوين يفوز على اقتراحات الرموز المميزة. لا ينتمي فك التشفير الناجح إلى أي مكان في تأكيدات القبول هذه لأن نجاح بناء الجملة متوافق مع كل الأمثلة الضارة.
الخلاصة: أداة التحقق هي التي تقرر، وليس الرمز المميز - تساعدك وحدة فك التشفير على رؤية الرأس، ولكن التحقق المثبت فقط هو الذي يحميك
يقرر المدقق؛ الرمز المميز لا. يمكن أن يكشف ToolAcre عن رأس يقول `none`، أو خوارزمية غير مألوفة أو معرف مفتاح مفاجئ. تساعد هذه الرؤية على الفرز، لكن سياسة الخوارزمية المثبتة والمفاتيح الموثوقة المرتبطة بشكل صحيح فقط هي التي تمنع القبول.
لا تنصح أبدًا بتمكين `none` أو اختيار مفتاح التحقق من رأس غير موثوق به أو التعامل مع طول التوقيع المعروض كتحقق من الصحة. قم بفك التشفير للفحص، ثم إثبات سلوك الرفض والقبول عند حدود التشفير الحقيقية من خلال اختبارات خاضعة للرقابة.