CVE-2026-71206 — Shiori: دالة CheckToken الخاصة بـ JWT لا تعيد التحقق من حالة الحساب أبدًا

المنتج: go-shiori/shiori الملف: internal/domains/auth.go CWE: CWE-613 — انتهاء صلاحية الجلسة غير كافٍ CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L — 8.2 (مرتفع) CNA: Turan Security · سجل CVE

الوصف

تتحقق دالة CheckToken في Shiori (internal/domains/auth.go) فقط من توقيع HMAC الخاص بـ JWT وتعيد كائن claims.Account المضمّن دون أي تعديل — فهي لا تعيد جلب الحساب من قاعدة البيانات عند كل طلب. لا توجد أي آلية لتخزين الجلسات أو لإبطال الرموز (token revocation) في أي مكان في قاعدة الكود.

التأثير

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

إعادة الإنتاج

1. سجّل الدخول كمستخدم والتقط JWT الصادر (على سبيل المثال عبر POST /api/v1/auth/login).
2. كمسؤول، احذف الحساب أو خفّض دور المستخدم.
3. أعد إرسال JWT الأصلي إلى أي نقطة نهاية تتطلب مصادقة:

   GET /api/bookmarks
   Authorization: Bearer <original JWT>
   

4. ينجح الطلب باستخدام الادعاءات القديمة (stale claims) — لا يزال الحساب المحذوف/المخفّض الصلاحيات يمتلك وصولًا، لأن CheckToken لا يتحقق أبدًا من الحالة الحالية لقاعدة البيانات، بل يتحقق فقط من التوقيع.

السبب الجذري

تعتبر CheckToken أن حمولة (payload) JWT هي المصدر الموثوق لحالة الحساب بدلًا من التعامل معها كبيانات اعتماد من نوع Bearer يجب إعادة التحقق منها مقابل قاعدة البيانات (أو فحصها مقابل قائمة إبطال) عند كل استخدام.

التوصية بالإصلاح

أعد جلب الحساب بواسطة معرّفه في كل طلب موثّق (أو على الأقل تحقق من مخزن إبطال/جلسات مُفهرس بمعرّف الرمز (jti) ويُبطَل عند حذف الحساب أو تخفيض صلاحياته أو تغيير كلمة المرور) بدلًا من الثقة حرفيًا في الادعاءات المضمّنة.