لماذا يعتبر فك تشفير JWS هو نقطة الدخول فقط
في بنية الهوية الحديثة - خاصةً OAuth 2.0 و OpenID Connect - كثيراً ما يتم التعامل مع الرموز الموقعة على أنها "حاويات موثوقة" يمكن تمريرها بين الخدمات. ولكن بالنسبة لمهندسي الأمن والباحثين في الفريق الأحمر والباحثين في مجال أمن الذكاء الاصطناعي، يتم فهم الرموز الموقّعة بشكل أفضل على أنها مدخلات مدمجة يتحكم فيها المهاجمون وتقع عند تقاطع التشفير ومنطق الأعمال. القدرة على إجراء فك تشفير توقيع الويب json ليس هو الهدف؛ بل هي الأداة التي تتيح لك التفكير في ماهية المُحقِّق يعتقد يتم التحقق من صحة ماهية التطبيق في الواقع التي يعتمد عليها في التفويض، وأجزاء الرمز المميز التي يتم التعامل معها على أنها تكوين وليس بيانات غير موثوق بها.
هذا التمييز مهم لأن "أمان الرمز المميز" ليس خاصية من خصائص تنسيق الرمز المميز. إنها خاصية من خصائص خط أنابيب التحقق والتحقق من صحة المطالبات-اختيار الخوارزمية، واختيار المفتاح، والتحقق من المُصدر/الجمهور، والمطالبات المستندة إلى الوقت، والأهم من ذلك، كيفية استخدام الرمز النهائي للمطالبات بمجرد حصوله عليها. في اللحظة التي يتعامل فيها النظام مع المطالبات التي تم فك تشفيرها على أنها "حقيقة" قبل اكتمال التحقق (أو حتى تشغيلها)، يتوقف الرمز المميز عن كونه حدًا أمنيًا ويصبح معلمة يتحكم فيها المستخدم.
الهندسة وراء السلسلة Base64url بدون حشو
عندما يقول الناس "فك تشفير JWS"، ما يفعلونه عادةً هو عكس خطوة ترميز base64url. في JWS Compact Serialization، كل مقطع من المقاطع الثلاثة يتم ترميزه بترميز base64url، باستخدام الأبجدية الآمنة لعناوين URL وعادةً ما يتم حذف = الحشو. يعرّف RFC 7515 التنسيق المضغوط ويستخدم صراحةً BASE64URL(...) لبناء الرأس والحمولة، ثم يتسلسل مع . الفواصل. (محرر RFC)
يبدو اصطلاح "عدم وجود حشو" ثانويًا حتى تقوم ببناء أدوات أو تحليل حركة المرور الملتقطة على نطاق واسع. تفترض العديد من إجراءات base64 العامة وجود الحشو وستقوم إما بإلقاء أخطاء أو إنتاج مخرجات غامضة عندما يكون الحشو مفقودًا. يجب على أداة فك التشفير القوية أن تعيد إضافة الحشو بشكل حتمي وأن تستخدم روتين فك تشفير مدرك لقاعدة 64، وإلا سيصبح تحليلك غير قابل للتكرار - خاصةً عندما تتعامل مع رموز مشوهة أو تالفة عمدًا أثناء التشويش.
JWS مقابل JWT: ما الذي تعنيه كل نقطة في الواقع
دائمًا ما يكون رمز JWS المدمج:
BASE64URL(الرأس) . BASE64URL(الحمولة) . BASE64URL(التوقيع)
هذا الجزء الثالث ليس "سداسي عشري". إنه قاعدة 64url من بايتات التوقيع (أو MAC). تعامل معها على أنها مبهمة إلا إذا كنت تتحقق أو تقوم بفرز التشفير.
JWT (RFC 7519) هو اصطلاح مجموعة المطالبات التي يتم حملها عادةً داخل حمولة JWS، ولهذا السبب يخلط الناس عرضًا بين "JWT" و "JWS". يعرّف RFC 7519 المطالبات المسجلة مثل إيسيس, الفرعية, التدقيق, انتهاء الصلاحيةو ن.ب.ف، ويصف كيفية تمثيل هذه المطالبات ككائن JSON. (IETF Datatracker بيانات IETF)
عملياً، هذا يعني عملياً أن خطوة فك التشفير فقط يمكن أن تخبرك ما هو الرمز المميز المطالبات، ولكن لا يمكن أن يخبرك ما إذا كانت هذه الادعاءات صحيح. لا تصل الحقيقة إلا بعد نجاح التحقق من صحة التوقيع والتحقق من صحة المطالبة.
الرأس هو سطح الهجوم: زئبق, طفل, جكو كمدخلات غير موثوق بها
في الأنظمة المصممة بشكل جيد، يكون رأس الرمز المميز عبارة عن بيانات وصفية تساعد المدقق على اختيار استراتيجية تحقق معروفة جيدة. في الأنظمة سيئة التصميم، يصبح الرأس قناة تهيئة يتحكم فيها المهاجم. لهذا السبب، أثناء فك تشفير توقيع الويب json، يركز العديد من المحترفين على الرأس أولاً.
إن زئبق حساسة بشكل خاص لأنها يمكن أن تؤثر على طريقة التحقق التي يتم استدعاؤها. يحدث ارتباك الخوارزمية (يُطلق عليه أيضًا ارتباك المفتاح) عندما يتمكن المهاجم من إجبار الخادم على التحقق من JWT باستخدام خوارزمية مختلفة عن تلك التي قصدها المطور، مما قد يؤدي إلى تمكين الرموز المزورة دون معرفة مفتاح توقيع الخادم. تصف أكاديمية PortSwigger لأمن الويب هذه الفئة بوضوح وتربطها بسوء التهيئة أو التعامل الخاطئ مع خيارات الخوارزمية. (بورت سويجر)
إن طفل المعلمة ليست تشفيرًا؛ إنها استرجاع المفتاح. إذا كان طفل يؤثر على مسارات الملفات، أو استعلامات قاعدة البيانات، أو مفاتيح ذاكرة التخزين المؤقت، أو المحاليل الديناميكية دون قائمة سماح صارمة، يصبح سطح حقن عام داخل حدود إدارة المفاتيح.
إن جكو تكون المعلمة أكثر خطورة عند إساءة استخدامها. إذا قام أحد الخوادم بجلب JWKS من عنوان URL المحدد من رأس الرمز المميز (أو من متغير غير مقيد بشكل كافٍ)، يمكن للمهاجم محاولة استبدال مرساة الثقة من خلال توجيه المدقق إلى المفاتيح التي يتحكم فيها المهاجم. حتى عندما يقوم النظام "بالجلب من HTTPS فقط"، فإن غياب قوائم سماح صارمة، وربط المصدر، وسياسة التخزين المؤقت، ومسارات التدقيق، يحول استرجاع المفتاح إلى مشكلة في سلسلة التوريد، وليس مشكلة تشفير.
وحدة فك ترميز غير متصلة بالإنتاج في بايثون (فك التشفير فقط، آمنة من الحشو)
تعتبر مصححات الرموز الرمزية المستندة إلى الويب مريحة، لكنها غالبًا ما تكون فكرة سيئة في العمل الأمني الاحترافي. يمكن أن تحتوي الرموز على معرّفات حساسة، أو رسائل بريد إلكتروني، أو معرّفات المستأجرين الداخلية، أو حتى معلومات التعريف الشخصية المضمنة. أنت تريد أدوات غير متصلة بالإنترنت وقابلة للبرمجة البرمجية تكون حتمية وآمنة حول المدخلات المشوهة. لا "يتحقق" التطبيق أدناه عن قصد من أي شيء؛ فهو يفك تشفير ما هو موجود فقط ويجعل أوضاع الفشل قابلة للملاحظة.
استيراد base64
استيراد json
من الكتابة استيراد Any, Dict, Tuple, Tuple, Optional
def _b64url_decode(data: str) -> بايت:
# RFC 7515 RFC 7515 base64url عادةً ما يحذف الحشو "=" ؛ استعادتها بشكل حتمي.
الحشو = (-Len(data)) % 4
إرجاع base64.urlsafe_b64decode((data + "=" * pad).encode("ascii"))
تعريف _parse_json(b: بايت) -> Tuple[اختياري[Dictal[Dictal[str, Any]], اختياري[str]]:
حاول
إرجاع json.loads.loads(b.decode("utf-8"))، لا شيء
باستثناء استثناء ك e:
إرجاع لا شيء، و"{نوع (e)._name____}: {e}"
def jws_decode(token: str) -> Dict[str, Any]:
الأجزاء = token.split(".")
إذا كان len(parts) != 3:
إرجاع {"خطأ": "تنسيق مضغوط غير صالح ل JWS (متوقع 3 أجزاء)."، "الأجزاء": len(parts)}
header_b = _b64url_decode(parts[0])
الحمولة_ب = _b64url_decode(parts[1])
الرأس، هو = _parse_json(header_b)
الحمولة، pe = _parse_json(payload_b)
خارج: Dict[str, Any] = {
"header_raw": header_b.decode("utf-8"، أخطاء="استبدال"),
"payload_raw": payload_b.decode("utf-8"، أخطاء="استبدل")، "payload_b.b.decode("utf-8")، أخطاء="استبدل"),
"signature_b64url_sample": أجزاء[2][:16] + "..."
}
إذا لم يكن الرأس لا شيء
خارج["الرأس"] = الرأس
غير ذلك
خارج["رأس_خطأ"] = هو
إذا كانت الحمولة ليست لا شيء
خارج["الحمولة"] = الحمولة
غير ذلك
خارج["payload_error"] = pe
إرجاع
يتماشى هذا مع استخدام RFC 7515 لـ RFC 7515 base64url (وحقيقة أن JWS المدمجة مصممة لسياقات عناوين URL/رؤوس بروتوكول نقل النص المكتوب (HTTP)، بينما تمنحك سلوكًا مستقرًا عندما يكون الرمز المميز مشوهًا أو مبتورًا أو مشوشًا عن قصد. (محرر RFC)
الفجوة الحرجة: فك التشفير مقابل التحقق (ونمط الخطأ الحقيقي)
أكثر مغالطة أمنية مستمرة حول JWS/JWT هي الخلط بين فك التشفير والتحقق. فك التشفير هو تنسيق قابل للعكس؛ والتحقق هو التحقق من صحة التشفير بالإضافة إلى تطبيق السياسة.
في الحوادث الحقيقية، يكون نمط الفشل الشائع هو "الاستخدام قبل التحقق" بدلاً من السباق الحرفي. يقوم التطبيق بفك تشفير الرمز المميز، ويقرأ الدور, المستخدم_المعرف, المستأجرأو النطاقويتخذ قرارات التفويض قبل أن يتم فرض التحقق من التوقيع والتحقق من صحة المطالبات بشكل قاطع. تسلط إرشادات OWASP حول اختبار JWT الضوء على كيفية أن سوء التعامل مع توقعات الخوارزمية ومنطق التحقق يتيح شن هجمات عالية التأثير، بما في ذلك الخلط بين تدفقات التحقق غير المتماثلة والمتماثلة. (مؤسسة OWASP)
حتى لو كان التوقيع صالحًا، يظل الرمز المميز بحاجة إلى التحقق من صحة المطالبة. يعرّف RFC 7519 التدقيق كمطالبة الجمهور، ويلاحظ أنه إذا لم يُعرّف المدير الذي يعالج الرمز المميز نفسه كجمهور مقصود، فيجب رفض الرمز المميز عند التدقيق موجودة. (IETF Datatracker بيانات IETF) هذا تذكير بأن صحة التشفير لا تعادل صحة السياق.
الاستغلال المتقدم: ما بعد "alg: لا شيء"
رواية "alg: لا شيء" مهمة تاريخيًا، لكن معظم المكتبات الحديثة تحظرها افتراضيًا. تميل الإخفاقات الأكثر إثارة للاهتمام اليوم إلى الوقوع في مجموعتين: عيوب التنفيذ في مزودي التشفير، والتجاوزات المنطقية المعقدة الناجمة عن خطوط أنابيب التحقق المرنة.
التواقيع النفسية (CVE-2022-21449): عندما يكذب التحقق من ECDSA
CVE-2022-21449 -المعروفة باسم "التوقيعات النفسية"- هي ثغرة خطيرة في تشفير جافا حيث يمكن تجاوز التحقق من توقيع ECDSA في ظل ظروف معينة في إصدارات جافا المتأثرة (تم تقديمها بشكل خاص في Java 15 وتم إصلاحها في وحدة المعالجة المركزية لشهر أبريل 2022). تؤكد التحليلات على مدى إضعافه بشكل كبير للأنظمة التي تعتمد على توقيعات ECDSA، بما في ذلك السيناريوهات التي تتضمن توقيعات ECDSA الموقعة من ECDSA JWTs أو آليات WebAuthn. (نيل مادن)
الدرس الأكثر أهمية لأمن الرمز المميز ليس ذكاء التجاوز؛ بل الواقع التشغيلي الذي يقول "اخترت ES256" ليس ضمانًا. إن إصدار وقت التشغيل، وتطبيق مزود الأمان، وحالة التصحيح هي جزء من نموذج التهديد الخاص بك. يجب أن تتعامل فرق الأمان مع "انحدارات مزود التشفير" على أنها مخاطر من الدرجة الأولى، مع اتفاقيات مستوى الخدمة الصريحة للتصحيح واختبارات الانحدار التي تمارس التحقق من التواقيع المشوهة.
ارتباك الخوارزمية / ارتباك المفاتيح: عندما يسمح الخادم للخادم باختيار القواعد
تحدث هجمات الخلط بين الخوارزميات عندما يسمح المدقق للرمز المميز بالتأثير على الخوارزمية المستخدمة للتحقق، ولا يتم الفصل في معالجة المفاتيح بشكل نظيف بين الوضعين غير المتماثل والمتماثل. يلاحظ PortSwigger أنه إذا لم يتم التعامل مع هذه الحالة بشكل صحيح، فقد يقوم المهاجمون بتزوير JWTs صالحة تحتوي على قيم عشوائية دون معرفة مفتاح التوقيع السري للخادم. (بورت سويجر)
من الناحية العملية، فإن الدفاع بسيط من الناحية المفاهيمية ولكن كثيراً ما يتم إغفاله: لا تسمح أبداً بـ "خوارزمية خفة الحركة" عند الحدود التي يتم فيها اتخاذ قرارات المصادقة. إذا كانت خدمتك تتوقع RS256، فأنت تفرض RS256. أنت لا "تقبل أي خوارزمية موجودة في الرأس وترى ما إذا كان سيتم التحقق من صحتها."
استرداد المفتاح المستند إلى الرأس: طفل/جكو كسلسلة إمدادات التحقق
بمجرد قبولك أن الرأس هو مدخلات المهاجم، فإنك تقبل أيضًا أن اختيار المفتاح هو جزء من سطح الهجوم. A طفل يجب أن ترتبط بقائمة مفاتيح محددة مسبقًا من المفاتيح، وليس بمواد مفاتيح عشوائية يتم جلبها أو تحميلها أو إنشاؤها في وقت التشغيل. A جكو يجب ألا تسمح أبدًا لرمز رمزي بإعادة تحديد مصدر ارتساء الثقة. إذا كنت تدعم جلب JWKS لـ OIDC، فيجب أن يكون مرتبطًا بتكوين مصدر موثوق به ومقوى بقوائم السماح والتخزين المؤقت والمراقبة.
استراتيجيات التقوية التي تنجو من انجراف الإنتاج
يميل نهج الدفاع في العمق للتحقق من صحة نظام الإنذار المشترك إلى أن يبدو مملاً على الورق، ولكنه بالضبط ما يمنع غالبية حالات فشل الرموز.
تقوم بتثبيت الخوارزميات المقبولة صراحةً وتطلب من المدقق فرض استخدام الخوارزمية المتوقعة. تشير إرشادات OWASP الخاصة بـ JWASP لـ Java إلى هذه النقطة مباشرةً كإجراء وقائي. (سلسلة أوراق غش OWASP)
يمكنك التحقق من صحة المصدر والجمهور باستمرار. إن تعريفات RFC 7519 للمطالبات المسجلة ليست أكاديمية؛ فهي موجودة لأن "توقيع صحيح، سياق خاطئ" هي فئة شائعة من حالات الفشل. على وجه الخصوص، عدم تطابق الجمهور هي واحدة من أسهل الطرق لقبول رمز تم سكه عن طريق الخطأ لخدمة مختلفة. (IETF Datatracker بيانات IETF)
أنت تتعامل مع معرّفات المفاتيح كبيانات، وليس كاستعلام بحث. A طفل يجب أن يتم حلها من خلال تعيين محدود - اسم مستعار لنظام إدارة المحتوى، أو سجل مفاتيح ثابت، أو مخزن مفاتيح محكم التحكم - وليس مسار نظام ملفات أو استعلام قاعدة بيانات مبني من مدخلات غير موثوق بها.
يمكنك تصحيح أوقات تشغيل التشفير بقوة واختبارها ضد الفئات الكارثية المعروفة. يوجد CVE-2022-21449 كتذكير بأن "الاختيار الصحيح للخوارزمية" لا يمكن أن يعوض عن تطبيقات التحقق المعطلة. (نيل مادن)
تقوم بمراقبة الحالات الشاذة التي تشير إلى وجود اختبار نشط. كميات كبيرة من أخطاء الحشو الأساسية64url، أو الرموز غير الصالحة المتكررة، أو ارتفاع معدل التكرار في طفل يمكن أن تشير القيم إلى محاولات تشويش أو تشويش مستمرة. لن تعمل المراقبة على إصلاح الخطأ، ولكنها يمكن أن تقلل من وقت الاكتشاف وتساعدك على ربط النشاط المشبوه بنقاط نهاية ومُدقِّقين محددين.
أتمتة التدقيق المنطقي للتحقق: أين يمكن أن يكون Penligent مناسبًا
في البيئات الحقيقية، لا يكمن الجزء الصعب في فك تشفير الرمز المميز مرة واحدة. إنه اكتشاف أين يتم قبول الرموز المميزة، وتحديد الخدمات التي تطبق قواعد التحقق، وإثبات ما إذا كان التفويض النهائي يعتمد على المطالبات التي تم فك تشفيرها قبل الأوان. هذه الحلقة "فك التشفير ← التفسير ← التفسير ← التحويل ← التحقق من صحة الأثر" هي حلقة متكررة، وهي بالضبط نوع العمل الذي يمكن أن تساعد منصات الأمان الحديثة المدعومة بالذكاء الاصطناعي في تصنيعه.
يمكن وضع منصة مثل Penligent بشكل موثوق به كطبقة أتمتة للاختبار المرتكز على الرموز: يمكنها إجراء فك تشفير دون اتصال بالإنترنت لتصنيف الرموز واستخراج حقول عالية الإشارة (المُصدر، والجمهور، والنطاقات، والأدوار)، واستنتاج حزم التحقق المحتملة من سلوك الاستجابة وبصمات الخدمة، ثم اختبار منهجي لفشل قائمة السماح بانحراف السياسات، وعدم اتساق تطبيق المُصدر/الجمهور عبر الخدمات المصغرة، وأنماط اختيار المفاتيح غير الآمنة. لا تكمن القيمة في "الرموز السحرية المكسورة"، بل في توليد الأدلة القابلة للتكرار والتحقق المستمر من الانحدار الذي يكشف عن انحدارات التحقق الدقيقة قبل أن يتم شحنها.
إذا كنت تتعامل مع التحقق من JWS كحدود واجهة برمجة التطبيقات ذات الأهمية الأمنية، فإن سير العمل القائم على الذكاء الاصطناعي يكون أكثر قوة عندما يساعدك على ضمان بقاء هذه الحدود متسقة عبر الإصدارات والبيئات ومالكي الخدمات.
الخاتمة
الأمر إلى فك تشفير توقيع الويب json هو خط البداية وليس خط النهاية. يمنحك فك التشفير إمكانية المراقبة، لكن الأمان يأتي من التحقق الصارم والتحقق من صحة المطالبات، والإدارة المنضبطة للمفاتيح، والنظافة الصحية المرنة في وقت التشغيل.
بدءاً من الإخفاقات الكارثية لمزود التشفير مثل "التوقيعات النفسية" (CVE-2022-21449) إلى الارتباك في الخوارزمية ومخاطر سلسلة التوريد الرئيسية التي تحركها الرؤوس، فإن أمن أنظمة JWS هو خاصية نظام. يمكن للفرق التي تجمع بين التحليل اليدوي الدقيق والأتمتة التي تكتشف انحراف التحقق أن تحافظ على قوة طبقات المصادقة الخاصة بها - حتى مع تطور الأنظمة البيئية وظهور أنماط فشل جديدة.
مصادر موثوقة ومزيد من القراءة
RFC 7515: توقيع الويب JSON (JWS). (محرر RFC)
RFC 7519: رمز الويب الرمزي JSON (JWT). (IETF Datatracker بيانات IETF)
PortSwigger: هجمات الارتباك الخوارزمية. (بورت سويجر)
OWASP WSTG: اختبار رموز الويب JSON. (مؤسسة OWASP)
ورقة غش OWASP: رمز JSON Web Token لـ Java. (سلسلة أوراق غش OWASP)
نيل مادن التوقيعات النفسية في جافا (نيل مادن)
تحليل JFrog لـ CVE-2022-21449 (الضفدع)
شرح تشفير CVE-2022-21449. (كريبتوماثيك)
