شرح هجمات منطق الأعمال

لا يقوم المهاجمون دائمًا باختراق الكود الخاص بك لسرقة الأموال.

يقضي العديد من المطورين شهورًا في تأمين واجهات برمجة التطبيقات (APIs) والتشفير. يركزون على منع هجمات SQL injection أو XSS. ثم يقوم المهاجم بسرقة الأموال دون كسر أي ضابط أمني واحد.

هذا هو هجوم منطق الأعمال (Business Logic Attack).

يعمل التطبيق تمامًا كما هو مصمم له. ببساطة، يستخدم المهاجم قواعدك الخاصة ضدك.

فكر في خزنة بنك. معظم الاختبارات الأمنية تتحقق مما إذا كان الباب قويًا. أما اختبار منطق الأعمال فيطرح سؤالًا مختلفًا: ماذا لو أقنع شخص ما الحارس بفتح الباب له؟

الخزنة تعمل، لكن العملية تفشل.

إليك ثلاث طرق يستغل بها المهاجمون المنطق المصرفي:

  1. تجاوز فترات الانتظار غالبًا ما تطلب البنوك انتظارًا لمدة 24 ساعة بعد إضافة مستلم جديد، وذلك لمنع السرقة السريعة. قد يجد المهاجم نقطة نهاية (API endpoint) تتخطى هذا التحقق، فيقوم بتجاوز قيود واجهة المستخدم (UI) ونقل الأموال فورًا.

  2. كسر حدود المعاملات قد يضع البنك حدًا يوميًا قدره 50,000. إذا كان الكود يتحقق من كل معاملة بشكل فردي فقط، فيمكن للمهاجم إرسال خمس تحويلات بقيمة 49,000 لكل منها. تبدو كل معاملة صالحة، والمجموع الكلي يتجاوز الحد، لكن النظام لا يلاحظ ذلك.

  3. إساءة استخدام المكافآت تمنح العديد من التطبيقات استردادًا نقديًا (cashback) عند دفع الفواتير. قد يقوم المهاجم بدفع فاتورة ثم إلغاؤها فورًا. إذا لم يقم النظام بسحب المكافأة، فسيقوم المهاجم بإنشاء حلقة مفرغة لجمع استرداد نقدي لا ينتهي.

لما لماذا تغفل أدوات الفحص الآلية عن هذا؟

تبحث أدوات الفحص عن العيوب التقنية مثل البرمجيات الخبيثة أو عمليات الحقن (injection). يرى الماسح عملية تحويل ناجحة ويعيد حالة 200 OK، فيعتقد أن كل شيء على ما يرام.

أما المختبر البشري فيسأل: هل كان ينبغي أن تتم هذه العملية من الأساس؟

لاكتشاف هذه العيوب، توقف عن السؤال عما إذا كان يمكن اختراق ميزة ما، وابدأ بالسؤال عما إذا كان يمكن إساءة استخدامها.

تحقق من هذه المجالات:

  • هل يمكن للمستخدمين تخطي خطوات التحقق؟
  • هل يمكن للمستخدمين تغيير ملكية معرف (ID) ما؟
  • هل يمكن تجاوز فترات الانتظار عبر الـ API؟
  • هل تُطبق الحدود على المبلغ الإجمالي أم على كل نقرة فقط؟
  • هل يمكن تفعيل المكافآت عدة مرات؟

الفرق الأمنية النخبوية لا تكتفي بإنشاء حالات الاستخدام (use cases)، بل تنشئ حالات الإساءة (abuse cases).

بدلًا من اختبار "المستخدم يحول الأموال"، اختبر "المهاجم يحاول إجراء 500 تحويل صغير لتجاوز الحدود".

السؤال الثاني هو الذي يكشف الخطر الحقيقي.

المصدر: https://dev.to/arashad_dodhiya_0e4bdba5a/business-logic-attacks-explained-using-a-banking-app-27hj