تهديد Magecart الذي لم تتهيأ له صفحات الدفع الجزائرية
شهد قطاع التجارة الإلكترونية الجزائري نموًا ملحوظًا في السنوات الأخيرة، إذ باتت منصات مثل Chargily و Satim والبوابات المرتبطة بـ CIB تعالج تدفقات مدفوعات حقيقية لآلاف التجار المحليين. غير أنه مع تنامي المدفوعات الرقمية تتوسع أيضًا مساحة الهجوم. Magecart — المصطلح الشامل للجهات الخبيثة التي تحقن كود JavaScript ضارًا في صفحات الدفع الإلكتروني — تشن حملة نشطة منذ مطلع 2022 تستهدف تحديدًا شبكات الدفع الأكثر صلة بالمستهلكين الجزائريين: Mastercard و UnionPay.
الآلية بسيطة ومدمرة. يخترق المهاجمون إما الموقع الإلكتروني للتاجر مباشرة أو سكريبتًا خارجيًا يحمّله التاجر عند الدفع (شبكة توصيل محتوى CDN أو مكتبة تحليلات أو SDK دفع). بمجرد الدخول، يحقنون بضعة أسطر من كود JavaScript المبهم الذي يقرأ بصمت حقول النماذج التي تحتوي على أرقام البطاقات وتواريخ الانتهاء ورموز التحقق من البطاقة (CVC) وعناوين الفواتير أو الشحن. تُلتقط البيانات لحظة نقر العميل على “ادفع” وتُرسَل إلى خوادم يتحكم فيها المهاجمون.
لماذا التجار الجزائريون معرضون بشكل خاص
ثلاث حقائق هيكلية تجعل تجار التجارة الإلكترونية الجزائريين أكثر عرضة للخطر من نظرائهم في الأسواق ذات منظومات مكافحة الاحتيال الناضجة.
أولًا، تنوع حزم SDK للدفع محدود وتيرة التحديث بطيئة. معظم التجار الجزائريين الذين يستخدمون Chargily أو البوابات المرتبطة بـ CIB يدمجون أداة JavaScript يوفرها معالج الدفع. إذا كانت هذه الأداة تُقدَّم من نقطة CDN مشتركة، فإن الاختراق في المصدر العلوي يؤثر في جميع التجار في المصب في آنٍ واحد.
ثانيًا، اعتماد Content Security Policy (CSP) شبه معدوم. CSP هو رأس HTTP يخبر المتصفحات بالنطاقات المسموح لها بتحميل JavaScript. سياسة CSP مهيأة بشكل صحيح ستحجب أي سكريبت محقون يحاول إرسال البيانات إلى نطاق المهاجم.
ثالثًا، مراقبة صفحات الدفع غائبة. تستمر عمليات حقن Magecart دون اكتشافها لأسابيع أو أشهر لأن التجار لا يمتلكون أدوات تنبيه عند تغيير مخزون JavaScript في صفحة الدفع.
إعلان
ما يجب على التجار الجزائريين فعله
1. تطبيق Subresource Integrity (SRI) لكل سكريبت خارجي
Subresource Integrity (SRI) آلية في المتصفح تتيح لك تثبيت سكريبت خارجي على هاش تشفيري محدد. إذا تم تعديل الملف على تلك الرابطة — حتى بحرف واحد — يرفض المتصفح تنفيذه. يجب أن تحمل كل وسم يحمّل SDK دفع أو مكتبة تحليلات سمة integrity="sha384-...". هذا التغيير الوحيد يُزيل أشيع متجهات Magecart: الاختراق من جانب الخادم لملف CDN مشترك. تكلفة التطبيق ساعة واحدة من وقت المطور لكل تكامل، والحماية فورية.
2. نشر Content Security Policy بتوجيه script-src صارم
رأس Content Security Policy، المضاف على مستوى خادم الويب أو CDN، يخبر المتصفحات بالنطاقات التي يمكنها تحميل JavaScript على صفحة الدفع. مثال حد أدنى لتاجر يستخدم أداة Chargily فقط: Content-Security-Policy: script-src 'self' https://js.chargily.com; object-src 'none'. أي سكريبت Magecart محقون يحاول إرسال بيانات البطاقة إلى نطاق مهاجم سيُحجب. ابدأ بتعيين الرأس في وضع Content-Security-Policy-Report-Only لمدة أسبوعين لتحديد السكريبتات الخارجية الشرعية التي قد تكون فاتتك، ثم انتقل إلى وضع التطبيق.
3. عزل صفحات الدفع خلف نطاق أو نطاق فرعي منفصل
تنتشر عمليات حقن Magecart عادةً من نظام إدارة محتوى مصاب إلى جميع صفحات نفس الأصل. تدفقات الدفع التي تعمل على نطاق فرعي منفصل (pay.متجرك.dz) تمتلك نطاق انتشار أصغر بكثير. حتى لو تعرضت الواجهة الرئيسية للاختراق، لا يمكن لعملية حقن على store.dz قراءة سياق JavaScript الخاص بـ pay.store.dz بسبب سياسة نفس الأصل في المتصفح.
4. إجراء عمليات تدقيق أسبوعية لمخزون JavaScript
كل أسبوع، يجب أن يزحف سكريبت على رابطة صفحة الدفع لديك ويعدّد كل ملف JavaScript محمّل — بعنوان URL وحجم الملف وهاش SHA-256 للمحتوى. يكشف الفرق بين عمليات التشغيل عن أي سكريبت مضاف أو معدل أو محذوف. يمكن تطبيق ذلك في أقل من 30 سطرًا من Python.
5. إخطار معالج الدفع فورًا عند الاشتباه بأي حقن
إذا اكتشفت سكريبتًا غير متوقع على صفحة الدفع، اعزل الصفحة عن حركة المرور المباشرة في دقائق لا أيام. تواصل مع معالج الدفع (Chargily أو CIB أو Satim) عبر جهة اتصال التصعيد الخاصة بالاحتيال. بموجب القانون الجزائري رقم 25-11 بشأن حماية البيانات الشخصية، يُلزَم مراقبو البيانات بإخطار الهيئة الوطنية لحماية البيانات الشخصية (ANPDP) خلال 5 أيام من اكتشاف الخرق.
الدرس الهيكلي
Magecart ليس هجومًا متطورًا من دولة قومية. إنه حملة صناعية منخفضة التكلفة مستمرة منذ ما يقارب أربع سنوات لأن الاقتصاديات تصب في مصلحة المهاجمين: نقطة CDN واحدة مخترقة تُنتج آلاف صفحات الدفع المصابة، ومعظم التجار لا يكتشفون الخرق إلا عندما يتصل بهم فريق مكافحة الاحتيال في البنك.
شبكات الدفع الستة المستهدفة تحديدًا — بما فيها Mastercard و UnionPay اللتان تمثلان محور منظومة الدفع بالبطاقات في الجزائر — تعني أن التعرض الجزائري ليس نظريًا. التجار الذين يعززون صفحاتهم الآن، قبل وقوع الخرق، يحمون عملاءهم ويتجنبون العقوبات التنظيمية بموجب القانون 25-11.
الأسئلة الشائعة
هل يستهدف Magecart الشركات الكبيرة فقط أم أن التجار الجزائريين الصغار معرضون أيضًا؟
التجار الصغار والمتوسطون هم المستهدفون بشكل غير متناسب تحديدًا لأنهم يفتقرون إلى فرق الأمن وأدوات المراقبة التي تنشرها المنصات الكبرى. كثيرًا ما تخترق حملات Magecart مزودي استضافة مشتركة أو إضافات تجارة إلكترونية شائعة يستخدمها آلاف التجار الصغار في آنٍ واحد. إذا كنت تدير متجرًا على WooCommerce أو PrestaShop أو Magento في الجزائر، فأنت ضمن مساحة الهجوم بصرف النظر عن حجم إيراداتك.
إذا استخدمت صفحة دفع مستضافة من Chargily أو CIB، هل أنا محمي؟
صفحة الدفع المستضافة بالكامل — حيث يُعاد توجيه العميل إلى النطاق الخاص بالمعالج لإدخال بيانات البطاقة — تقلل من خطرك بشكل كبير لأن Magecart لا يستطيع حقن JavaScript في صفحة لا يتحكم فيها خادمك. ومع ذلك، يستخدم كثير من التجار أدوات JavaScript مدمجة تحمّل نموذج الدفع مباشرة على نطاقهم الخاص، مما يُعيد التعرض. تحقق من معالج الدفع لديك بشأن وضع التكامل الذي تستخدمه.
ما الحد الأدنى الذي يمكن للتاجر فعله اليوم إذا لم يكن لديه مطور متاح؟
الإجراء الأعلى تأثيرًا دون مطور هو تفعيل تقرير مشكلات الأمان في Google Search Console والاشتراك في مراقبة مجانية للموقع من خدمة كـ Sucuri. الإجراء الثاني، الذي يتطلب وقتًا أدنى من المطور، هو تدقيق حاوية GTM للبحث عن أي وسوم غير معروفة أضيفت بعد آخر تاريخ سليم معروف.
---
المصادر والقراءات الإضافية
- المتسوقون عبر الإنترنت في خطر مع استهداف Magecart لشبكات الدفع الكبرى — Malwarebytes
- MRC تُصدر تقرير 2026 العالمي للمدفوعات والاحتيال في التجارة الإلكترونية — Merchant Risk Council
- تهديدات أمن التجارة الإلكترونية في 2026 — Anura
- الجزائر: حماية البيانات وقوانين الأمن السيبراني — CMS Law
- دليل اختبار أمن الويب OWASP — OWASP














