أدوات المطور · التشفير ووحدة فك التشفير Base64
Base64 vs base64url: لماذا يرفض جهاز فك الترميز القياسي - و_
· كيف يعمل
base64 ترميز سير عمل المطور
يقوم Base64url بمبادلة + و / لـ - و _ حتى يتمكن الإخراج من الانتقال في عناوين URL وأسماء الملفات دون الهروب. يشرح هذا المنشور الحروف الهجائية، وكيفية التحويل بينهما وسبب إسقاط الحشو أيضًا.
الرمز المميز الذي يتم فك ترميزه في كل مكان باستثناء الكود الخاص بك - خطأ حرف غير صالح ناتج عن حرف واحد - أو _
فشل مقطع JWT في فك التشفير في وحدة فك ترميز Base64 القياسية مع وجود خطأ غير صالح في تسمية الشرطة. ولكن بصريا، لا تظهر أي شرطة. انظر مرة أخرى، إنه كذلك. يستخدم إصدار base64url - حيث يستخدم Base64 القياسي +، و_ حيث يستخدم /. تقبل العديد من أجهزة فك التشفير أبجدية واحدة فقط، وسيتم رفض الرمز المميز المشفر للسلامة URL بواسطة التعليمات البرمجية التي تتوقع RFC 4648 Base64 القياسي.
الحروف الهجائية متكافئة. التحويل بينهما هو استبدال الطابع الميكانيكي. تنشأ المشكلة لأن + و/ لهما معاني في عناوين URL. تمثل علامة الزائد المساحة في بيانات نموذج التطبيق /x-www-form-urlencoded. الشرطة المائلة للأمام هي فاصل المسار في URL. إذا قمت بتضمين Base64 مباشرة في معلمة الاستعلام URL بدون ترميز النسبة المئوية + ووحدة فك الترميز /, فقد يخطئ في تفسيرها.
لماذا يمثل + و/ مشكلة في عناوين URL وأسماء الملفات - المعنى المحجوز لـ / في المسارات و+ كمسافة في بيانات النموذج
يمكن قراءة A + كمساحة قبل الوصول إلى وحدة فك التشفير. يمكن لـ / تقسيم قيمة المعلمة في مكان خاطئ. RFC 4648 القسم 5 يحدد أبجدية base64url لإزالة الغموض: استخدم - بدلاً من + و_ بدلاً من /, بحيث يكون الإخراج آمنًا في عناوين URL وأسماء الملفات. الحروف الهجائية متطابقة باستثناء حرفين.
يستخدم Base64 القياسي الأحرف في المواضع 62 و63: A–Z (0–25)، a–z (26–51)، 0–9 (52–61)، + (62)، / (63). يستخدم base64url A–Z (0–25)، a–z (26–51)، 0–9 (52–61)، - (62)، _ (63). كل شيء آخر - إعادة تجميع البتات، وقواعد الحشو، وتعيين البتات إلى المؤشرات - هو نفسه. ستنتج سلسلة المؤشرات الخاصة بـ Base64 القياسي سلسلة من المؤشرات الخاصة بـ base64url؛ الحرف الوحيد الموجود في الموضعين 62 و63 سيختلف.
الأبجدية base64url من RFC 4648 القسم 5 - الحرفان المستبدلان ولماذا لا يتغير شيء آخر
إذا كان الإدخال لا يحتوي على مؤشرات 62 أو 63 (no + أو / في المعيار، no - أو _ في base64url)، فإن كلا الحروف الهجائية تنتج مخرجات متطابقة. يعد تحويل Base64 القياسي إلى base64url عملية بحث واستبدال مباشرة: مبادلة + لـ - و / لـ _. يتطلب فك تشفير سلسلة base64url في Base64 القياسي عكسًا: المبادلة - لـ + و_ لـ /.
التحويل متماثل وصالح دائمًا. إذا واجهت رمزًا مميزًا فشل في فك التشفير مع تسمية خطأ بأحرف غير صالحة - أو _، فتحقق مما إذا كانت وحدة فك الترميز تقبل base64url. إذا لم يكن الأمر كذلك، فقم بتطبيق استبدال الأحرف، وإذا كان الإدخال جيدًا، فيجب أن ينجح فك التشفير. خذ بعين الاعتبار JWT الرأس {"alg":":HS256"، "typ": "JWT"} المشفر كـ base64url. تمر البايتات القياسية UTF-8 بإعادة تجميع البتات: تصبح ثلاث بايتات أربعة مؤشرات، ويتم البحث عنها بأبجدية base64url. ToolAcre يعرض الحشو كخيار تشفير بدلاً من ربطه بالتبديل الأبجدي. يعد هذا الفصل دليلًا مفيدًا: URL- قد يكون الإخراج الآمن مبطنًا أو غير مبطن، بينما تقوم وحدة فك التشفير بتطبيع أي من النموذجين قبل استدعاء المتصفح البدائي. الأبجدية والحشو عبارة عن اتفاقيات مرتبطة، وليس مفتاحًا واحدًا.
يعد الحشو في base64url اختياريًا حسب التقليد - لماذا تحذف JWTs = وكيف يمكن لجهاز فك التشفير استعادته من الطول
عندما يكون الفهرس 62، فإن حرف الإخراج هو -؛ عندما يكون 63، يكون الإخراج _. البايتات المتطابقة من خلال الأبجدية القياسية ستنتج + في الفهرس 62 و/ في الفهرس 63. تحويل نتيجة base64url إلى قياسي هو عملية حرف بحرف: امسح بحثًا عن - واستبدل بـ +، وابحث عن _ واستبدل بـ /, ثم فك التشفير كالمعتاد.
البايتات التي تستردها متطابقة لأن الفهارس كانت متطابقة؛ تختلف الرموز فقط. يعد الحشو في base64url اختياريًا وفقًا للاتفاقية، على الرغم من أن المعيار يسمح بذلك. يتم تنظيم JWTs على شكل ثلاثة قطاعات base64url مرتبطة بالنقاط؛ يستخدم كل مقطع الحشو إذا لزم الأمر، ولكن العديد من التطبيقات تحذفه وتعتمد على حقيقة أن التطبيق المستهلك يعرف طول البايت المتوقع.
مثال عملي: تحويل مقطع رأس JWT إلى Base64 القياسي - استبدال الأحرف وإضافة الحشو وفك التشفير إلى JSON
يمكن لجهاز فك التشفير استعادة الحشو المفقود عن طريق قسمة طول السلسلة على أربعة، أو حساب الباقي، أو إلحاق 0، أو 1، أو 2 بعلامات يساوي. إذا لم يكن طول السلسلة مضاعفًا للأربعة، فهذا يعني أن الحشو مفقود. إذا كان الطول مضاعفًا لأربعة، فإما أن تكون السلسلة مبطنة ثم يتم تجريد الحشوة، أو يتم إدخال عدة بايتات بالفعل (تنتهي بثلاث بايتات في الكتلة النهائية، ولا تحتاج إلى حشوة).
يتطلب تسلسل مقاطع base64url الانتباه إلى الحشو. إذا كانت كل ثلاثة أجزاء تنتهي بـ =، فإن التسلسل المباشر ينتج سلاسل مثل AAAA=BBBB=CCCC=، حيث أصبحت الحشوة في المنتصف الآن عبارة عن أحرف ضالة، وليست علامات إنهاء. هذا هو السبب في أن JWTs تحذف الحشو في كل مقطع: البنية المكونة من ثلاثة أجزاء صريحة، لذلك يستمر فك التشفير بشكل مستقل في كل جزء، والحشو داخل منتصف السلسلة المتسلسلة غير ضروري وقد يؤدي إلى انقطاع التحليل.
الأخطاء الشائعة - خلط الحروف الهجائية في سلسلة واحدة، أو Base64 القياسي للترميز النسبي بدلاً من استخدام base64url
في حالة إنشاء حمولة متعددة المقاطع، حدد تقليد الحشو في البداية: إما تضمينه في كل مقطع وعدم ربطه مباشرة، أو حذفه واستعادته من الطول فقط عند فك التشفير. RFC 4648 المعيار هو السلطة في كلتا الأبجديتين. يحدد القسم 4 معيار Base64؛ يحدد القسم 5 عنوان URL الأساسي64. يجب أن يذكر كل جهاز فك ترميز مطابق بوضوح الأبجدية التي يقبلها.
الكود الذي يقبل base64url ولكن ليس Base64 القياسي (أو العكس) ينفذ المجموعة الفرعية فقط. توجد أبجدية base64url للتوافق مع URL وقيود اسم الملف؛ إنه ليس تحسينًا أو استبدالًا، بل مجرد تغيير لسياق محدد. عندما تقوم بتأليف API أو تنسيق الرمز المميز، اختر أبجدية واحدة وقم بتوثيق أي منها. من الأخطاء الشائعة ترميز النسبة المئوية Base64 القياسي بدلاً من استخدام base64url. يشرح التنفيذ أيضًا حدود المقالة. فهو يقوم بتطبيع الواصلة والشرطة السفلية قبل فك التشفير، لكنه لا يتحقق من توقيع الرمز المميز أو يفسر المطالبات. يمكن أن يؤدي تحويل مقطع JWT إلى بايت إلى الكشف عن JSON؛ لا يمكن تحديد من أصدر ذلك JSON أو ما إذا كان أي شخص قد قام بتغييره.
ما لا يغطيه هذا - التحقق من توقيعات JWT وbase32 وترميزات RFC 4648 الأخرى
%2B هو رمز النسبة المئوية لـ +؛ %2F هو رمز النسبة المئوية لـ /. يحول ترميز النسبة المئوية TWFu إلى TWFu بدون تغيير (بدون أحرف خاصة) ولكن TE9S+g== إلى TE9S%2Bg%3D%3D (عدد كبير جدًا من الأحرف التي لا يمكن التعامل معها). الحل الصحيح هو استخدام base64url، الذي ينتج مخرجات آمنة URL بالفعل. يعتبر ترميز النسبة المئوية Base64 غير ضروري ومهدرًا. استخدم الأبجدية الصحيحة للسياق. يقبل جهاز التشفير ووحدة فك التشفير Base64 كلا الحروف الهجائية تلقائيًا.
إذا قمت بلصق سلسلة تحتوي على -، فسيتم التعامل معها على أنها base64url؛ إذا قمت بلصق سلسلة تحتوي على +، فسيتم التعامل معها على أنها Base64 القياسي. تقبل الأداة أيضًا عناوين URL وتتعامل معها على أنها URL-إدخال آمن. وبالتالي فإن الفحص العملي له نتيجتان مستقلتان: البايتات ذهابًا وإيابًا، والتمثيل المختار يناسب قناته. تمرير الأول يقول أن التحول قابل للعكس. يؤدي تمرير الثانية إلى عدم إعادة كتابة علامات الترقيم والحشو بواسطة URL أو اسم الملف أو ملف تعريف الارتباط أو البروتوكول الذي يحملها.
الوجبات الجاهزة: أبجديتان، تخطيط بت واحد - كيف يتعامل جهاز التشفير ووحدة فك التشفير Base64 مع الأبجدية القياسية في المتصفح، وحيث توضح صفحة الأداة الخاصة به ما يقبله
عند فك تشفير مقطع JWT أو URL-الرمز الآمن، يمكنك اللصق مباشرة دون تحويل، وتحدد الأداة الأبجدية من السياق. يصبح تصحيح أخطاء فك التشفير الفاشل أمرًا بسيطًا: قم بلصق الرمز المميز، ومعرفة ما إذا كانت الأداة تقبله، وإذا لم يكن الأمر كذلك، فقم بتبديل الأحرف يدويًا وحاول مرة أخرى.
الاستبدال نفسه عبارة عن سطر واحد من التعليمات البرمجية، ولكن يمكن أن يأتي فك التشفير الفاشل أيضًا من طول مستحيل أو حشوة في غير مكانها أو تلف أو إدخال غير Base64. تقوم الأداة بتسوية كلا الحروف الهجائية تلقائيًا، لذلك يؤكد القبول فقط أنه يمكن استرداد وحدات البايت. تظل الحمولة النافعة JWT التي تم فك تشفيرها مطالبة غير موقعة حتى يتحقق مدقق منفصل من توقيعها والخوارزمية المتوقعة.