ثغرة التحكم في الوصول المكسور في نظام دعم ilGhera لـ WooCommerce (CVE-2025-14033) — ما يجب على مالكي المواقع القيام به الآن

تؤثر ثغرة التحكم في الوصول المكسور التي تم الكشف عنها مؤخرًا على مكون WordPress الإضافي “نظام دعم ilGhera لـ WooCommerce” (الإصدارات ≤ 1.3.0). تتيح المشكلة للمستخدمين غير المصرح لهم الوصول إلى معلومات حساسة بسبب عدم وجود فحوصات تفويض. يتم تتبع الثغرة على أنها CVE­2025­14033 وقد تم إصلاحها في الإصدار 1.3.1.

كفريق أمان WordPress مسؤول عن حماية آلاف متاجر WooCommerce، قمنا بتحليل المشكلة وأعددنا دليلًا عمليًا خطوة بخطوة لمالكي المواقع والمطورين ومقدمي خدمات الاستضافة. يشرح هذا المنشور المخاطر، وكيف يمكن للمهاجمين استغلالها، وكيفية اكتشاف محاولات الاستغلال، والتخفيفات الفورية التي يمكنك تنفيذها، وتعزيز الأمان على المدى الطويل من منظور كل من المسؤول والمطور.

ملحوظة: لا يقدم هذا المقال كود استغلال أو تعليمات قد تمكن من سوء الاستخدام. الهدف هو مساعدتك في حماية موقعك بسرعة وبمسؤولية.

الملخص التنفيذي

• المكون المتأثر: نظام دعم ilGhera لـ WooCommerce (اسم المكون: wc-support-system)
• الإصدارات المعرضة للخطر: ≤ 1.3.0
• الإصدار المصحح: 1.3.1
• CVE: CVE­2025­14033
• المشكلة: التحكم في الوصول المكسور — عدم وجود فحوصات تفويض/nonce في نقطة أو أكثر من نقاط النهاية/الوظائف التي تعيد بيانات حساسة
• CVSS: 5.3 (متوسط / منخفض حسب سياق الموقع)
• الامتياز المطلوب للتفعيل: غير مصرح به (عام)
• التأثير الرئيسي: كشف معلومات حساسة (بيانات العملاء/تذاكر الدعم، بيانات الطلبات أو المستخدمين المحتملة) — خطر على الخصوصية والامتثال والثقة
• الإجراء الفوري: تحديث المكون إلى 1.3.1 أو إصدار لاحق. إذا لم تتمكن من التحديث على الفور، قم بتطبيق التخفيفات الموضحة أدناه (تصحيح افتراضي WAF، تقييد الوصول، تعطيل المكون إذا لم يكن ضروريًا).

لماذا يهم هذا لمواقع WooCommerce

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

• انتهاكات الخصوصية والتعرض لـ GDPR/CCPA.
• تعداد الحسابات والهندسة الاجتماعية المستهدفة.
• تجميع البيانات لحملات أكبر ضد المتاجر.
• هجمات ثانوية (تعبئة بيانات الاعتماد، التصيد) باستخدام المعلومات المسربة.

حتى لو تم تصنيف الثغرة على أنها “منخفضة/متوسطة” بواسطة نظام التقييم، فإن التأثير الحقيقي على الأعمال يمكن أن يكون كبيرًا اعتمادًا على البيانات المعرضة وكمية المعلومات المتاحة.

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

اكتشف الباحثون في الأمن أن الإضافة تكشف عن نقطة نهاية أو وظيفة تعيد بيانات نظام الدعم دون التحقق مما إذا كان الطالب مخولًا.

• فحص القدرات المفقودة: الكود يتجاهل current_user_can() أو فحوصات الأذونات المعادلة.
• متطلبات المصادقة المفقودة: نقطة النهاية متاحة للطلبات غير المصدقة.
• عدم التحقق من nonce: لم يتطلب المطورون/يحققوا في wp_nonce أو رمز مضاد CSRF مشابه.
• نقاط نهاية REST المفرطة في السماح: تم تسجيل مسارات REST دون ‘permission_callback’ المناسب.

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

تقييم المخاطر وقابلية الاستغلال

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

على الرغم من أن درجة CVSS الرسمية حوالي 5.3، فإن سياق متجر التجارة الإلكترونية (المعلومات الشخصية، الطلبات، رسائل البريد الإلكتروني للعملاء) يمكن أن يرفع من التأثير في العالم الحقيقي. اعتبر هذا أولوية لمواقع WooCommerce أو أي موقع يستخدم الإضافة.

الإجراءات الفورية لمالكي المواقع (خطوة بخطوة)

1. تحديث البرنامج المساعد
   - أصدرت الشركة النسخة 1.3.1 التي تعالج التحكم في الوصول المكسور. قم بالتحديث فورًا عبر إدارة WordPress (الإضافات → الإضافات المثبتة → تحديث) أو سير العمل الإداري المفضل لديك.
   - إذا كنت تدير العديد من المواقع، قم بجدولة تحديث جماعي ومراقبة سجلات التحديث.
2. إذا لم تتمكن من التحديث فورًا - تدابير مؤقتة
   - تطبيق قواعد WAF / التصحيح الافتراضي لحظر نقاط النهاية الضعيفة (أمثلة أدناه).
   - تقييد الوصول العام إلى مسارات الإضافة بواسطة IP أو مصادقة HTTP حيثما كان ذلك ممكنًا (انظر أمثلة .htaccess/nginx أدناه).
   - تعطيل الإضافة مؤقتًا إذا لم تكن ضرورية لوظائف المتجر.
   – حد من استخدام الإضافات الأخرى أو الشيفرات المخصصة التي قد تستدعي نقطة النهاية الضعيفة من الواجهة الأمامية.
3. تدقيق السجلات والمستخدمين
   – تحقق من سجلات خادم الويب ووردبريس للطلبات المشبوهة إلى نقاط نهاية الإضافات (ابحث عن طلبات GET/POST غير العادية إلى دليل إضافة نظام الدعم).
   – ابحث عن ارتفاعات في أنماط الوصول أو الطلبات التي تعيد 200 للموارد التي يجب تقييدها.
   – راجع حسابات المستخدمين الأخيرة ومحاولات تسجيل الدخول الفاشلة.
4. غير أو قم بتدوير الأسرار
   – إذا كان نظام الدعم يتكامل مع واجهات برمجة التطبيقات الخارجية أو الرموز، قم بتدويرها إذا كنت تشك في إساءة الاستخدام.
   – ضع في اعتبارك إعادة تعيين كلمات مرور المسؤولين للحسابات المخترقة أو المشبوهة.
5. أبلغ عملاءك (إذا تم كشف البيانات)
   – إذا حددت أن البيانات تم الكشف عنها، اتبع متطلبات إشعار الخرق في منطقتك وأبلغ العملاء المتأثرين بشفافية.

اكتشاف علامات الاستغلال

ابحث عن المؤشرات التالية في سجلات الوصول وسجلات ووردبريس:

• الطلبات إلى نقاط نهاية الإضافات مثل:
  • /wp-content/plugins/wc-support-system/*
  • /wp-json/wc-support-system/*
• الطلبات غير المصرح بها التي تتلقى 200 OK مع حمولات JSON تحتوي على أسماء المستخدمين، والبريد الإلكتروني، ومعرفات الطلبات، ومحتوى التذاكر، أو معلومات التعريف الشخصية الأخرى.
• الطلبات المفرطة أو الآلية من مجموعة صغيرة من عناوين IP تستهدف نقاط نهاية الدعم.
• الطلبات التي تستخدم أنماط فحص شائعة (مثل، ?id=*, ?ticket_id=*, إلخ) ضد عناوين URL للدعم.

عينة grep على سجلات الخادم (استبدل المسار وأسماء الملفات حسب الحاجة):

grep -i "wc-support-system" /var/log/nginx/access.log | tail -200

أو ابحث عن استجابات JSON تحتوي على عناوين البريد الإلكتروني:

grep -Eio "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,6}\b" /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

إذا اكتشفت نشاطًا مشبوهًا، احتفظ بالسجلات وقم بعمل نسخة احتياطية قبل إجراء أي تغييرات.

قواعد WAF العملية / تصحيح افتراضي (أمثلة)

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

مهم: لا تحظر الطلبات الشرعية من المسؤولين / الخدمات. اختبر القواعد في وضع الكشف أولاً.

قواعد على نمط ModSecurity (مفاهيمية):

# حظر الوصول المباشر إلى نقاط نهاية PHP للمكون الإضافي من غير المسؤولين"

مثال NGINX للحظر حسب الموقع (استخدمه فقط إذا كان آمنًا لإعدادك):

location ~* /wp-content/plugins/wc-support-system/ {

.مقتطف .htaccess لحظر الوصول العام إلى مجلد المكون الإضافي (Apache):

# حماية ملفات نظام دعم ilGhera

هذه الأمثلة هي قوالب. إذا كنت تستخدم WAF مُدار أو مكون إضافي للأمان، أنشئ قاعدة لـ:

• حظر المكالمات غير المصرح بها إلى نقاط نهاية REST الخاصة بالمكون الإضافي.
• تطلب أن تكون الطلبات إلى نقاط نهاية الدعم من جلسات مسؤول مصدق أو مقيدة بواسطة referer/nonce.
• تحديد معدل وحظر وكلاء المستخدمين المشبوهين أو عناوين IP التي تسيء استخدام هذه الروابط.

قائمة مراجعة تصحيح المطورين (لمؤلفي المكونات الإضافية والمكاملين)

إذا كنت تحافظ على مكونات إضافية مخصصة أو تتكامل مع المكون الإضافي للدعم، تأكد من نظافة الكود التالية:

1. فحوصات الأذونات
   - يجب على كل نقطة نهاية تعيد بيانات حساسة التحقق من قدرة المستخدم المطلوب:
       • استخدم current_user_can( ‘manage_woocommerce’ ) أو قدرة مناسبة.
       • بالنسبة لمسارات REST، قدم permission_callback آمن يتحقق من القدرة والسياق.
2. التحقق من الهوية والتحقق من nonce
   - تطلب المصادقة لنقاط النهاية التي تقدم معلومات التعريف الشخصية (PII).
   – بالنسبة لنماذج الواجهة الأمامية، تحقق من قيمة wp_verify_nonce() قبل إرجاع المحتوى الحساس.
3. مبدأ الحد الأدنى من الامتياز
   – أعد الحد الأدنى من البيانات المطلوبة للطلب.
   – تجنب إرجاع سجلات المستخدم الكاملة حيث تكفي التفاصيل الجزئية.
4. تسجيلات REST الآمنة
   – عند تسجيل مسارات REST (register_rest_route)، حدد دائمًا permission_callback التي تفرض فحوصات القدرة وتعيد WP_Error عند الفشل.
5. تطهير المخرجات
   – قم بتنظيف وتشفير جميع المخرجات حتى للمستخدمين المعتمدين؛ تجنب تسرب مسارات الخادم، معلومات التصحيح، أو تتبع المكدس.
6. التسجيل والفشل
   – لا ترجع رسائل خطأ مطولة تكشف معلومات للمتصلين غير المعتمدين. قم بتسجيل الفشل على جانب الخادم للتشخيص.
7. الاختبارات الآلية ومراجعة الكود
   – أضف اختبارات وحدة/تكامل تؤكد أن الطلبات غير المصرح بها تتلقى 401/403 ولا يمكنها الوصول إلى الحمولة الحساسة.
   – نفذ مراجعات كود تركز على الأمان للمسارات واستدعاءات AJAX.

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

استجابة الحوادث: إذا كنت تشك في حدوث خرق

1. تحتوي على:
   – قم بتحديث الإضافة على الفور إلى 1.3.1.
   – طبق قواعد WAF أو قم بتعطيل الإضافة مؤقتًا.
   – قم بتدوير أي مفاتيح API أو رموز مرتبطة بنظام الدعم.
2. الحفاظ على الأدلة:
   – أرشفة السجلات (سجلات خادم الويب، التطبيق، سجلات قاعدة البيانات) بشكل آمن للتحليل الجنائي.
   – لا تقم بكتابة فوق أو تقصير السجلات.
3. تقييم:
   – حدد البيانات التي قد تكون تعرضت (بريد المستخدمين، محتوى التذاكر، معرفات الطلبات).
   – حدد العملاء المتأثرين والإطار الزمني.
4. تعافى:
   – إعادة بناء الحسابات الم compromised أو إعادة تعيين بيانات الاعتماد حسب الحاجة.
   – تنظيف البرمجيات الخبيثة إذا تم تثبيتها كإجراء ثانوي.
5. إشعار:
   – إبلاغ المستخدمين المتأثرين والهيئات التنظيمية وفقًا للقوانين المعمول بها.
   – تقديم إرشادات للعملاء (مثل: تغيير كلمة المرور، تجاهل الرسائل المشبوهة).
6. بعد الحادث:
   – تعزيز العمليات: تدقيقات دورية للإضافات، ضبط مستمر لجدار الحماية، ومراجعات أمنية مجدولة.
   – النظر في اختبار الاختراق للإضافات الحرجة والرموز المخصصة.

كيف يحميك WP-Firewall (شرح نهجنا)

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

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

فلسفتنا: عندما يرتكب المطورون أخطاء (وهم سيفعلون)، يجب أن يمنع جدار الحماية الفعال ووضع الأمان تلك الأخطاء من أن تصبح اختراقات.

شرح منطق توقيع جدار الحماية (ما نقوم بحظره ولماذا)

عندما يكشف مكون إضافي عن نقطة نهاية ضعيفة، تشمل أنماط الاستغلال الآلي الشائعة:

• طلبات عالية الحجم إلى نفس نقطة النهاية، غالبًا ما تقوم بتعداد المعرفات.
• طلبات تتضمن معلمات استعلام نموذجية لأنظمة التذاكر: ticket_id، message_id، order_hash، إلخ.
• طلبات من وكلاء مستخدمين يستخدمهم الماسحات أو سلاسل الروبوت المعروفة.

ستقوم التوقيع المعقول بـ:

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

تمنع هذه الطريقة الاستغلال الجماعي مع تقليل الإيجابيات الكاذبة لحركة مرور المسؤولين الشرعية.

الأمن الأساسي الموصى به على المدى الطويل لمواقع WooCommerce

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

تقلل هذه التدابير من فرصة أن تؤدي ثغرة واحدة في الإضافة إلى خرق شديد.

التحقق والاختبار بعد تطبيق الإصلاحات

• اختبار وظيفة الإضافة من حساب مسؤول ومن حساب غير متميز لضمان السلوك الصحيح وأن تحقق التفويض يعمل بشكل صحيح.
• التحقق من أن نقاط النهاية التي كانت ضعيفة سابقًا تعيد الآن 401/403 للطلبات غير الموثوقة.
• إذا قمت بتنفيذ قواعد WAF، انقلها من الكشف إلى الحظر فقط بعد التحقق من أنها لا تحظر الطلبات الشرعية للمسؤولين.
• راقب السجلات لمحاولات متكررة ضد نقاط النهاية لعدة أيام بعد التصحيح.

الأسئلة الشائعة (إجابات سريعة)

س: هل تم اختراق موقعي بالتأكيد إذا استخدمت الإضافة؟

أ: ليس بالضرورة. تعرض الثغرات لا يعني أن الاستغلال قد حدث. تحقق من السجلات والمؤشرات الموضحة أعلاه. إذا وجدت علامات على وصول مشبوه، اتبع قائمة التحقق من استجابة الحوادث.

س: هل يجب أن أزيل الإضافة؟

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

س: هل يمكن لجدار حماية تطبيق الويب (WAF) أن يحل محل تحديث المكون الإضافي بالكامل؟

أ: لا - التحديث هو الحل الصحيح. يوفر WAF حماية مؤقتة فورية (تصحيح افتراضي) ويقلل من المخاطر حتى يتم تطبيق تصحيح كامل.

ائتمان الكشف المسؤول

تم الإبلاغ عن المشكلة بشكل مسؤول من قبل باحثي الأمن (شكرًا للباحث المذكور في الكشف) وتم إصلاحها من قبل مؤلف الإضافة في تحديث في الوقت المناسب. شكرًا لمجتمع الباحثين على تحديدهم والإبلاغ عن هذا النوع من المشكلات - الكشف المنسق والتصحيح ضروريان لسلامة النظام البيئي.

ابدأ بحماية مجانية مُدارة لموقع WooCommerce الخاص بك

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

• الأساسي (مجاني): جدار حماية مُدار، نطاق ترددي غير محدود، WAF، ماسح للبرمجيات الضارة، تخفيفات OWASP Top 10.
• المعيار ($50/السنة): أساسي بالإضافة إلى إزالة البرامج الضارة تلقائيًا والقدرة على وضع 20 عنوان IP في القائمة السوداء/القائمة البيضاء.
• برو ($299/السنة): قياسي بالإضافة إلى تقارير أمان شهرية، وتصحيح افتراضي تلقائي للثغرات، والوصول إلى إضافات متميزة مثل مدير حساب مخصص وخدمات أمان مُدارة.

ابدأ خطتك المجانية الآن واحصل على طبقة إضافية من التصحيح الافتراضي أثناء التحديث: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(يمكنك الترقية لاحقًا للحصول على تصحيح تلقائي وتقارير شهرية إذا كنت تدير متاجر متعددة.)

أفكار ختامية

التحكم في الوصول المكسور هو سبب متكرر للعديد من تسريبات بيانات WordPress. بالنسبة لمتاجر التجارة الإلكترونية، فإن المخاطر أعلى لأن بيانات العملاء حساسة والثقة أمر بالغ الأهمية. تؤكد الثغرة في نظام دعم ilGhera لـ WooCommerce على أهمية:

• التحديثات الفورية،,
• الدفاع المتعدد الطبقات مع WAF مُدار ومراقبة،,
• أفضل ممارسات المطورين (تحقق من الأذونات، الرموز غير المتكررة، أقل امتيازات)،,
• عملية استجابة للحوادث قوية.

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

الملحق: قائمة تحقق سريعة لمالكي المواقع (نسخ ولصق)

• تحديث نظام دعم ilGhera لملحق WooCommerce إلى 1.3.1.
• إذا لم يكن بالإمكان التحديث على الفور: تطبيق قاعدة WAF لحظر نقاط نهاية الملحق.
• تقييد الوصول إلى مجلد الملحق عبر إعدادات الخادم إذا كان ذلك ممكنًا.
• البحث في السجلات عن /wc-support-system/ أو استجابات 200 مشبوهة تعيد معلومات التعريف الشخصية.
• تغيير/تدوير أي رموز API خارجية تتعلق بالملحق.
• النظر في تعطيل الملحق مؤقتًا إذا لم يكن حرجًا.
• الاشتراك في جدار ناري مُدار مع تصحيح افتراضي للحماية حتى اكتمال التصحيح.

إذا كنت ترغب في المساعدة في تنفيذ أي من التخفيفات المذكورة أعلاه (قواعد WAF، المراقبة، أو استجابة الحوادث)، فإن فريق الدعم لدينا متاح للمساعدة في حماية متجرك على WooCommerce.