هجمات اختبار البطاقات: كيف تكتشف تخمين أرقام البطاقات وتوقفه

فريق Visatk · ١٦ أكتوبر ٢٠٢٦ · 9 دقائق قراءة · Read in English

تعرّف على كيفية اكتشاف هجمات اختبار البطاقات وإيقافها: أهم المؤشرات، وقواعد السرعة، وأنماط BIN، وCAPTCHA، و3-D Secure، والمراقبة لحماية صفحة الدفع لديك.

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

يشرح هذا الدليل كيف يعمل اختبار البطاقات (ويُسمّى أيضًا تعداد البطاقات أو الكاردينج)، والمؤشرات التي تكشفه، ومجموعة متعددة الطبقات من الضوابط التي توقفه دون الإضرار بالعملاء الحقيقيين.

ما هو هجوم اختبار البطاقات؟ #

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

وهناك نوعان رئيسيان:

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

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

لماذا يُستهدف التجار؟ #

يفضّل المهاجمون صفحات الدفع التي تتسم بالخصائص التالية:

• مبالغ منخفضة أو يحددها المستخدم، مثل التبرعات أو الإكراميات أو التسعير الحر (ادفع ما تشاء).
• الدفع كضيف دون حساب أو تحقق من البريد الإلكتروني أو تسجيل دخول.
• مسارات التحقق من البطاقة، مثل التفويضات بقيمة صفرية أو منخفضة عند إضافة بطاقة إلى المحفظة.
• رسائل خطأ تفصيلية تكشف بالضبط أي حقل فشل.
• غياب تحديد معدل الطلبات (Rate Limiting) على نقطة الدفع أو على واجهة برمجة الدفع المتاحة للمتصفح.
• واجهات برمجة دفع (APIs) يمكن استدعاؤها مباشرة مع تجاوز الواجهة الأمامية.

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

تكاليف اختبار البطاقات #

المؤشرات التي تكشف اختبار البطاقات #

لا يوجد مؤشر واحد حاسم. يُكتشف اختبار البطاقات بدمج عدة مؤشرات ضعيفة لتكوين مؤشر قوي.

مؤشرات الحجم والسرعة #

• زيادة مفاجئة في محاولات الدفع لا تقابلها زيادة في زيارات صفحات المنتجات أو نشاط سلة التسوق.
• محاولات كثيرة في الدقيقة من عنوان IP واحد أو نطاق IP أو بصمة جهاز أو جلسة أو حساب.
• أرقام بطاقات مختلفة كثيرة يستخدمها عميل أو بريد إلكتروني أو جهاز أو عنوان شحن واحد.
• محاولات في ساعات غير معتادة مقارنة بنمط الزيارات الطبيعي لديك.

مؤشرات أنماط الرفض #

• ارتفاع حاد في معدل الرفض الإجمالي، خاصة إذا تركّز على نقطة طرفية واحدة.
• أعداد كبيرة من الردود التي تشير إلى رقم بطاقة غير صالح أو بطاقة منتهية الصلاحية أو CVV غير صحيح أو "do not honor" (عدم الاعتماد).
• كثير من حالات عدم تطابق CVV وفشل AVS خلال فترة قصيرة. يشرح مرجع رموز استجابة AVS وCVV كل نتيجة.
• إعادة محاولة رقم البطاقة نفسه بتواريخ انتهاء أو رموز أمان مختلفة.

مؤشرات BIN وأنماط البطاقات #

• مجموعة من المحاولات تشترك في رقم BIN نفسه المكوّن من 6 أو 8 أرقام.
• أرقام بطاقات متسلسلة أو شبه متسلسلة ضمن نطاق واحد.
• دول بطاقات لا تتطابق مع قاعدة عملائك المعتادة.
• تركّز غير معتاد للبطاقات المدفوعة مسبقًا أو لمنتجات بطاقات بعينها.

يُظهر لك فحص البادئات المشبوهة باستخدام فاحص BIN الجماعي بسرعة ما إذا كانت موجة الزيارات تتركّز على بنك مُصدِر أو دولة أو نوع بطاقة واحد.

مؤشرات الطلبات والسلوك #

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

بناء قواعد السرعة (Velocity Rules) #

تحدّ قواعد السرعة من عدد مرات حدوث أمر ما خلال نافذة زمنية محددة، وهي العمود الفقري للدفاع ضد اختبار البطاقات. ابدأ بحدود متحفظة مبنية على حركة المعاملات المشروعة لديك، ثم شدّدها بناءً على البيانات.

نصائح لقواعد سرعة فعّالة #

• استخدم مفاتيح متعددة. يبدّل المهاجمون عناوين IP باستمرار، لذا اعتمد أيضًا على بصمة الجهاز والحساب والبريد الإلكتروني وبصمة البطاقة (رقم PAN مُشفّر بدالة Hash) ورقم BIN وعنوان الشحن.
• استخدم نوافذ زمنية منزلقة. اجمع بين نوافذ قصيرة (بالدقائق) لرصد الموجات المفاجئة ونوافذ طويلة (بالساعات أو الأيام) لرصد الهجمات البطيئة والموزعة.
• قارن بخطوط الأساس. الحدود المطلقة تنهار خلال مواسم الذروة في المبيعات. أما الحدود النسبية المبنية على المتوسطات المتحركة فتتكيف بشكل أفضل.
• استجب تدريجيًا. تدرّج من التقييم غير المرئي إلى التحديات ثم الحظر، حتى لا يكلّف الإنذار الكاذب العميل سوى بضع ثوانٍ بدلًا من خسارة عملية بيع.
• لا تخزّن أرقام PAN الخام أبدًا لأغراض عدّ السرعة. استخدم بصمة البطاقة التي توفرها جهة المعالجة أو Hash بمفتاح ضمن نطاق PCI لديك.

ضوابط متعددة الطبقات لإيقاف اختبار البطاقات #

1. إدارة الروبوتات وCAPTCHA #

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

2. بروتوكول 3-D Secure (EMV 3DS) #

يتيح 3-D Secure للبنك المُصدِر التحقق من هوية حامل البطاقة، غالبًا دون أي احتكاك باستخدام بيانات الجهاز والمعاملة، ومع تحدٍّ للتحقق عندما تكون المخاطر أعلى. وهو يجعل الاختبار أصعب، وفي كثير من المناطق قد ينقل مسؤولية الاحتيال إلى البنك المُصدِر في المعاملات المصادَق عليها. فكّر في اشتراط 3DS للفئات عالية المخاطر: العملاء الجدد، وأرقام BIN غير المعتادة، والدول غير المتطابقة، والجلسات التي بلغت حدود السرعة بالفعل.

3. تحصين نقطة الدفع #

• اشترط وجود جلسة صالحة وسلة تسوق ورمز (Token) مُولَّد من الخادم قبل قبول أي طلب دفع.
• طبّق تحديد معدل الطلبات على الحافة (CDN أو WAF) وداخل التطبيق.
• لا تكشف مفاتيح API السرية في كود الواجهة الأمامية، وقيّد المفاتيح القابلة للنشر بالنطاقات التي تتحكم فيها.
• احظر الطلبات المباشرة التي تتخطى تسلسل الصفحات المتوقع أو أخضعها لتحدٍّ للتحقق.

4. قلّل المعلومات التي تكشفها #

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

5. ارفع تكلفة كل محاولة #

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

6. التزم بقواعد إعادة المحاولة #

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

7. استخدم معلومات BIN بحذر #

عندما يتركّز الهجوم على BIN معين، يمكنك إضافة احتكاك مؤقت لهذا النطاق، مثل اشتراط 3DS. استخدم فاحص BIN للتأكد من البنك المُصدِر والدولة ونوع البطاقة قبل كتابة القواعد. وتجنّب الحظر الدائم والشامل لأرقام BIN، إذ قد يمنع العملاء الحقيقيين لهذا البنك المُصدِر من الشراء لفترة طويلة بعد انتهاء الهجوم.

8. استفد من أدوات جهة المعالجة #

توفر معظم بوابات الدفع وجهات المعالجة تقييمًا لمخاطر الاحتيال، واكتشافًا لاختبار البطاقات، ومحركات قواعد، ولوحات متابعة. فعّلها، وراجع إعداداتها الافتراضية، وادمج مؤشراتها في نظام المراقبة الخاص بك.

المراقبة والتنبيهات #

كثيرًا ما تبدأ الهجمات ليلًا أو في عطلات نهاية الأسبوع حين لا يراقب أحد. والمراقبة الفورية تحوّل حادثة مكلفة إلى حادثة قصيرة.

المقاييس التي ينبغي تتبّعها #

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

تصميم التنبيهات #

• استدعِ أحد أفراد الفريق فورًا عندما يتجاوز معدل الرفض أو حجم المحاولات مضاعفًا لخط الأساس لفترة متواصلة.
• أرسل إشعارات أقل أولوية للحالات الشاذة الأصغر حتى تتمكن من رصد الهجمات البطيئة.
• جهّز مفتاحًا لتفعيل "الوضع الأكثر صرامة" يُفعّل التحديات الإلزامية و3DS خلال دقائق.

خطة الاستجابة للحوادث #

1. تأكّد من وقوع الهجوم. افحص حجم المحاولات وأسباب الرفض وتجمّع أرقام BIN.
2. احتوِ الهجوم. فعّل الوضع الأكثر صرامة: التحديات، وحدود سرعة أشد، و3DS للحركة عالية المخاطر، وتحديد معدل الطلبات على الحافة.
3. احظر الواضح. احظر مؤقتًا نطاقات IP والأجهزة والحسابات المسيئة. وراجع ملكية عناوين IP قبل حظر نطاقات كبيرة حتى لا تقطع الوصول عن شبكات مشروعة.
4. أوقف نزيف عمليات القبول. ألغِ عمليات التفويض الاختبارية الناجحة أو استردّ مبالغها قبل تسويتها كلما أمكن، فهذا يقلل نزاعات الاسترداد لاحقًا.
5. أبلغ البنك المستحوذ. التواصل الاستباقي عادةً أفضل من أن يكتشف البنك المستحوذ الارتفاع بنفسه.
6. حقّق في الأمر. حدّد نقطة الدفع التي أُسيء استخدامها وكيف حدث ذلك. استخدم أداة التحقيق في الاحتيال لتحليل عينات من المعاملات المشبوهة.
7. عالج الأسباب الجذرية. أغلق واجهات API المكشوفة، وأضف حدود معدل الطلبات الناقصة، وعدّل القواعد.
8. راجع ما حدث بعد ذلك. وثّق التسلسل الزمني والخسائر والدروس المستفادة، وأضف اختبارات أو تنبيهات كانت ستكشف الهجوم مبكرًا.

اختبار دفاعاتك بأمان #

ينبغي للمطورين التحقق من الدفاعات في بيئة تجريبية (Sandbox)، وليس أبدًا على نقاط دفع حقيقية بأرقام بطاقات حقيقية. استخدم أرقام البطاقات التجريبية وردود الرفض المحاكاة التي توفرها جهة المعالجة، وولّد أرقامًا صحيحة الصيغة لاختبارات التحقق في الواجهة الأمامية باستخدام مولّد أرقام البطاقات التجريبية. ويمكن لاختبارات الحمل المحاكاة على بيئة Staging التأكد من أن حدود معدل الطلبات والتنبيهات لديك تعمل كما هو مخطط.

الأسئلة الشائعة #

#اختبار البطاقات#مكافحة الاحتيال#هجوم BIN#قواعد السرعة#أمان صفحة الدفع