العربية

ما يثبت JWT الذي تم فك تشفيره

يعرض لك جهاز فك الترميز JWT ما يطالب به الرمز المميز. لا يمكن أن يوضح لك ما إذا كانت هذه الادعاءات صحيحة. يغطي هذا الدليل ما هي الأجزاء الثلاثة، وما يفعله فك التشفير وما لا ينشئه، والهجمات التي تعيش في الفجوة بين الاثنين.

ثلاثة أجزاء، اثنان منها فقط JSON

JWT في شكله الشائع هو JWS: ثلاثة أجزاء base64url مفصولة بالنقاط. الأول عبارة عن رأس، والثاني حمولة، والثالث توقيع.

الرأس والحمولة عبارة عن كائنات JSON عادية تم ترميزها باستخدام base64url. مشفرة وليست مشفرة. يمكن لأي شخص يحمل الرمز قراءة كليهما على الفور، دون الحاجة إلى مفتاح - وهذا ليس عيبًا، بل هو التصميم. JWT عبارة عن بيان موقع، وليس ظرفًا مختومًا. يضمن التوقيع عدم تغيير البيان؛ لا يفعل شيئًا للحفاظ على خصوصيته.

والنتيجة تستحق الذكر بوضوح لأنه يتم تفويتها بشكل روتيني: لا تضع أبدًا أي شيء سريًا في الحمولة النافعة JWT. ليست كلمة مرور، ولا معرفًا وطنيًا كاملاً، ولا تفاصيل النظام الداخلي. افترض أن الحمولة عامة، لأنها كذلك بالنسبة لأي شخص لديه الرمز المميز.

الجزء الثالث هو التوقيع، محسوبا على الأولين. وهو الجزء الوحيد الذي يحمل أي قيمة أمنية، وهو الجزء الذي لا يستطيع جهاز فك التشفير تقييمه.

ما يثبت فك التشفير: لا شيء

وهذا هو الهدف من الدليل كله. يؤدي فك تشفير JWT إلى توزيع سلسلتين من سلسلة base64url إلى JSON. إنه يؤكد أن الرمز المميز تم تشكيله بشكل جيد. ولا يؤكد أن الرمز المميز حقيقي، أو أنه تم إصداره من قبل الطرف المذكور في المطالبة "iss"، أو أنه لم يتم تحرير المطالبات، أو أنه كان صالحًا على الإطلاق.

يمكن لأي شخص إنشاء رمز مميز. خذ أي JWT، وقم بتغيير "الدور": "المستخدم" إلى "الدور": "المسؤول"، وأعد تشفير الحمولة، وقم بتدبيس أي توقيع في النهاية، وسيعرض جهاز فك التشفير مطالباتك المعدلة بنفس الثقة تمامًا كما عرض الأصل. ليس هناك طريقة لمعرفة الفرق، لأن التحقق من الفرق هو عملية مختلفة تتطلب مفتاحًا لا يمتلكه جهاز فك التشفير.

لذلك عندما يعرض لك جهاز فك التشفير - هذا أو أي جهاز آخر - "exp: 2026-01-01"، فإن ما يخبرك به حقًا هو: يحتوي هذا الرمز المميز على مطالبة بأن صلاحيته تنتهي في ذلك التاريخ. ويعتمد ما إذا كان هذا الادعاء يعني أي شيء بشكل كامل على ما إذا كان التوقيع صالحًا أم لا، وهو الأمر الذي لم يتم التحقق منه.

هذه الأداة تقوم بفك التشفير فقط، وتقول ذلك على الصفحة، بجانب النتائج، في كل مرة. ليس في الحاشية السفلية. والسبب هو أن وحدة فك التشفير التي تظل صامتة بشأن هذا الأمر تقوم بتدريب مستخدميها على قراءة البيانات التي لم يتم التحقق منها كما لو تم التحقق منها، وهذه العادة هي أصل عائلة كاملة من أخطاء المصادقة.

لماذا لا تقدم هذه الأداة التحقق

يحتاج التحقق إلى ثلاثة أشياء لا يمكن لصفحة الويب أن تمتلكها بشكل مسؤول: مفتاح جهة الإصدار، والخوارزمية المثبتة مسبقًا، وسياسة حول ما يجب رفضه.

المفتاح هو المشكلة الواضحة. بالنسبة لخوارزميات HMAC (HS256 والأصدقاء)، يكون المفتاح سرًا مشتركًا - وهو نفس السر المستخدم لإنشاء الرموز المميزة. إن لصقها في صفحة ويب يعني لصق بيانات اعتماد يمكنها سك الرموز الصالحة في صفحة الويب. بالنسبة إلى RSA وECDSA، فإن المفتاح العام ليس سرًا، ولكنك ستظل بحاجة إلى جلب المفتاح الصحيح من نقطة نهاية JWKS الصحيحة والثقة التي تمتلكها.

الخوارزمية هي المشكلة الدقيقة، ومصدر هجومين معروفين. الأول هو alg: "none": يدعي الرأس أن الرمز المميز غير موقع، ويقبل المدقق الذي يحترم الرأس بدلاً من التكوين الخاص به أي شيء. والثاني هو ارتباك RS256-to-HS256: يأخذ المهاجم مفتاحًا عامًا - وهو، بحكم التعريف، عام - يغير الرأس ليقول HS256، ويوقع الرمز المميز باستخدام هذا المفتاح العام باعتباره السر HMAC. سيقوم المدقق الذي يقرأ الخوارزمية من الرمز المميز ويبحث عن "المفتاح" بالتحقق من صحتها.

يأتي كلا الهجومين من نفس الخطأ: السماح للرمز المميز بإخبار المدقق بكيفية التحقق من الرمز المميز. يتجاهل المدقق الصحيح خوارزمية الرأس ويستخدم الخوارزمية التي تم تكوينه بها. وهذا قرار يعود إلى النظام الذي يثق في الرمز المميز - وليس إلى أداة الراحة، وليس إلى من يلصق شيئًا ما في النموذج.

لماذا لا تلصق رموز الإنتاج في أي مكان

رمز الوصول هو بيانات اعتماد حامله. هذا هو ما تعنيه كلمة "الحامل" في رأس التفويض: من يحمله، هو أنت. لا يوجد عامل ثانٍ وعادة لا توجد طريقة للتمييز بين الرمز المميز المسروق والرمز الشرعي. وإلى أن تنتهي صلاحيته، فهو مفتاح عمل لحسابك.

لذا فإن لصق رمز مباشر في أي صفحة ويب يعد بمثابة تسليم بيانات اعتماد لتلك الصفحة. يقوم هذا الخيار بفك تشفير كل شيء محليًا ولا يقدم أي طلب للشبكة بعد تحميل الصفحة - يمكنك تأكيد ذلك في لوحة الشبكة بالمتصفح الخاص بك، ويجب عليك ذلك، لأن الأمر يستغرق عشر ثوانٍ. لكن لاحظ ما هي هذه الحجة في الواقع: ادعاء، على موقع ويب، بأن الموقع جدير بالثقة. كل موقع يقوم بتصفية الرموز يقدم نفس الادعاء تمامًا، ولا يستطيع الزائر معرفة الفرق بنظرة واحدة.

العادة الآمنة لا تعتمد على الحكم على المواقع بشكل صحيح. استخدم الرموز المميزة منتهية الصلاحية، أو الرموز المميزة لبيئة الاختبار، أو الرموز المميزة التي سكتها لهذا الغرض. إذا كنت قد قمت بالفعل بلصق رمز الإنتاج في مكان ما - في أي مكان - فقم بتدويره. الإلغاء رخيص؛ حادثة ليست كذلك.

وينطبق الشيء نفسه بقوة أكبر على مفاتيح التوقيع. لا يوجد سبب مشروع لكتابة سر HMAC أو مفتاح خاص في صفحة ويب، وأي موقع يطلب واحدًا "للتحقق" من الرمز المميز الخاص بك يطلب القدرة على تزوير الرموز المميزة. هذا هو السبب الملموس لعدم احتواء هذه الأداة على ميزة التحقق: الميزة تتطلب الطلب.

قراءة المطالبات التي تهم

RFC 7519 يسجل مجموعة صغيرة من أسماء المطالبات. "iss" هو المُصدر، و"sub" هو الموضوع الذي يدور حوله الرمز المميز، و"aud" الجمهور المستهدف، و"exp" انتهاء الصلاحية، و"nbf" أول وقت صالح، و"iat" وقت الإصدار، و"jti" معرف فريد لاكتشاف إعادة التشغيل. كل شيء آخر خاص بالتطبيق.

مطالبات الوقت هي قيم NumericDate: الثواني منذ عصر Unix، وليس ميلي ثانية. يؤدي هذا إلى نقل الأشخاص باستمرار، لأن معظم قيم الوقت JavaScript هي بالمللي ثانية. الرمز المميز الذي يبدو أن صلاحيته ستنتهي في 1970 عادةً ما يُعطى قيمة بالمللي ثانية؛ واحدة يبدو أنها تنتهي صلاحيتها في العام 55000 عادةً ما يكون لها قيمة ثانية مضروبة في 1000 في مكان ما.

يستحق "aud" اهتمامًا خاصًا عند تصحيح الأخطاء. من الممكن أن يكون الرمز المميز الصالح تمامًا رمزًا خاطئًا، لأنه تم إصداره لجمهور مختلف. سيقبل المدقق الذي يتحقق من التوقيع ولكن ليس الجمهور رمزًا مميزًا تم سكه لخدمة أخرى بالكامل - وهو مسار حقيقي لتصعيد الامتيازات في الأنظمة التي تشترك في موفر الهوية.

تعرض هذه الأداة مطالبات الوقت في UTC، وتضع علامة على رمز منتهي الصلاحية على أنه منتهي الصلاحية، وتجمع ذلك مع تذكير بأن مطالبة انتهاء الصلاحية لا تعني شيئًا إلا إذا كان التوقيع صالحًا. التذكير موجود لأن العبارة "تشير إلى أنها لم تنته صلاحيتها" هي اللحظة المحددة التي تسبب فيها عادة البيانات التي لم يتم التحقق منها ضررها.

قائمة مرجعية قصيرة للنظام الذي يقوم بعملية الثقة

إذا كنت تكتب التعليمات البرمجية التي تقبل الرموز المميزة بدلاً من مجرد فحصها، فإن ما يلي هو الإصدار القصير لما يفعله المدقق الصحيح.

  1. تحقق من التوقيع أولاً، باستخدام المفتاح الذي حصلت عليه خارج النطاق، قبل قراءة أي مطالبة.
  2. قم بتثبيت الخوارزمية في التكوين الخاص بك. لا تقرأه أبدًا من رأس الرمز المميز. رفض "لا شيء" دون قيد أو شرط.
  3. تحقق من "exp" و"nbf" مقابل ساعة موثوقة، مع قدر ضئيل من التسامح مع الانحراف على الأكثر.
  4. تحقق من "iss" و"aud" مقابل القيم التي تتوقعها. التوقيع الصالح على الرمز المميز المخصص لشخص آخر لا يزال رمزًا خاطئًا.
  5. استخدم مكتبة تم فحصها لمنصتك بدلاً من تجميعها بنفسك. كل عنصر في هذه القائمة موجود فيه لأن التطبيقات قد أخطأت في فهمه.
  6. اجعل عمر الرمز قصيرًا، وامتلك مسارًا للإلغاء. تعمل الرموز قصيرة العمر على الحد من الضرر الناتج عن التسرب الذي لم تلاحظه بعد.

ماذا يحدث لما تلصقه

  • يتم تشغيل كل تحويل وتجزئة وفك تشفير وفرق في علامة تبويب المتصفح الخاص بك. لا يتم تحميل أي مدخلات أو تسجيلها أو تخزينها على الخادم، لأنه لا يوجد خادم مشارك بمجرد تحميل الصفحة.
  • تأتي التجزئة من تطبيق Web Crypto الخاص بالمتصفح، والمعرفات الفريدة الفريدة (UUID) من المولد العشوائي الآمن للتشفير. لا يتضمن أي منهما مكالمة شبكة.
  • لا تتم كتابة أي شيء تكتبه على وحدة التخزين المحلية أو ملف تعريف الارتباط. تؤدي إعادة تحميل الصفحة إلى تجاهلها؛ إغلاق علامة التبويب يتجاهلها.
  • يتم تشغيل التحليلات على مستوى الموقع فقط على مضيف الإنتاج الأساسي الذي تم تكوينه ويتم الكشف عنها في سياسة الخصوصية؛ المضيفون المحليون ومضيفو المعاينة يرفضون ذلك. يتم استبعاد القيم والرموز المميزة وعناوين URL ومحتويات الملفات التي تم لصقها من أحداث التحليلات الخاصة بـ ToolAcre. تم تعطيل الإعلان في التكوين الحالي.
  • ومع ذلك: يعد المفتاح JWT أو المفتاح API بمثابة بيانات اعتماد مباشرة. العادة الآمنة هي عدم لصق أي شيء على صفحة ويب لم تكتبها، مهما كانت ادعاءاتها جديرة بالثقة - بما في ذلك هذه الصفحة.

أسئلة

هل هذه الأداة تتحقق من التوقيع؟

لا، ولن يحدث ذلك أبداً. يقوم بفك تشفير الرأس والحمولة ويظهر لك ما تحتويه. فهو لا يتحقق من التوقيع، لذلك لا يوجد شيء يعرضه يثبت أن الرمز المميز أصلي أو غير متغير أو صادر من أي شخص يذكره.

إذن كيف أعرف أن الرمز المميز أصلي؟

من خلال التحقق من التوقيع باستخدام مفتاح المُصدر، باستخدام مكتبة تم فحصها، مع تثبيت الخوارزمية في التكوين الخاص بك بدلاً من قراءتها من الرمز المميز. وهذا هو العمل لصالح الخدمة التي تثق في الرمز المميز، في بيئة تحمل المفتاح بشكل شرعي.

هل يتم إرسال الرمز المميز الخاص بي إلى أي مكان عندما أقوم بفك تشفيره هنا؟

لا. يتم فك التشفير في علامة تبويب المتصفح لديك باستخدام JavaScript الخاص بالصفحة، ولا تقدم الصفحة أي طلبات شبكة بعد تحميلها. يمكنك التحقق من ذلك في لوحة الشبكة في متصفحك. لا يزال يتعين عليك عدم لصق رموز الإنتاج في أدوات الويب كعادة، لأن هذه العادة يجب أن تعمل على المواقع غير الصادقة بشأنها.

لماذا يمكن لأي شخص قراءة حمولتي JWT؟

لأن الحمولة مشفرة بـ base64url، وليست مشفرة. JWS عبارة عن بيان موقع، وليس مختومًا. إذا كنت تريد أن تكون المحتويات غير قابلة للقراءة، فأنت بحاجة إلى JWE، تنسيق الرمز المميز المشفر - ومن ثم لا يمكن لجهاز فك التشفير أن يظهر لك أي شيء على الإطلاق بدون المفتاح.

ما هو طحالب: "لا شيء"؟

قيمة رأس تعلن أن الرمز المميز غير موقع. إنه موجود في مواصفات السياقات حيث يتم ضمان السلامة بوسائل أخرى، وهو فخ قائم: سيقبل المدقق الذي يثق في خوارزمية الرأس أي رمز مميز يدعي "لا شيء". تقوم هذه الأداة بوضع علامة عليها كلما ظهرت.

يحتوي الرمز المميز الخاص بي على خمسة أجزاء ولن يتم فك تشفيره. لماذا؟

خمسة أجزاء تعني JWE — رمز مميز مشفر — بدلاً من JWS موقع. لا يمكن قراءة محتوياته بدون مفتاح فك التشفير، لذلك لا يوجد شيء حقيقي يمكن أن تظهره وحدة فك التشفير. تحدد هذه الأداة هذه الحالة بشكل صريح بدلاً من الإبلاغ عن فشل تحليل غامض.

يبدو انتهاء الصلاحية خاطئًا بعامل 1000.

JWT مطالبات الوقت هي NumericDate: الثواني منذ العصر، وليس بالمللي ثانية. القيمة التي تنتجها Date.now() أكبر من اللازم بألف مرة. تقوم أداة الطابع الزمني الموجودة في مجموعة الأدوات هذه بالتحويل بين الاثنين وتخبرك دائمًا بالوحدة التي استخدمتها.

هل من الآمن تخزين JWT في التخزين المحلي؟

إنها مقايضة، وليست نعم أو لا. يمكن قراءة localStorage بواسطة أي JavaScript يعمل على مصدرك، لذا فإن ثغرة أمنية واحدة XSS تعمل على تسرب الرمز المميز. ملف تعريف الارتباط httpOnly غير قابل للقراءة بواسطة JavaScript ولكنه يحتاج إلى حماية CSRF. الملخص الصادق هو أن أيًا منهما ليس مجانيًا، وأن القرار ينتمي إلى نموذج التهديد الخاص بتطبيقك.

القيود

  • هذه الأداة تقوم بفك التشفير فقط. فهو لا يتحقق من التوقيعات، وهذا قرار تصميم دائم وليس ميزة مفقودة - راجع الدليل أعلاه لمعرفة السبب.
  • لا يمكن فك تشفير الرموز المميزة (JWE، خمسة أجزاء) على الإطلاق بدون المفتاح. تحددهم الأداة وتتوقف.
  • لا يتم إلغاء تغليف JWTs المتداخلة - وهو رمز مميز تكون حمولته في حد ذاته رمزًا مميزًا - تلقائيًا. قم بفك تشفير الرمز الداخلي كخطوة منفصلة.
  • إن معاني المطالبة التي تتجاوز المجموعة المسجلة المحددة في RFC 7519 خاصة بالتطبيق، لذا تعرض الأداة قيمها دون تفسيرها.
  • إن انتهاء الصلاحية الموضح هنا يعكس فقط ما يدعيه الرمز المميز عن نفسه. يعتمد ما إذا كانت هذه المطالبة ذات معنى على التوقيع الذي لا تتحقق منه هذه الأداة.
  • يتم رفض الرموز المميزة التي يزيد حجمها عن 200,000 من الأحرف. أي JWT حقيقي يكون أصغر من حيث الحجم.