CSRF لتعطيل أي موظف

الملخص

وظيفة إدارة الموظفين معرّضة لهجوم التزوير عبر الطلبات المشتركة بين المواقع (CSRF).
يمكن للمهاجم خداع مسؤول مسجّل الدخول لإرسال طلب مزوّر يؤدي إلى تعطيل موظف (مثل inid=1) دون علم المسؤول أو موافقته.

درجة CVSS الأساسية: 5.4 (متوسطة)

سلسلة المتجه: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L

الوظيفة المتأثرة

الوحدة: لوحة الإدارة ← الموظفون ← إدارة الموظفين
الإجراء: تعطيل موظف (عبر معامل inid)

خطوات إعادة الإنتاج

تسجيل الدخول كمسؤول
- انتقل إلى نقطة النهاية /admin وسجّل الدخول ببيانات اعتماد مسؤول صالحة.
فتح إدارة الموظفين
- من لوحة التحكم، انقر على الموظفون ← إدارة الموظفين.
التقاط طلب التعطيل
- فعّل اعتراض الطلبات في البروكسي الخاص بك (مثل Burp Suite).
- انقر على تعطيل لأحد الموظفين والتقط الطلب الذي يقوم بتعطيل المستخدم.
- لاحظ المعامل inid في الطلب (مثل inid=1).
إنشاء إثبات المفهوم الخاص بـ CSRF
- باستخدام تفاصيل الطلب المعترض، أنشئ ملف HTML يرسل طلبًا يحتوي على inid=1 لتعطيل المستخدم 1.
تشغيل هجوم CSRF على الضحية
- استضف ملف إثبات المفهوم HTML أو افتحه في متصفح.
- عندما يكون المسؤول مسجّل الدخول إلى التطبيق، إذا زار صفحة إثبات المفهوم هذه وأرسل النموذج، فسيتم تعطيل المستخدم 1.
التحقق من النتيجة
- ارجع إلى لوحة تحكم المسؤول ← إدارة الموظفين.
- لاحظ أن المستخدم 1 أصبح الآن معلّماً كـ غير نشط.

إثبات المفهوم لهجوم CSRF (HTML)

فيما يلي نموذج نموذجي لإثبات المفهوم بافتراض طلب POST مع المعامل inid:

<html>
  <body>
    <form action="http://localhost/elms/admin/manageemployee.php">
      <input type="hidden" name="inid" value="1" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

احفظ هذا الملف باسم csrf_inactivate_emp1.html.
أرسل/استضف هذا الملف واجعل مسؤولًا مصادقًا يقوم بتحميله والضغط على الزر.

التأثير

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

نظرًا لأن هذا يتلاعب مباشرة بـ إدارة المستخدمين في بوابة المسؤول، ينبغي اعتبار هذه المشكلة عالية الخطورة.

المعالجة

تنفيذ رموز حماية CSRF
- أضف رمز CSRF عشوائيًا وآمنًا من الناحية التشفيرية إلى جميع الطلبات التي تغيّر الحالة (مثل التعطيل، الحذف، التحديثات).
- ضمّن الرمز في النماذج كحقل مخفي.
- على جانب الخادم، تحقق من:
  - وجود الرمز،
  - صحة الرمز، و
  - ارتباط الرمز بجلسة المستخدم الحالية.
- ارفض الطلب إذا كان الرمز مفقودًا أو غير صالح.
استخدام ملفات تعريف الارتباط Same-Site
- عيّن ملفات تعريف ارتباط الجلسة مع SameSite=Lax أو يفضّل SameSite=Strict حيثما أمكن.
- يمنع هذا الإرسال التلقائي لملفات تعريف الارتباط في الطلبات المشتركة بين المواقع، مما يقلل من خطر CSRF.
فرض طرق HTTP المناسبة
- تأكد من أن جميع العمليات التي تغيّر الحالة (مثل تعطيل موظف) تستخدم POST (أو PUT/DELETE) بدلاً من GET.
- لا تقبل تغييرات الحالة الحساسة عبر معاملات GET.
التحقق من ترويسات المصدر / المُحيل
- في نقاط النهاية الحساسة، تحقق من ترويسة Origin أو Referer لضمان أن الطلبات تأتي من نطاقات موثوقة.
- إذا كانت الترويسة مفقودة أو من مصدر غير موثوق، ارفض الطلب.
تقوية واجهة المستخدم / سير العمل
- أضف تأكيدًا على جانب الخادم أو عمليات إعادة مصادقة للإجراءات الحساسة (مثل تعطيل المستخدمين الذين لديهم أدوار مسؤول).
- نفّذ فحوصات تفويض مناسبة لضمان أن الأدوار المخصصة فقط يمكنها تنفيذ الإجراء، حتى لو تمت محاولة CSRF.
الاختبار الأمني
- أدرج فحوصات CSRF في الاختبارات الأمنية المنتظمة (اليدوية والآلية).
- أعد اختبار نقطة النهاية هذه (وما يشابهها) بعد تنفيذ الحمايات للتحقق من أن إثبات المفهوم لم يعد يعمل.

CVE-2025-67315

الأكثر شعبية