ثغرات منطق الأعمال في الـ API: الخطأ الذي لا يكتشفه أي سكانر وكيف تكتشفه بنفسك
يا جماعة، خلونا نتكلم بصراحة اليوم.
في المقالين السابقين فضحنا الـ 7 أخطاء الكارثية في أمن الـ API وشرحنا كيف نصلحها خطوة بخطوة. كثير ناس قرأوا وطبقوا، وهذا كويس. لكن في شيء أكبر وأخطر ما يتكلم عنه أحد بصراحة، وحتى اللي يتكلمون عنه يمرون عليه مرور الكرام كأنه شيء نظري.
اليوم بنفتح باب ما ينفتح بسهولة.
اللي بيخلي أغلب الـ APIs تنهار مو الثغرات اللي يكتشفها السكانر، ولا الـ IDOR الكلاسيكي، ولا حتى غياب الـ Rate Limiting. اللي بيخليها تنهار هو أخطاء منطق الأعمال (Business Logic Flaws) اللي ما تظهر في أي أداة آلية، وما يقدر يكتشفها إلا إنسان فاهم كيف يشتغل النظام فعليًا.
هذي الثغرات ما لها اسم جاهز في أغلب الأحيان، وما تطلع في تقرير OWASP Top 10 كبند واضح. بس هي اللي تسبب أكبر الخسائر المالية والسمعة في الواقع.
ليش هالنوع من الثغرات خطير جدًا؟
لأنها مش تقنية. هي منطقية.
السكانر ما يفهم إن "الطلب لازم يمر بثلاث مراحل قبل ما يتأكد"، أو إن "المبلغ لازم يكون أقل من رصيد الحساب في اللحظة دي"، أو إن "ما ينفع المستخدم يلغي الطلب بعد ما استلم المنتج". هذي أشياء بشرية بحتة. لازم تفهم المنتج، وتفهم الـ Flow، وبعدين تبدأ تكسره.
والمعظم ما يسوي كذا. يفتحون Burp Suite ويرمون Payloads جاهزة ويخلصون. والنتيجة؟ API "آمن" تقنيًا، لكنه مفتوح على مصراعيه من ناحية المنطق.
أمثلة حقيقية ودقيقة (مو نظري)
خلوني أعطيكم حالات شفتها بنفسي أو شفتها في تقارير حقيقية، مو من الكتب:
طلب استرجاع فلوس بعد الاستلام
التطبيق يسمح للمستخدم يطلب استرجاع المبلغ طالما الحالة "قيد التجهيز". المطور حط شرط على الحالة فقط.
المهاجم يرسل طلب استرجاع، وفي نفس الثانية يرسل طلب تغيير الحالة إلى "تم التسليم" من جهاز ثاني (أو حتى من نفس الجلسة لو ما في قفل). النتيجة؟ يستلم المنتج ويأخذ فلوسه.
السبب؟ ما في Atomicity ولا Race Condition Protection على مستوى العملية التجارية.
تغيير كمية المنتج بعد إضافة للسلة
المستخدم يضيف منتج سعره 1000 ريال بكمية 1. بعدين يروح يعدل الكمية في الـ Cart إلى 100، بس السعر يبقى محسوب على الكمية القديمة لأن الحساب صار في الـ Frontend أو في مرحلة سابقة.
لما يوصل للدفع، النظام يأخذ الكمية الجديدة والسعر القديم.
هذي ما تطلع في أي سكانر عادي، لأن كل طلب على حدة "صحيح".
استغلال نقاط الولاء أو الكوبونات
النظام يعطي 10 نقاط مقابل كل 100 ريال. المستخدم يشتري، يأخذ النقاط، بعدين يلغي الطلب. النقاط ما تنحذف. أو يستخدم كوبون خصم 50%، بعدين يغير المنتج لمنتج أغلى والكوبون يبقى شغال.
السبب؟ التحقق من صلاحية الكوبون صار مرة واحدة في البداية، وما عاد يتكرر عند كل تغيير.
الـ Multi-step Process بدون State Validation
عملية تسجيل حساب أو فتح حساب بنكي تمر بـ 4 خطوات. كل خطوة لها Endpoint منفصل.
المهاجم يتخطى الخطوة 2 و 3 ويروح مباشرة للخطوة 4 بحالة "مكتمل". النظام يقبل لأن كل Endpoint يتحقق من وجود Token فقط، مو من تسلسل الخطوات.
هذي أمثلة بسيطة. في تطبيقات حقيقية الوضع أسوأ بكثير.
كيف تكتشف هالنوع من الثغرات بنفسك؟ (الطريقة اللي ما يعلمونها)
ما تحتاج أدوات غالية. تحتاج عقلية مختلفة:
ارسم الـ Business Flow كامل على ورقة أو Miro. كل خطوة، كل شرط، كل حالة ممكنة.
اسأل نفسك في كل نقطة:
وش لو سويت هالخطوة مرتين؟
وش لو سويتها بترتيب غلط؟
وش لو غيرت قيمة بعد ما اعتمدت عليها خطوة لاحقة؟
وش لو سويت خطوتين في نفس الوقت من جلستين مختلفتين؟
استخدم حسابين أو ثلاثة في نفس الوقت (واحد عادي وواحد "مميز" وواحد ضيف).
ركز على العمليات اللي فيها فلوس أو صلاحيات أو تغيير حالة نهائي (طلب، دفع، إلغاء، ترقية، حذف).
جرب Race Conditions يدويًا: افتح نفس الطلب في تبويبين وأرسل في نفس اللحظة تقريبًا.
الأدوات تساعد (Burp Intruder مع Timing، أو Turbo Intruder)، لكن الأداة ما تفكر عنك. أنت اللي لازم تفكر.
ليش أغلب المطورين وفرق الأمن يفشلون هنا؟
لأنهم يركزون على "الثغرات التقنية" اللي تطلع في التقارير وتبان حلوة في الـ CV. أما أخطاء المنطق فتحتاج وقت وفهم عميق للمنتج، وما تطلع بسهولة في الـ Bug Bounty أحيانًا لأن الشركات ما تحب تعترف إن منطق أعمالها فيه ثغرات.
النتيجة؟ تطبيقات "محمية" تقنيًا، لكنها تنهار من أول ما يجي مستخدم ذكي أو مهاجم يفهم المنتج أكثر من المطور نفسه.
الخلاصة اللي أبيك تطلع فيها
الأمان الحقيقي مو بس "هل الـ Token صحيح؟" و"هل الـ ID يخصك؟". الأمان الحقيقي هو: هل النظام يمنع السلوك اللي ما يفترض يصير حتى لو كل طلب لوحده يبدو شرعي؟
لو ما كنت تختبر منطق الأعمال بنفس قوة ما تختبر الـ Injection والـ IDOR، فأنت ما زلت تبني على رمل.
هالمقال مو عشان نخوف أحد. عشان نرفع المستوى. الثغرات التقنية صارت معروفة، أما الثغرات المنطقية فما زالت الملعب المفتوح.
لو عندك مثال صار لك أو شفته في تطبيق حقيقي، اكتبه في التعليقات. نبي نكسر هالموضوع أكثر.
خلونا نكمل المسار اكتب تعليق جميل زيك
تعليقات