هجوم Race Condition وخطورة التوقيت في السيرفر

في اختبار الاختراق اتعودنا ندوّر على ثغرات سببها إدخال خبيث زي: XSS - SQL Injection - Command Injection
لكن فيه نوع أخطر بكتير…
ثغرات مش محتاجة Payload ولا بتكسر Validation ولا بتغير أي قيمة
ومع ذلك… تأثيرها ممكن يبقى كارثي هنا بنتكلم عن Race Condition Attacks

الفكرة الأساسية قبل أي تعريف ​

السيرفر غالبًا بيفترض حاجة بسيطة جدًا:

• الطلبات هتوصل بالترتيب
• الطلب الأول يخلص قبل ما التاني يبدأ

الافتراض ده غالبًا صحيح بس بيقع تمامًا لما:

• تبعت أكتر من طلب في نفس اللحظة

Race Condition لا تستغل خطأ في التحقق لكن تستغل الفجوة الزمنية بين:

• Check (التحقق)
• Update (تحديث الحالة)

---

​

السيرفر بيفكر إزاي أصلًا؟ ​

في أغلب الأنظمة، السيناريو بيبقى كده:
استقبال الطلب
التحقق من الحالة (هل مسموح؟)
تنفيذ العملية
تحديث الحالة

المشكلة إن الخطوات دي مش دايمًا Atomic يعني ممكن طلب تاني:

• يعدّي مرحلة التحقق
• قبل ما الطلب الأول يحدّث الحالة

وهنا تبدأ المصيبة

---

​

مثال عملي بسيط (من غير أدوات) ​

تخيّل سيناريو شائع جدًا: 🎟 كوبون خصم يُستخدم مرة واحدة
السيرفر بيعمل الآتي:

• هل الكوبون مستخدم؟ لا
• إذًا استخدمه

دلوقتي تخيّل:

• إرسال 5 طلبات في نفس اللحظة
• كل طلب بيسأل نفس السؤال
• قبل ما حالة الكوبون تتحدّث

النتيجة؟

• الكوبون اتستخدم 5 مرات

ما غيرناش أي قيمة
ما كسرناش Validation
بس استغلينا التوقيت

---

​

مثال منطقي مبسّط بالكود ​

if coupon.used == false:
    apply_discount()
    coupon.used = true

الكود ده شكله سليم لكن لو اتنفّذ بالتزامن مفيش Lock ولا Transaction
يبقى عرضة لـ Race Condition

---

​

ليه Race Condition خطيرة جدًا؟ ​

لأنها ممكن تؤدي إلى:

• مضاعفة الرصيد
• تكرار عمليات مالية
• إنشاء موارد غير محدودة
• تجاوز قيود “مرة واحدة فقط”
• الحصول على صلاحيات إضافية

وغالبًا بتتصنّف: High / Critical Severity

---

​

ليه أدوات الفحص الآلي مش بتكتشفها؟ ​

لأن:

• مفيش Payload معروف
• مفيش Error Message
• مفيش Pattern ثابت

الـ Scanners بتشتغل كده: ابعت طلب ➜ استقبل رد لكن Race Condition محتاجة:
ابعت طلبات متزامنة ➜ راقب السلوك
وده فرق جوهري

---

​

Race Condition بتظهر فين غالبًا؟ ​

• أنظمة الدفع
• الكوبونات والخصومات
• التسجيلات
• تغيير كلمات المرور
• استهلاك الرصيد أو النقاط
• APIs اللي بتتعامل مع State

خصوصًا الأنظمة اللي بتفترض إن: الطلبات مش هتتزامن

إزاي بيفكر مختبر الاختراق المحترف؟ ​

السؤال مش: هل الطلب ده آمن؟
لكن: ماذا لو اتبعت أكتر من مرة؟ وفي نفس اللحظة؟
التحول في التفكير ده هو الفرق الحقيقي بين: مبتدئ مختبر اختراق محترف

---

​

إزاي نمنع Race Condition؟ ​

من الناحية التقنية:

• Server-side Locking
• Atomic Operations
• Proper Transaction Handling
• Rate Limiting (حل جزئي)

والأهم: متعتمدش على التحقق بس لازم تزامن حقيقي

الخلاصة ​

أي منطق بيعتمد على: “مرة واحدة فقط” هو هدف محتمل لـ Race Condition
مش كل ثغرة بتكسر القواعد… بعضها بس بيسبقك بثانية