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

التحكم في الوصول الحديث يعيش ويموت على الرموز المميزة المستندة إلى JSON. عندما تفحص رمز وصول OAuth، أو رمز معرّف OpenID Connect، أو جلسة عمل واجهة برمجة تطبيقات موقّعة، فأنت عادةً ما تنظر إلى توقيع الويب JSON (JWS) البنية. سوف ترسل محركات البحث العديد من الأشخاص إلى أدوات "فك تشفير توقيع الويب json" التي يبدو أنها تحوّل السلاسل المبهمة بطريقة سحرية إلى JSON قابلة للقراءة.

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

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

ما هو توقيع الويب JSON Web Signature بالفعل

وفقًا لمواصفات JWS، يمثل توقيع الويب JSON Web Signature محتوى اعتباطيًا محميًا إما بتوقيع رقمي أو MAC، باستخدام هياكل تستند إلى JSON. وهو يوفر التكامل والموثوقية لتسلسل من البايتات، بغض النظر عما تمثله تلك البايتات. (IETF Datatracker بيانات IETF)

من الناحية العملية، في معظم الأحيان، يكون تسلسل البايت هذا في معظم الأحيان عبارة عن كائن JSON من المطالبات - وهو ما نسميه رمز JSON Web Token (JWT). يتم تعريف JWS نفسها في [RFC 7515]، بينما JWT في معيار شقيق يركز على كيفية هيكلة تلك المطالبات وتفسيرها. (متوسط)

يبدو الشكل المدمج المألوف هكذا:

eyJJhbGciGIOiJSUzI1NiIsInR5cCICI6IkpXVCJ9
eyJjzdWIWIIOIOIxMjMjM0Iwic2NvcGUIOlsicmVhZCIISIndyaXRlIl0sImV4cCI6MTczNDkxMjAwMH0.
ODU5Y...signature-bytes-here....

من الناحية النظرية، هي عبارة عن ثلاثة أجزاء مشفرة بترميز Base64URL موصولة بنقاط:

تقوم عملية فك تشفير توقيع الويب json، سواء تم تنفيذها بواسطة أداة عبر الإنترنت أو في البرامج النصية الخاصة بك، بعكس ترميز Base64URL للجزأين الأولين فقط وتطبع JSON بشكل جميل. إنها تقوم بما يلي لا إثبات صحة التوقيع ما لم تقم الأداة صراحةً بإجراء التحقق باستخدام مفتاح معروف ومجموعة خوارزميات مقيدة. (developer.pingidentity.com)

كيفية عمل أدوات فك تشفير توقيع الويب json فعلياً

تقوم معظم أدوات فك تشفير JWT / JWS - مثل أدوات المطورين الشائعة المستخدمة في المتصفحات أو ملاعب الويب - بتنفيذ نفس الحد الأدنى من خط الأنابيب:

1. تقسيم على النقاط إلى ثلاثة أجزاء.
2. Base64URL-فك تشفير أول جزأين.
3. تحليلها على هيئة JSON للرأس والحمولة.
4. إذا تم توفير مفتاح التحقق، قم بإعادة حساب التوقيع باستخدام الخوارزمية المعلن عنها في الرأس وقارن مع الجزء الثالث. (developer.pingidentity.com)

من من منظور مهندس أمني، تعتبر الخطوات من 1-3 آمنة بما فيه الكفاية للتحليل دون اتصال بالإنترنت؛ أما الخطوة 4 فهي التي تختبئ فيها معظم الثغرات الأمنية.

الحد الأدنى من مقتطف فك تشفير بايثون

إليك مقتطفًا بسيطًا متعمدًا لفك التشفير فقط في Python، وهو مفيد عندما تبحث في الرموز التي تم التقاطها أثناء اختبار خماسي:

استيراد base64
استيراد json

def b64url_decode(data: str) -> بايت:
    معالجة حشو # JWT الحشو #
    الحشو = '=' * (-Len(data) % 4)
    إرجاع base64.urlsafe_b64decode(data + padding)

تعريف decode_jws(token: str):
    header_b64, payload_b64, signature_b64 = token.split('.')
    header = json.loads.loads(b64url_decode(header_b64))
    الحمولة = json.loads.loads(b64url_decode(payload_b64))
    إرجاع الرأس، الحمولة، الحمولة، التوقيع_b64

jws = "eyJhbGciOciOiJSUzI1Ni1NiIsInR5cCCI6IkpXVCJ9...."
h, p, sig = decode_jws(jws)
طباعة("رأس:"، ح)
طباعة("الحمولة:", p)

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

مقتطف Node.js مع التحقق

بمجرد تجاوز مرحلة فك التشفير إلى مرحلة التحقق، تصبح كل التفاصيل مهمة:

استيراد jwt من "jsonwebtoken";
استيراد fs من "fs";

const publicKey = fs.readFileSync("public.pem", "utf-8");

دالة التحقق من Jws(الرمز المميز) {
  // حاسم: تأمين الخوارزميات المدعومة صراحةً
  إرجاع jwt.check(token, publicKey, {
    الخوارزميات: ["RS256"],
  });
}

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

فك التشفير غير ضار، والثقة بالبيانات التي تم فك تشفيرها ليست ضارة

يظهر نمط يظهر مرارًا وتكرارًا في تقارير الحوادث ومكافحة التطرف العنيف: يتعامل المطورون مع فك الشفرة بيانات JWT / JWS كما لو كانت بالفعل تم التحقق. تؤكد العديد من الكتابات الحديثة لمشكلات أمان JWT على أن فك تشفير Base64URL أمر تافه وأن سرية الرمز المميز لا تأتي من "صعوبة القراءة". (بورت سويجر)

تبرز ثلاث فئات متكررة من الأخطاء:

1. يتم التعامل مع حقل "alg" كمصدر للحقيقة. إذا كان رمز التحقق الخاص بك يسحب الخوارزمية التي ستستخدمها من الرأس - والتي يتحكم فيها المستخدم - فأنت بذلك تدعو إلى هجمات إرباك الخوارزمية.
2. إن لا شيء الخوارزمية مقبولة عن طريق الخطأ. يتطلب معيار JWT تاريخيًا دعمًا لـ "لا شيء" كخوارزمية تعني "عدم وجود حماية سلامة". أظهر التحليل الكلاسيكي لـ Auth0 كيف أن العديد من المكتبات احترمت هذا الاختيار بسذاجة، مما سمح للرموز غير الموقعة باجتياز عمليات التحقق. (المصادقة0)
3. تلميحات رئيسية (طفلمضمنة جوك, x5u) لم يتم التحقق من صحتها. يسلط كل من JWS RFC وأدلة الاختبار الضوء على أن السماح للرمز المميز باختيار مفتاح التحقق الخاص به دون وضع قائمة بيضاء صارمة يتيح للمهاجمين تهريب مفاتيح عامة عشوائية أو فرض عمليات بحث عن المفاتيح في مواقع يتحكم فيها المهاجمون. (بورت سويجر)

وبعبارة أخرى، يمنحك فك تشفير توقيع الويب json إمكانية الملاحظة. ولا يمنحك الثقة. هذا التمييز هو ما يفصل بين الإعداد الآمن لتصحيح الأخطاء عن عنوان تنفيذ التعليمات البرمجية عن بُعد.

عند التقاء فك التشفير مع CVEs: أنماط فشل JWS الملموسة

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

CVE-2015-9235 - ارتباك في مفتاح HS/RS في رمز jsonwebtoken

في Node.js رمز jsonwebtoken الوحدة النمطية قبل الإصدار 4.2.2، أتاح خطأ في التصميم إمكانية تجاوز التحقق من التوقيع عن طريق التبديل من خوارزمية غير متماثلة (عائلات RS256 / ES256) إلى خوارزمية متماثلة (HS256). أعاد مسار التعليمات البرمجية الضعيفة استخدام نفس القيمة - المفتاح العام RSA - كسر HMAC عندما قام المهاجم بتغيير زئبق رأس إلى HS256. (nvd.nist.gov)

من وجهة نظر المهاجم، فإن سير العمل واضح ومباشر:

1. فك تشفير الرمز المميز الأصلي وفحص الرأس.
2. استخرج المفتاح العام للخادم (على سبيل المثال، من نقطة نهاية أو شهادة JWK).
3. قم بتزوير رمز مميز جديد برأس HS256، باستخدام المفتاح العام كسر HMAC.
4. تقديم الرمز المميز المزور؛ فيتعامل الخادم معه على أنه صالح عن طريق الخطأ.

هنا، أعطى فك التشفير للمهاجم المادة الخام (الرأس، والخوارزمية، ومواقع المفاتيح)؛ بينما قام منطق التحقق بالباقي.

CVE-2018-1000531 - قبول لا شيء الخوارزمية

تتبعت هذه الثغرة الحالات التي قبلت فيها المكتبات رموزًا موقعة بـ لا شيء خوارزمية، ومعاملتها بشكل فعال على أنها صالحة على الرغم من افتقارها إلى أي توقيع. نمط الاستغلال بسيط بشكل كوميدي تقريبًا: تغيير "alg": "RS256" إلى "alg": "لا شيء"وإزالة جزء التوقيع، ومعرفة ما إذا كانت واجهة برمجة التطبيقات المستهدفة تقبل الرمز المميز. (0xN3VA.gitbook.io)

CVE-2023-48238 - ارتباك في الخوارزمية في رمز json-ويب-ويب

إن رمز json-ويب-ويب مكتبة لـ JavaScript وُجدت عرضةً لهجوم آخر لإرباك الخوارزمية. المشكلة الأساسية هي أن الخوارزمية المستخدمة للتحقق كانت مأخوذة مباشرةً من رأس الرمز المميز، والذي كان في تلك المرحلة غير موثوق به. وقد سمح ذلك للمهاجمين باختيار خوارزمية أكثر ملاءمة من الخوارزمية التي اعتقد مشغل الخادم أنه كان يفرضها. (nvd.nist.gov)

CVE-2024-54150 - ارتباك في تطبيق C JWT

وفي الآونة الأخيرة ج ج و ت عانت مكتبة C من ثغرة خطيرة في خوارزمية الخلط بين الخوارزميات، والتي تم تعقبها الآن باسم CVE-2024-54150. كشفت مراجعة الكود أن التطبيق لم يميز بشكل صحيح بين الخوارزميات المستندة إلى HMAC والخوارزميات المستندة إلى RSA / EC عند التحقق من الرموز المميزة، مما فتح الباب مرة أخرى للخلط بين المفاتيح. (nvd.nist.gov)

هذه الحالات ليست من الفضول التاريخي؛ فهي تُظهر أنه حتى في عام 2023-2024، لا تزال الأخطاء الدقيقة في مسار التحقق من نظام الإنذار المشترك مصدرًا نشطًا لنقاط الضعف الخطيرة.

لإبقائهم في وضع مستقيم أثناء التقييم، تقوم العديد من الفرق بإنشاء ورقة غش مثل ما يلي:

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

سير عمل عملي لفك التشفير أولاً للمختبرين الخماسيين

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

1. التقاط الرموز المميزة وفهرستها. استخدم البروكسي أو أداة الاختبار لالتقاط جميع الرموز المميزة: رؤوس التخويل، وملفات تعريف الارتباط، ومعلمات عنوان URL. قم بتجميعها حسب جهة الإصدار والجمهور.
2. فك تشفير الرأس والحمولة دون اتصال بالإنترنت. استخدم البرامج النصية مثل مقتطف بايثون أعلاه أو jwt_tool لفك التشفير فقط؛ لا تعتمد أبدًا على خدمة عبر الإنترنت للرموز الحساسة في الارتباطات الحقيقية. (جيثب)
3. قم ببناء مصفوفة رأس المصفوفة. لكل عائلة رمزية، سجِّل زئبق, طفلوجود جكو / جوك / x5uوأي حقول رأس مخصصة. هذا هو المكان الذي تصبح فيه إرشادات PortSwigger بشأن مفاتيح JWK المضمنة والمفاتيح التي يوفرها المهاجمون قابلة للتنفيذ مباشرة. (بورت سويجر)
4. استنتاج أنماط الإدارة الرئيسية. استنادًا إلى حقول الرؤوس ونقاط النهاية المعروفة (/.معروف/jwks.json.json)، ارسم كيفية توزيع المفاتيح وتدويرها.
5. اختبار لفئات الأخطاء المعروفة.
   • جرب التوقيع الفارغ / لا شيء المتغيرات إذا كانت المكتبة أو المكدس يدعمها تاريخيًا.
   • قم بإجراء محاولات إرباك مفاتيح HS/RS حيث لا يتم تأمين الألغاز.
   • مسبار طفل التعامل مع سلوك اجتياز الدليل أو تضمين الملفات.
   • محاولة حقن JWK المدمج حيث تسمح به المواصفات ولكن قد لا يقيده التنفيذ.
6. بعد ذلك، وعندها فقط، انتقل إلى محاولات الاستغلال الكامل. في هذه المرحلة، يجب أن تعرف بالضبط ما تحاول إثباته، بدلاً من مجرد إلقاء الحمولات في صندوق أسود.

في هذه العملية، يكون فك تشفير توقيع الويب json هو طبقة المراقبة لبقية منهجية الهجوم.

دمج فك تشفير توقيع الويب json في خط أنابيب اختبار خماسي يعتمد على الذكاء الاصطناعي (Penligent.ai)

يصلح التحليل اليدوي لمشاركة واحدة؛ أما على نطاق واسع، فتحتاج الفرق إلى شيء أقرب إلى خط أنابيب. منصة مدعومة بالذكاء الاصطناعي مثل Penligent.ai فك تشفير توقيع الويب json مباشرةً في مرحلتي الاستطلاع والاستغلال.

في إعداد نموذجي، تقوم المنصة باستيعاب حركة مرور HTTP من صندوق رمل المتصفح أو وكيل، وتستخرج الرموز المميزة المرشحة تلقائيًا، وتقوم بفك تشفير JWS بالجملة على الرؤوس والحمولات. يقوم عامل الذكاء الاصطناعي بعد ذلك بتجميع الرموز المميزة حسب المُصدر والخوارزمية وتلميحات المفاتيح، ويبحث عن الحالات الشاذة مثل التنوع غير المتوقع في الخوارزمية أو الغرابة طفل الترميزات، أو مجموعات المطالبات غير المعتادة.

وبمجرد إنشاء هذا الخط الأساسي، يمكن لمحرك هجوم Penligent تشغيل دفاتر تشغيل JWT / JWS المنسقة تلقائيًا: محاولات التوقيع الفارغة، وسيناريوهات الخلط بين الخوارزميات، و JWK أو جكو إساءة الاستخدام، والاختبارات المعروفة المستوحاة من CVE. وبدلاً من ترك هذه الفحوصات لذاكرة الإنسان، يعاملها النظام كحالات اختبار قابلة للتكرار يتم تشغيلها على كل هدف، ويغذي النتائج في قائمة مخاطر قائمة على الأدلة أولاً وتقرير يمكن قراءته آلياً.

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

قائمة مراجعة التقوية والمزيد من القراءة

إذا كانت وظيفتك اليومية تتضمن إصدار أو التحقق من رموز JWS / JWT، فيمكنك التعامل مع هذا كحد أدنى:

• فرض قائمة صارمة من جانب الخادم للخوارزميات المسموح بها؛ لا تقرأ أبدًا زئبق من رمز غير موثوق به كسياسة.
• افصل بين المفاتيح بين التواقيع غير المتماثلة وأسرار HMAC؛ لا تقم أبدًا بإعادة استخدام مفتاح RSA العام كمفتاح HMAC.
• تعطيل دائم لا شيء في مكتبات الإنتاج ورفض أي رمز مميز يعلن عنه.
• تعامل مع جميع حقول الرؤوس (طفل, جكو, جوك, x5u) كمدخلات غير موثوق بها والتحقق من صحتها مقابل مجموعة مفاتيح مثبتة أو قائمة بيضاء.
• حافظ على مكتبات JWT الخاصة بك مصحّحة؛ راجع دوريًا مكتبات CVEs مثل CVE-2015-9235 و CVE-2018-1000531 و CVE-2023-48238 و CVE-2024-54150 لمعرفة ما إذا كانت حزمتك متأثرة. (مختبر سويسكي)
• أضف اختبارات الانحدار التي تمارس صراحةً سيناريوهات عدم/خوارزمية الارتباك.

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

• جوهر [JSON Web Signature (JWS) RFC 7515] من IETF. (IETF Datatracker بيانات IETF)
• قسم OWASP حول [اختبار رموز الويب JSON] في دليل اختبار أمان الويب. (مؤسسة OWASP)
• مختبرات أكاديمية PortSwigger لأمن الويب التابعة لـ PortSwigger حول [هجمات JWT] و [الخلط بين الخوارزميات]. (بورت سويجر)
• تقرير تيم ماكلين الكلاسيكي الذي كتبه تيم ماكلين عن [الثغرات الحرجة في مكتبات رمز الويب JSON Web Token]. (المصادقة0)
• مسودة [أفضل الممارسات الحالية JWT] المتطورة [JWT أفضل الممارسات الحالية] في مجموعة عمل IETF OAuth. (IETF)

عند استخدامها بشكل صحيح، فإن فك تشفير توقيع الويب json ليس مجرد وسيلة مريحة لتصحيح الأخطاء؛ بل هو الباب الأمامي لطريقة منهجية لفهم نسيج المصادقة في تطبيقاتك ومهاجمته وتقويته.