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

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

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

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

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

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

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

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

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

---

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

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

💥 المشكلة إن الخطوات دي مش دايمًا 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 ⚠️
مش كل ثغرة بتكسر القواعد… بعضها بس بيسبقك بثانية ⏱️