أداة فك ترميز JWT
اقرأ ترويسة الرمز وادّعاءاته وما يقوله عن نفسه. فك ترميز لا تحقّق.
فكّ الترميز ليس تحقّقًا. المقطعان المقروءان في رمز JWT ليسا سوى base64 — يقرأهما أي أحد ويكتبهما أي أحد. التوقيع وحده هو ما يجعل الرمز جديرًا بالثقة، وفحصه يحتاج إلى المفتاح. هذه الصفحة لا تملك المفتاح ولا تطلبه، ولا تزعم شيئًا عن كون الرمز أصليًا.
تُزال البادئة «Bearer» تلقائيًا. ولا يغادر شيء مما تلصقه هذه الصفحة.
ثلاثة مقاطع، واحد منها فقط هو المهم
رمز JWT ثلاث سلاسل بترميز base64url يصلها نقطتان. الأوليان JSON تستطيع قراءته؛ والثالث توقيع على الأوليين.
eyJhbGciOiJIUzI1NiJ9 . eyJzdWIiOiIxMjM0In0 . 4fXK...
header payload signatureتذكر الترويسة أي خوارزمية وقّعته. وتحمل الحمولة المطالبات. وليس أيٌّ منهما مشفّراً — فترميز base64 ترميز نقل لا إخفاء، ومن يحمل الرمز يقرأ الاثنين في نحو ثانية.
والتوقيع وحده هو ما يؤدي عملاً أمنياً. فهو يثبت أن المقطعين الأولين أنتجهما من يملك مفتاح التوقيع وأنهما لم يُعدَّلا منذ ذلك الحين. ومن دون التحقق منه، لا يعدو JWT كونه ملفاً نصياً يصف نفسه، لا سلطة له تزيد على أي نص آخر أرسله إليك عميل.
ولهذا لن تخبرك هذه الصفحة بأن رمزاً ما صالح
التحقق يحتاج المفتاح، ولا توجد صيغة من صيغ نصيحة «الصق سرّ التوقيع لديك في صفحة ويب» تُعدّ نصيحة جيدة. وما تفعله الأداة بدل ذلك هو الإبلاغ عمّا يقوله الرمز عن نفسه: أانتهت صلاحيته، أحلّ وقت بدء سريانه، أخوارزميته متماثلة أم غير متماثلة، وأيدّعي أنه لا يحتاج توقيعاً أصلاً.
alg:none، ولماذا هي حالة معلِّمة
تسمح المواصفة بـ "alg": "none" — أي رمزاً بلا توقيع. والهجوم يكتب نفسه: خذ رمزاً شرعياً، وعدّل الحمولة لتدّعي ما شئت، واضبط الخوارزمية على none، واحذف التوقيع، ثم أرسله.
والمكتبة التي تقرأ الخوارزمية من الترويسة وتفعل ما تقوله ستقبل هذا. فالمهاجم هو من اختار سياسة التحقق، لأن السياسة كانت في الجزء الذي يسيطر عليه المهاجم من الرسالة.
والنسخة القريبة منها هي الخلط بين الخوارزميات. فالخادم الذي يتحقق بـ RS256 يملك المفتاح العام، وهو غير سرّي. غيّر الترويسة إلى HS256 — وهي خوارزمية متماثلة — ووقّع بذلك المفتاح العام بوصفه السرّ المشترك. فتستعمل مكتبة ساذجة مادة المفتاح نفسها في الحالتين، فيجتاز الرمز المزوَّر التحقق.
ويُصلَح الأمران بالطريقة نفسها، وهي مبدأ عام يستحق أن تحمله معك إلى غير هذا الموضع: على المتحقِّق أن يعلن أي الخوارزميات يقبل بدل أن يسأل الرمز.
ما الذي يعطب فعلاً في بيئة الإنتاج
| العَرَض | السبب المعتاد |
|---|---|
| يُرفض فور إصداره | انحراف الساعة. فـ iat أو nbf تسبق ساعة المتحقِّق ببضع ثوانٍ. اسمح بهامش صغير. |
| يعمل محلياً ويفشل بعد النشر | مفتاح توقيع مختلف لكل بيئة — رمز من بيئة الاختبار أُرسل إلى الإنتاج. |
| التوقيع صالح ومع ذلك يُرفض | مطالبة aud أو iss لا تطابق ما تتوقعه تلك الخدمة. |
| يعمل ثم يتوقف في منتصف الجلسة | انتهاء الصلاحية. فالرموز القصيرة العمر تحتاج تدفق تجديد، وهو الجزء الناقص عادةً. |
| تفشل الطلبات لأن الترويسات أكبر من اللازم | الرمز تجاوز الحدّ. فمعظم الخوادم تحدّ الترويسات عند نحو 8 كيلوبايت، وتحدّ المتصفحات الكعكة الواحدة عند 4 كيلوبايت. |
مشكلة الإبطال
سبب استعمال JWT أن التحقق لا يحتاج مراجعة قاعدة بيانات — فالرمز يحمل برهانه معه. وهذا بعينه سبب عجزك عن إبطاله. فلا شيء يُستشار وقت التحقق، ومن ثمّ لا موضع يُسجَّل فيه أن رمزاً ينبغي أن يكفّ عن العمل.
والخيارات، وما من واحد منها مجاني:
- صلاحية قصيرة مع رموز تجديد. الجواب المعياري. فرموز الوصول تعيش دقائق، ورموز التجديد تُراجَع في قاعدة بيانات ويمكن إبطالها.
- قائمة منع. أن تفحص
jtiكل رمز في مخزن للمبطَلة — وهذا يعيد المراجعة التي وُجدت الصيغة لتجنّبها. - تدوير مفتاح التوقيع. يُبطل كل الرموز دفعةً واحدة، بما فيها رموز الجميع.
فإن كانت حاجتك إلى إبطال جلسات بعينها فوراً أكبر من حاجتك إلى تحقق بلا حالة، فإن معرّف جلسة مبهماً مسنوداً بمخزن تصميمٌ أبسط، وهو مبخوس حقه.
ذات صلة
المقاطع الثلاثة كلها Base64 آمن في الروابط وبلا حشو — ولهذا كثيراً ما يفشل مقطع منها في فاكّ ترميز صارم. وبعد فكّ الترميز يكون الجزآن المقروءان JSON. أما بيانات الاعتماد التي ينوب عنها الرمز، فإن فاحص القوة يغطي الطرف الآخر من تسجيل الدخول.
أسئلة حول JWT
هل فكّ ترميز JWT يتحقق منه؟
لا، وهذا التمييز هو نموذج الأمان كله. فالترويسة والحمولة مرمّزتان بـ base64url، وقراءتهما لا تحتاج شيئاً. أما التحقق فيعني إعادة حساب التوقيع بالمفتاح ثم المقارنة، وهو ما يثبت أن الرمز صادر عمّن يملك ذلك المفتاح وأنه لم يُغيَّر منذ ذلك الحين. ففاكّ الترميز الذي لا يملك المفتاح يخبرك بما يدّعيه الرمز؛ أما هل تصدّقه فلا يقوله إلا التحقق.
هل من الآمن لصق رمز حقيقي في موقع إلكتروني؟
في هذه الصفحة نعم — إذ يجري فكّ الترميز في متصفحك ولا يُنقل شيء. لكن الحدس وراء السؤال سليم ويستحق البقاء. فرمز JWT عادةً بيانات اعتماد حيّة: من يحمله يستطيع التصرف نيابةً عنك حتى ينتهي أجله. وفاكّ الترميز الذي يرسله إلى خادم قد سُلّمت إليه جلسة عاملة. فتحقّق من مكان تنفيذ أي أداة قبل أن تلصق فيها رمزاً من بيئة الإنتاج.
هل أضع أسراراً في حمولة JWT؟
لا. فالحمولة موقّعة لا مشفّرة — يقرؤها كل من يحمل الرمز، بمن فيهم المستخدم الذي صدر له. والتوقيع يضمن أن المحتوى لم يتغير، ولا يفعل شيئاً لإخفائه. فإن كنت تحتاج حمولة سرية حقاً فذلك JWE، وهو مواصفة أخرى أعقد بكثير. وفي الممارسة العملية يكون الجواب الأفضل عادةً إبقاء الجزء الحساس على الخادم ووضع معرّف في الرمز.
ما هي ثغرة alg:none؟
تسمح مواصفة JWT بأن تكون قيمة «alg» هي «none»، أي رمزاً بلا توقيع. والهجوم أن تأخذ رمزاً صالحاً وتغيّر الحمولة لتدّعي صلاحيات المدير، وتضبط alg على none، وتحذف التوقيع. فالمكتبة التي تثق بحقل الخوارزمية في الترويسة ستعدّه صالحاً — إذ إن الرمز نفسه نصّ على ألا تحقق مطلوب. وقد رُقّعت كل المكتبات الكبرى، لكن الدرس أعمّ: الخادم هو من يقرر أي الخوارزميات يقبل، لا أن يترك الرمز يرشّح واحدة.
كيف أبطل رمز JWT قبل انتهاء أجله؟
لا تستطيع في الغالب، وهذه هي المقايضة التي تقوم عليها الصيغة. فرمز JWT قابل للتحقق دون مراجعة قاعدة بيانات، وهذا ما يجعله سريعاً — وهو نفسه سبب أن لا شيء يُستشار وقت التحقق يعلم أنك أردت إبطاله. والحلول العملية هي آجال قصيرة مع رموز تجديد، أو قائمة منع بالمعرّفات المبطَلة تُفحص مع كل طلب (وهذا يعيد المراجعة التي كنت تتجنبها)، أو تدوير مفتاح التوقيع لإبطال كل شيء دفعةً واحدة.
لماذا يُرفض رمزي وهو يبدو صالحاً؟
بعد انتهاء الأجل، الأسباب المعتادة هي انحراف الساعة بين المُصدِر والمُتحقِّق، أو مطالبة جمهور أو مُصدِر لا تطابق ما يتوقعه الخادم، أو أن يكون الرمز موقّعاً بمفتاح غير الذي يحمله المُتحقِّق — وغالباً ما يكون رمزاً من بيئة الاختبار استُعمل مع الإنتاج. والفاكّ أعلاه يؤشّر على مشكلات التوقيت التي يستطيع رؤيتها؛ أما عدم تطابق الجمهور والمفتاح فلا يخبرك به إلا الخادم.
آخر مراجعة . وجدت شيئاً لم يعد محدَّثاً؟ أخبِرنا.