حين يكتب أحد العملاء رقم بطاقته الائتمانية على صفحة الدفع في متجرك الإلكتروني، فإن متصفحه لا يُشغّل شيفرتك البرمجية وحدها. تعمل في الخلفية عشرات السكريبتات الخارجية في آنٍ واحد: وسوم التحليلات، ومُدير الوسوم، وأداة الدعم الفني، وإطار عمل الدفع. أيٌّ من هذه الأدوات يمكن تحويله إلى أداة تجسس خفية تسرق بيانات الدفع قبل أن تصل إلى بوابتك الآمنة.
هذه ليست سيناريوهات افتراضية، بل هو النمط الذي تعمل به مجموعات القرصنة المعروفة بـ Magecart، ولقد تطور هذا النوع من الهجمات ليصبح أحد أخطر التهديدات التي تواجه التجارة الإلكترونية عالمياً. وفقاً لتقارير شركة Sansec المتخصصة في الأمن الرقمي، تجاوز عدد المواقع التي تضررت من هجمات سرقة البيانات عبر الويب وهجمات سلسلة التوريد حاجز مئة ألف موقع. أما اختراق شركة British Airways عام 2018 فقد كشف عن بيانات ما يقارب 380 ألف معاملة مالية، وأسفر عن غرامة ابتدائية بلغت 183 مليون جنيه إسترليني قبل أن تُخفَّض لاحقاً.
كيف تنجح هجمات Magecart رغم اعتماد الشركات على الوثوق بسكريبتاتها
الجانب الأشد خطورة في هذه الهجمات يكمن في طريقة وصول الشيفرة الخبيثة إلى المواقع المستهدفة. في أغلب الحالات، لا تأتي هذه الشيفرة عبر ثغرة مباشرة في موقعك، بل تصل مُختبئةً داخل سكريبت تابع لجهة خارجية تثق بها وتستخدمها منذ أشهر. يقوم المهاجمون باختراق أحد موردي الخدمات الرقمية التي تعتمد عليها، مثل أداة تحليل الزيارات أو نظام الدردشة الفورية مع العملاء، ثم يُدرجون حمولتهم الخبيثة داخل الملف المُحدَّث الذي يُوزَّع تلقائياً على كل المواقع التي تستخدم تلك الخدمة.
ما يجعل الأمر بالغ الخطورة هو أن لا شيء يبدو مختلفاً للوهلة الأولى. الملف موجود كما كان، والاسم لم يتغير، والمصدر هو نفسه. لكن ما تغيّر هو سلوك السكريبت، إذ بات يرصد حقول إدخال بيانات البطاقة ويُرسلها إلى خوادم المهاجمين بشكل صامت ودون أي إشارة مرئية للمستخدم أو المشغّل.
هذا النوع من الهجمات يُصنَّف ضمن ما يُعرف بهجمات سلسلة التوريد الرقمية، حيث يكون الهدف الفعلي ليس المتجر الإلكتروني مباشرةً، بل أحد الأطراف الثالثة التي يثق بها ويعتمد عليها.
متطلبات PCI DSS الإصدار 4.0.1 تُغلق الثغرة بقواعد إلزامية
استجابةً لتصاعد هذه التهديدات، جاء الإصدار الأحدث من معيار أمن بيانات صناعة بطاقات الدفع PCI DSS بمتطلبَين جديدَين باتا سارَي المفعول بشكل كامل:
المتطلب الأول 6.4.3: يُلزم التجار بجرد شامل لكل سكريبت على صفحات الدفع، مع التحقق من صلاحيته وإثبات سلامته.
المتطلب الثاني 11.6.1: يُوجب اكتشاف أي تعديل على محتوى الصفحة أو ترويسات HTTP في اللحظة التي يتلقاها المتصفح.
تطبيق هذين المتطلبَين يدوياً يمثّل تحدياً تشغيلياً ضخماً. فمن يُسيطر على مئات السكريبتات المتغيّرة باستمرار؟ تُظهر بيانات شركة Reflectiz المتخصصة في رصد سلوك صفحات الويب أن قرابة 30 بالمئة من سكريبتات صفحات الدفع تتغير خلال أي نافذة زمنية بسيطة لا تتعدى أسبوعَين. هذا الواقع يجعل المراقبة اليدوية غير فعّالة من الناحية العملية، وتحويل المسؤولية إلى فريق بشري دون أدوات آلية يُعرّض المؤسسة لمخاطر جسيمة وغرامات باهظة.
ما وجده مقيّمون مستقلون عند اختبار منصة Reflectiz
أجرت شركة Integrity360 Europe، وهي جهة تقييم مؤهلة وعضو في مجلس معايير PCI SSC العالمي، مراجعة شاملة لمنصة Reflectiz المخصصة للامتثال لمعيار PCI DSS، ووجدت أنها قادرة على دعم الامتثال لكلا المتطلبَين بفاعلية.
برزت ثلاثة محاور رئيسية خلال التقييم: أولها أن المنصة ترصد السلوك لا مجرد بصمات الملفات، وهو ما يُعدّ نقلة نوعية. فالتحقق من البصمة الرقمية للملف يمكن أن يُخطئ حين يُجري المورّد تحديثاً صامتاً من جانبه دون تغيير في الاسم، لكن Reflectiz تكتشف السكريبت في اللحظة التي يبدأ فيها بالوصول إلى حقول بيانات البطاقة. ثانيها أن النشر لا يستلزم تعديلات في الكود أو إضافة أجزاء برمجية جديدة، وأن الإعداد يكتمل في غضون أيام، مع استمرار العمل حتى عبر عمليات إعادة الهيكلة وترحيل أنظمة إدارة المحتوى. ثالثها أن المنصة تُنتج سجلات مراجعة جاهزة لتسليمها للمقيّمين بنقرة واحدة، تشمل مسار تدقيق كاملاً لكل صفحة.
يعكس هذا التقييم المستقل أهمية متزايدة للاعتماد على حلول آلية في ظل تصاعد تعقيد بيئات الويب وتشابك الاعتماديات على الأطراف الثالثة. وقد تحولت صفحة الدفع من نقطة تقنية بسيطة إلى ساحة مواجهة أمنية متشعّبة تستلزم مراقبة سلوكية متواصلة.
استثناء SAQ A ومتى لا ينقذك التحويل الكامل من الالتزام بالمتطلبَين
منذ يناير 2025، أتاح معيار PCI DSS لفئة معينة من التجار إمكانية إسقاط المتطلبَين 6.4.3 و11.6.1 من استبيان SAQ A، لكن بشرط محدد وصارم: إثبات أن الموقع غير قابل للتأثر بهجمات السكريبتات.
إن كنت تعتمد التحويل الكامل إلى بوابة الدفع بحيث تُغادر صفحتك تماماً قبل إدخال بيانات البطاقة، فأنت على الأرجح بمنأى عن هذه المتطلبات. أما إن كنت تستخدم إطار عمل الدفع المُدمج في صفحتك الأم، فالأمر مختلف جذرياً. سكريبت على الصفحة الأم يستطيع نظرياً اعتراض عملية الدفع قبل أن تصل البيانات إلى الإطار الآمن، وعليك إثبات استحالة ذلك. السؤال الدقيق هنا هو المكان الفعلي الذي تنتقل منه بيانات الدفع، ومتى تصبح بعيدة عن متناول أي سكريبت خارجي على صفحتك. وقد أشار الـ FAQ رقم 1588 الصادر عن PCI SSC صراحةً إلى أن هذه الضوابط تظل سارية في حالات إطارات الدفع المُدمجة.
هذا التمييز الدقيق بين سيناريوهات التحويل الكامل وسيناريوهات الإطار المُدمج يُمثّل أحد أبرز المزالق التي يقع فيها التجار حين يفترضون خاطئين أنهم بمنأى عن الالتزام بهذه المتطلبات.
