اسم البرنامج الإضافي	مدير دوري MSTW
نوع الضعف	البرمجة النصية عبر المواقع (XSS)
رقم CVE	CVE-2026-34890
الاستعجال	قليل
تاريخ نشر CVE	2026-04-02
رابط المصدر	CVE-2026-34890

عاجل: ثغرة البرمجة عبر المواقع (XSS) في مدير دوري MSTW (<= 2.10) — ما يجب على مالكي مواقع ووردبريس فعله الآن

التاريخ: 2026-04-02 | المؤلف: فريق أمان WP‑Firewall

الملخص: تم الإبلاغ علنًا عن ثغرة البرمجة عبر المواقع (XSS) التي تؤثر على إصدارات مدير دوري MSTW <= 2.10 (CVE-2026-34890). تتيح المشكلة لمستخدم منخفض الامتياز (دور المساهم) وضع حمولات JavaScript يمكن تنفيذها عندما يتفاعل مستخدم ذو امتيازات مع واجهات المكون الإضافي. تتطلب الثغرة تفاعل المستخدم وتُصنف بمعدل CVSS يبلغ 6.5. يشرح هذا المنشور ما يعنيه ذلك، ومن هو المعرض للخطر، والتخفيفات الفورية، وكيفية اكتشاف الاستغلال، وتوصيات تعزيز الأمان على المدى الطويل، وكيف يمكن لـ WP‑Firewall حماية موقعك.

جدول المحتويات

• حقائق سريعة
• ما هي الثغرة وكيف تعمل (مستوى عالٍ)
• تأثير واقعي وسيناريوهات المخاطر
• من يجب أن يكون قلقًا
• الخطوات الفورية التي يجب عليك اتخاذها الآن (قائمة الأولويات)
• كيفية اكتشاف ما إذا كنت مستهدفًا أو معرضًا للخطر
• كيفية التخفيف عندما لا يتوفر تصحيح من البائع (تخفيفات عملية)
• توقيعات WAF وقواعد الحظر النموذجية (إرشادات آمنة)
• قائمة التحقق من التنظيف واستعادة ما بعد الاختراق
• How WP‑Firewall helps protect your site
• خطة حماية مجانية — طريقة سهلة وبدون تكلفة لإضافة طبقة من الدفاع
• الأفكار النهائية والتوصيات

---

حقائق سريعة

• الحزمة المتأثرة: مكون إضافي لمدير دوري MSTW لووردبريس
• الإصدارات المعرضة للخطر: <= 2.10
• نوع الثغرة: البرمجة النصية عبر المواقع (XSS)
• CVE: CVE‑2026‑34890
• تم الإبلاغ عن: 2 أبريل، 2026
• الامتياز المطلوب للحقن: المساهم
• تفاعل المستخدم: مطلوب (يعتمد الاستغلال الناجح على قيام مستخدم ذو امتيازات بأداء إجراء)
• حالة التصحيح (في وقت الكتابة): لا يوجد تصحيح متاح من البائع
• الأولوية: منخفض (لكن يمكن استغلاله في بيئات محددة) - CVSS 6.5

---

ما هي الثغرة وكيف تعمل (مستوى عالٍ)

يشير XSS (البرمجة النصية عبر المواقع) إلى الحالات التي يتمكن فيها المهاجم من حقن JavaScript أو HTML في صفحة يشاهدها مستخدمون آخرون، ويعمل هذا الرمز المحقون في متصفحات الضحايا بصلاحيات الموقع. في هذه الحالة:

• يمكن لحساب مستخدم لديه دور المساهم (أو دور منخفض الصلاحيات آخر) تقديم مدخلات من خلال واجهات ملحق MSTW League Manager التي لم يتم تنظيفها/تشفيرها بشكل صحيح.
• تظهر تلك المدخلات لاحقًا في عرض إداري أو متميز (على سبيل المثال، صفحة لوحة تحكم المسؤول أو شاشة الإدارة).
• عندما يزور مستخدم متميز (محرر، مسؤول أو مدير موقع) الصفحة، أو ينقر على رابط أو زر مصمم، يتم تنفيذ JavaScript المقدم من المهاجم في متصفح المستخدم المتميز.
• يمكن للمهاجم بعد ذلك محاولة تنفيذ إجراءات في سياق تلك الجلسة المتميزة - على سبيل المثال، سرقة ملفات تعريف الارتباط للجلسة (إذا لم تكن محمية بواسطة HttpOnly)، تنفيذ إجراءات عبر الجلسة المعتمدة (على نمط CSRF)، حقن أبواب خلفية إضافية، أو تسجيل آليات الاستمرارية.

تحذير مهم: هذه الكتابة تتجنب عمدًا تعليمات الاستغلال خطوة بخطوة. تركيزنا هو الدفاعي: فهم الآليات حتى تتمكن من معالجة واكتشاف الإساءة.

---

تأثير واقعي وسيناريوهات المخاطر

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

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

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

---

من يجب أن يكون قلقًا

• المواقع التي تعمل على MSTW League Manager في أي إصدار <= 2.10.
• المواقع التي تسمح لحسابات المساهمين أو مستخدمين غير إداريين بتقديم محتوى يمكن تخزينه وعرضه في منطقة الإدارة.
• مواقع متعددة المؤلفين، أو مجتمعية أو أندية رياضية حيث يمكن للمتطوعين إضافة فرق، لاعبين، أو بيانات المباريات.
• المواقع التي تحتوي على العديد من مستخدمي الإدارة أو تستخدم بيانات اعتماد إدارة مشتركة (مما يزيد من فرص تفاعل المسؤول مع مدخلات ضارة).

إذا كنت غير متأكد مما إذا كنت تستخدم الملحق أو أي إصدار تعمل به، تحقق من قائمة الملحقات في wp-admin (الملحقات > الملحقات المثبتة) أو استخدم أداة إدارة المواقع التي تعدد إصدارات الملحقات. إذا لم تتمكن من عرض منطقة الإدارة بأمان (أو تشك في الاختراق)، اتبع “الخطوات الفورية” أدناه.

---

الخطوات الفورية التي يجب عليك اتخاذها الآن (قائمة الأولويات)

هذه هي الإجراءات التي يجب عليك تنفيذها بالترتيب الموضح. ابدأ بأعلى خطوات الحماية تأثيرًا.

1. تأكد مما إذا كان موقعك يستخدم MSTW League Manager وأي إصدار
   • قم بتسجيل الدخول إلى wp-admin (استخدم حساب مسؤول) وتحقق من الإضافات > الإضافات المثبتة.
   • إذا لم تتمكن من الوصول إلى لوحة الإدارة بأمان، استخدم سطر الأوامر (wp‑cli) أو SFTP لفحص مجلد الإضافات: wp-content/plugins/mstw-league-manager وتحقق من ملف readme/changelog الخاص به.
2. إذا كنت تستخدم إصدارًا متأثرًا (<= 2.10)، قم بتعطيل الإضافة مؤقتًا
   • يمنع التعطيل تشغيل كود الإضافة ويزيل متجه التعرض الفوري.
   • إذا كانت الإضافة حيوية لتشغيل الموقع، فكر في وضع الموقع في وضع الصيانة حتى تتمكن من تنفيذ تدابير تخفيف إضافية.
3. إذا لم يكن هناك تصحيح متاح من مؤلف الإضافة، قم بإزالة أو استبدال الإضافة
   • إذا كان بإمكان الموقع العمل بدون الإضافة، قم بإزالتها تمامًا حتى يتم إصدار تصحيح من البائع.
   • إذا كانت الأمور حرجة، قم بتطبيق التدابير المذكورة أدناه (قواعد WAF، تحديد الأدوار، تطهير البيانات الموجودة) وراقب عن كثب.
4. قم بمراجعة الحسابات وتحديد الامتيازات
   • قم بتعطيل أو تخفيض حسابات المساهمين حيثما أمكن.
   • فرض كلمات مرور قوية وتمكين MFA لجميع حسابات المسؤول/المحرر.
   • قم بإزالة الحسابات غير المستخدمة وإعادة تعيين كلمات المرور لأي حسابات ذات امتيازات أعلى إذا كنت تشك في إساءة الاستخدام.
5. قم بتمكين أو تشديد جدار حماية تطبيق الويب (WAF) الخاص بك
   • قم بتكوين قواعد لحظر الحمولة الشائعة لـ XSS وطلبات POST المشبوهة إلى نقاط نهاية إضافة MSTW.
   • استخدم التصحيح الافتراضي إذا كان WAF الخاص بك يدعمه (نشر قواعد WAF التي تحظر نمط الثغرة أثناء انتظار تصحيح من البائع).
6. افحص قاعدة البيانات بحثًا عن مدخلات مشبوهة
   • ابحث في الجداول المتعلقة بالإضافة وpostmeta عن علامات السكربت أو JS المضمنة المشبوهة (استعلامات أدناه).
   • قم بتنظيف أو تحييد أي إدخالات مشبوهة (استبدل وسمات on*، أو قم بتصدير/حذف الصفوف المخالفة).
7. قم بفحص الموقع بحثًا عن البرامج الضارة وأصداف الويب
   • قم بتشغيل فحص كامل للبرامج الضارة (من جانب الخادم وفحص ملفات ووردبريس) - تحقق من وجود مستخدمين إداريين غير معروفين، وملفات PHP جديدة، أو ملفات أساسية/إضافات معدلة.
8. التواصل مع فريقك
   • أخبر مديري الموقع بعدم النقر على الروابط غير المعروفة وتجنب فتح صفحات الإدارة حتى يتم الانتهاء من التنظيف.
   • إذا كان لديك مزود أمان مُدار، قم بإخطارهم.

---

كيفية اكتشاف ما إذا كنت مستهدفًا أو معرضًا للخطر

مؤشرات الاختراق (IoCs) التي يجب أن تبحث عنها:

• مستخدمون إداريون جدد أو غير متوقعين (تحقق من جدول wp_users).
• ملفات إضافات أو سمات معدلة - قارنها بنسخ معروفة جيدة أو تحقق من الطوابع الزمنية في نظام الملفات.
• علامات سكريبت غير متوقعة أو URIs جافا سكريبت مخزنة في:
  • wp_posts.post_content
  • wp_postmeta.meta_value
  • جداول محددة للإضافات (ابحث عن ‘<script’، ‘javascript:’، ‘onerror=’، ‘onload=’)
• طلبات صادرة غير عادية من موقعك (ارتفاعات في حركة المرور الصادرة، اتصالات بنقاط نهاية غير مألوفة).
• محاولات تسجيل دخول فاشلة أعلى من المعتاد أو أنماط تسجيل دخول مشبوهة.

استعلامات SQL مفيدة للكشف (قم بتشغيلها في phpMyAdmin أو عبر wp-cli؛ قم بعمل نسخ احتياطية أولاً):

-- ابحث عن علامات سكريبت محتملة في المشاركات;

نصيحة: يمكن أن تشمل النتائج إيجابيات كاذبة (تضمينات شرعية). راجع الإدخالات قبل الحذف.

---

كيفية التخفيف عندما لا يتوفر تصحيح من البائع (تخفيفات عملية)

عندما لا يكون هناك تصحيح رسمي، يجب عليك تقليل التعرض القابل للاستغلال ومنع تنفيذ الحمولة. الدفاعات التالية فعالة وعملية:

1. قيد من يمكنه تقديم محتوى يظهر في وجهات نظر الإدارة
   • إزالة دور المساهم من المواقع حيث لا تكون المساهمات غير الموثوقة مطلوبة بشكل صارم.
   • تنفيذ متطلب بأن يتمكن فقط المحررون/المديرون من إضافة محتوى الدوري، أو استخدام سير العمل المعتدل.
2. تعزيز تخطيط القدرات
   • استخدم إضافة إدارة القدرات أو كود مخصص لإزالة القدرة على تقديم HTML غير المصفى من المساهمين.
   • مثال: إزالة قدرة ‘unfiltered_html’ من الأدوار غير الإدارية.
3. تطهير البيانات المخزنة عند العرض
   • حيثما يتم عرض مخرجات الإضافات في واجهات الإدارة، تأكد من وجود دوال الهروب: esc_html()، esc_attr()، wp_kses_post() حسب السياق.
   • إذا كان لديك موارد تطوير، قم بتصحيح كود الإضافة محليًا للهروب من المخرجات في صفحات الإدارة، ثم اختبرها بدقة.
4. استخدم جدار حماية تطبيقات الويب (WAF) لحظر الحمولة (تصحيح افتراضي)
   • أنشئ قواعد لحظر الطلبات التي تحتوي على علامات سكريبت أو سمات on* في حقول الإدخال المقدمة إلى نقاط نهاية MSTW.
   • استخدم “قائمة حظر” للأنماط المعروفة الخطيرة وفرض السياسة عند الحافة.
5. قم بإزالة أو تحييد المدخلات الخبيثة المعروفة
   • استبدل علامات بنص آمن أو أزل السمات المشبوهة من جداول الإضافات.
   • إذا تم العثور على حمولات مخزنة، اعتبر جميع جلسات الإدارة معرضة للخطر حتى تقوم بتنظيف وتدوير بيانات الاعتماد.
6. تحسين وضع تصفح الإدارة
   • وجه الإداريين للوصول إلى wp-admin فقط من الشبكات والأجهزة الموثوقة.
   • ضع في اعتبارك استخدام وكيل عكسي للإدارة أو وصول إداري مقيد بواسطة IP.
7. راقب السجلات وزد من التنبيهات
   • راقب سجلات خادم الويب وWAF لطلبات POST إلى مسارات الإضافات مع حمولات مشبوهة.
   • قم بتمكين تسجيل الطلبات المحظورة واضبط التنبيهات للانحرافات.

---

توقيعات WAF وقواعد الحظر النموذجية (إرشادات آمنة)

أدناه توجد قواعد نموذجية يمكنك تعديلها لـ ModSecurity أو محركات WAF الأخرى كتصحيحات افتراضية أثناء انتظار إصلاح رسمي من البائع. هذه القواعد واسعة عمدًا - فهي تقلل من المخاطر ولكن قد تحتاج إلى ضبط لتجنب الإيجابيات الكاذبة (اختبر في بيئة اختبار أولاً).

مثال ModSecurity (apache، أساسي):

# حظر علامات السكريبت الشائعة المضمنة في أجسام POST"

قاعدة Nginx + Lua أو قاعدة regex (مثال):

# مثال بسيط - رفض الطلبات التي تحتوي على <script في الجسم لنقاط النهاية تحت مسار الإضافة

ملاحظات حول الضبط:

• هذه الأمثلة عامة عن عمد. يجب عليك الاختبار بدقة لتجنب حظر المحتوى الشرعي (مثل، المضمنات التي تحتوي بشكل شرعي على سلاسل javascript:).
• نشر في وضع “المراقبة” أولاً (تسجيل فقط) ومراجعة الإيجابيات الكاذبة.
• تضييق القواعد إلى نقاط نهاية المكونات الإضافية المحددة للحصول على دقة أفضل.

---

قائمة التحقق من التنظيف واستعادة ما بعد الاختراق

إذا وجدت دليلًا على الحقن أو اشتبهت في أن جلسة الإدارة قد تم اختراقها:

1. عزل واحتواء
   • قم بإيقاف الموقع أو تفعيل وضع الصيانة إذا كان هناك شك في اختراق واسع النطاق.
   • إلغاء مفاتيح API المخترقة.
2. تدوير أوراق الاعتماد
   • أعد تعيين جميع كلمات مرور المسؤولين والمحررين.
   • إبطال جميع الجلسات النشطة (يدعم ووردبريس فرض تغيير كلمة المرور لإنتهاء الجلسات).
   • تدوير أي بيانات اعتماد عن بُعد أو SFTP/استضافة.
3. إزالة المحتوى الضار
   • حذف أو تحييد المشاركات الضارة، أو البيانات الوصفية، أو إدخالات الخيارات.
   • إزالة أي ملفات PHP غير معروفة أو قذائف ويب.
4. استعادة من نسخة احتياطية نظيفة إذا كانت متاحة
   • إذا كان لديك نسخة احتياطية نظيفة معروفة من قبل الحادث، استعد ثم قم بتصحيح وتقوية.
   • بعد الاستعادة، قم بتغيير جميع كلمات المرور واختبر.
5. إعادة المسح والمراقبة
   • إعادة تشغيل فحوصات البرمجيات الضارة وفحوصات قواعد WAF.
   • راقب السجلات عن كثب لرصد التكرار.
6. مراجعة ما بعد الحادث
   • تحديد كيف حصل المهاجم على حساب المساهم أو أدخل المحتوى.
   • سد الفجوة (تعطيل التسجيل المفتوح، فرض إدارة أدوار أفضل، تطبيق قواعد WAF).
7. النظر في المساعدة المهنية
   • إذا كان الموقع ذو قيمة عالية وتشك في وجود اختراق مستمر، احضر خدمة استجابة للحوادث في ووردبريس ذات خبرة.

---

كيفية تقوية ووردبريس بشكل عام لتقليل مخاطر XSS

• فرض مبدأ أقل الامتيازات: منح الأدوار فقط الأذونات التي تحتاجها.
• إزالة قدرة ‘unfiltered_html’ من أي دور لا يحتاجها.
• استخدام رؤوس سياسة أمان المحتوى (CSP) للمساعدة في التخفيف من تأثير السكربتات المدخلة عن طريق منع السكربتات المضمنة أو تقييد أصول السكربتات.
• الحفاظ على تحديث المكونات الإضافية، والسمات، ونواة ووردبريس والاشتراك في تغذيات الثغرات الموثوقة.
• قم بتمكين HttpOnly على الكوكيز واستخدم سمات Secure وSameSite حيثما كان ذلك ممكنًا.
• استخدم الهروب من المخرجات على جانب الخادم في كود الإضافات والقوالب (esc_html، esc_attr، wp_kses).
• استخدم WAF مع تصحيح افتراضي للحماية السريعة بين الكشف وإصلاحات البائع.

---

How WP‑Firewall helps protect your site

كفريق خلف WP‑Firewall، نصمم منتجنا ليتناسب تمامًا مع السيناريو الموصوف أعلاه: ثغرة في طبقة التطبيق يتم استغلالها قبل توفر تصحيح من البائع. يوفر WP‑Firewall عدة طبقات من الحماية تقلل من فرصة الاستغلال الناجح وتسريع التعافي:

• جدار ناري مُدار وWAF: قواعد فورية لحظر حمولات XSS وأنماط الهجوم الشائعة عند حافة موقعك - هذا يمنع الإدخال الضار من الوصول إلى الخلفية أو يوقف تنفيذ الحمولات المعروضة.
• ماسح البرمجيات الضارة: عمليات مسح مجدولة للعثور على السكربتات المدخلة، والمستخدمين الإداريين الضارين، والملفات المعدلة.
• التخفيف من مخاطر OWASP Top 10: حماية مستهدفة للثغرات الشائعة في تطبيقات الويب بما في ذلك XSS.
• عرض نطاق غير محدود لحركة WAF: احمِ موقعك دون القلق بشأن عرض النطاق الترددي أو التقييد.
• نشر سهل: انضمام سريع لتفعيل التصحيح الافتراضي في غضون دقائق حتى تحصل على الحماية بينما تقوم بتقييم الموقع وانتظار التصحيحات العلوية.

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

---

احمِ موقعك الآن — ابدأ بخطة WP‑Firewall المجانية

لأصحاب المواقع الذين يرغبون في حماية فورية بدون تكلفة أثناء تقييمهم وإصلاحهم، يوفر خطتنا المجانية الأساسية دفاعات أساسية توقف الكثير من الإساءة في العالم الحقيقي. تشمل حماية جدار ناري مُدار، وWAF بمستوى إنتاج، ومسح البرمجيات الضارة، وعرض نطاق غير محدود، وتخفيفات لمخاطر OWASP Top 10. إذا كنت تدير MSTW League Manager (أو أي إضافة بها كشف)، فإن تفعيل الخطة المجانية يوفر شبكة أمان سريعة بينما تعمل من خلال الخطوات أعلاه.

اشترك وفعّل الحماية الآن

(تم تصميم الحمايات المجانية لتكون غير متطفلة ويمكن تعطيلها بسرعة إذا لزم الأمر - وهي تهدف إلى شراء الوقت وتقليل المخاطر التشغيلية الفورية.)

---

الجدول الزمني وما يمكن توقعه بعد ذلك

• الكشف: تم نشر تقرير عام (CVE‑2026‑34890) في 2 أبريل 2026 يصف الثغرة وخصائصها.
• إجراء البائع: في وقت كتابة هذا، لم يتم نشر أي تصحيح رسمي. نوصي بالتحقق من الصفحة الرسمية لتوزيع الإضافة أو سجل التغييرات بشكل متكرر للحصول على التحديثات.
• التوصية المؤقتة: نشر قواعد WAF، تقييد امتيازات المساهمين، وإزالة أو تعطيل الإضافة إذا كان ذلك ممكنًا.
• نشر التصحيح: عندما يتم إصدار نسخة محدثة من المكون الإضافي، اختبر التغييرات في بيئة الاختبار ثم قم بالتحديث بسرعة. بعد التحديث، قم بإزالة قواعد WAF المؤقتة التي كانت تمنع حركة المرور فقط لمنع كسر الوظائف.

---

الأفكار النهائية والتوصيات

• لا تتجاهل XSS لمجرد أن صلاحيات المهاجم المطلوبة منخفضة. في العديد من المواقع، يكون المساهمون شائعين ويمكن خداع المستخدمين الإداريين للنقر على الروابط - مما يجعل هذه الثغرات عملية ومفيدة للمهاجمين.
• إذا كنت تستخدم مكونات إضافية تقبل المدخلات من مستخدمين ذوي صلاحيات منخفضة، اختبر وقم بتقوية مسارات الخروج - تأكد من أن جميع المحتويات مؤمنة بشكل صحيح عند العرض.
• استخدم الدفاع المتعدد الطبقات: تقوية الأدوار، قواعد WAF/edge، فحص البرمجيات الخبيثة، ونظافة بيانات الاعتماد الجيدة تعمل معًا لتقليل المخاطر.
• إذا كنت تفتقر إلى القدرة على إدارة هذه التدابير داخليًا، قم بأتمتة الحماية حيثما كان ذلك ممكنًا واستخدم حلاً مُدارًا للحصول على تصحيح افتراضي سريع وفحص.

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

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

---

إذا كنت بحاجة إلى قائمة مراجعة قابلة للطباعة أو مجموعة من قواعد ModSecurity معدة لبيئتك، رد على هذا المنشور بنوع خادمك (Apache، Nginx، أو مضيف مُدار) وسنقدم مجموعة قواعد مخصصة يمكنك اختبارها في بيئة الاختبار.