من أين تُخترق تطبيقات الويب؟ مراجعة أنماط برمجية شائعة
اختراق تطبيقات الويب نادرًا ما يكون نتيجة ثغرة “ذكية” أو معقّدة. في أغلب الحالات، يبدأ من نمط برمجي شائع، أو افتراض غير مُعلن، أو قرار هندسي يبدو صحيحًا أثناء التطوير لكنه يفتح بابًا غير مقصود لاحقًا.
هذا المقال موجه لمطوري Backend ذوي الخبرة، ويهدف إلى تفكيك أماكن ظهور الثغرات داخل الكود نفسه: كيف تولد، لماذا تتكرر، ولماذا لا يمنعها استخدام Framework أو ORM.
التركيز هنا ليس على تصنيف نظري، بل على أنماط واقعية تظهر في كود الإنتاج، حتى في أنظمة ناضجة ومشاريع كبيرة.
1) SQL Injection — الثغرة التي تظهر خارج CRUD
Root Cause
غالبًا لا تظهر SQL Injection في CRUD البسيط، بل في الأجزاء الديناميكية مثل:
- ORDER BY
- IN clauses
- Search builders
نمط كود شائع
$query .= " ORDER BY " . $request->sort;
سبب الخطورة
القيمة ليست data فقط، بل جزء من بنية الاستعلام. Prepared Statements لا تحمي هنا.
الإغلاق الصحيح
- عدم قبول أسماء أعمدة من المستخدم
- Whitelist صارم للقيم الممكنة
2) Stored XSS — الثقة بالمحتوى الداخلي
Root Cause
الافتراض الخاطئ أن المحتوى القادم من لوحة الإدارة آمن.
نمط كود شائع
{!! $article->content !!}
سبب الخطورة
أي خطأ إداري أو حساب مخترق يتحول إلى تنفيذ JavaScript لكل زائر.
الإغلاق الصحيح
- Escape عند العرض لا التخزين
- HTML sanitization إن لزم
- Content Security Policy
3) Reflected XSS عبر رسائل الخطأ
Root Cause
إرجاع مدخل المستخدم داخل رسالة خطأ.
نمط كود شائع
return "Invalid value: $input";
الإغلاق الصحيح
- رسائل خطأ ثابتة
- عدم عكس مدخلات المستخدم
4) CSRF في التطبيقات الهجينة
Root Cause
JWT مخزن في Cookie مع SameSite غير مضبوط، وEndpoints تغيّر الحالة.
سبب الخطورة
المتصفح يرفق الكوكي تلقائيًا مع أي طلب خارجي.
الإغلاق الصحيح
- CSRF Tokens
- SameSite=Lax أو Strict
- منع تغيير الحالة عبر GET
5) Broken Access Control (IDOR)
Root Cause
التحقق من وجود السجل بدل التحقق من ملكيته.
نمط كود شائع
$invoice = Invoice::find($id); return $invoice;
الإغلاق الصحيح
- Ownership checks
- Policies / Guards
6) Mass Assignment
Root Cause
تمرير كل مدخلات المستخدم مباشرة إلى النموذج.
نمط كود شائع
User::create($request->all());
سبب الخطورة
المستخدم قد يمرر حقولًا لم تُعرض في الواجهة.
الإغلاق الصحيح
- Explicit fields
- DTOs
7) Business Logic Abuse
Root Cause
المنطق يعمل كما كُتب، لكنه يسمح بإساءة الاستخدام.
أمثلة شائعة
- كوبونات بلا حد استخدام
- تسلسل عمليات غير محمي
الإغلاق الصحيح
- State machines
- Idempotency
8) Overexposed API Responses
Root Cause
إرجاع Models كاملة مباشرة.
سبب الخطورة
حتى لو لم تُستخدم في الواجهة، فهي مكشوفة.
الإغلاق الصحيح
- DTOs
- Explicit serialization
9) File Upload Execution
Root Cause
تخزين الملفات داخل public path.
سبب الخطورة
سلسلة: رفع → وصول → تنفيذ.
الإغلاق الصحيح
- Storage خارج public
- Serve عبر Controller
- تعطيل التنفيذ
10) Path Traversal
Root Cause
استخدام مدخل المستخدم لبناء مسار ملفات.
نمط كود شائع
file_get_contents('/files/' . $name);
الإغلاق الصحيح
- Normalize paths
- Whitelist أسماء الملفات
11) Command Injection
Root Cause
تمرير مدخلات المستخدم لأوامر النظام.
الإغلاق الصحيح
- عدم استخدام exec مع مدخلات
- APIs آمنة
12) Insecure Deserialization
Root Cause
Deserialize بيانات غير موثوقة.
الإغلاق الصحيح
- عدم deserialize مدخلات المستخدم
- استخدام JSON فقط
13) Authentication Bypass
Root Cause
الاعتماد الكامل على Middleware دون تحقق داخل المنطق.
الإغلاق الصحيح
- Authorization داخل Use Case
14) Session Fixation
Root Cause
عدم تجديد Session ID بعد تسجيل الدخول.
الإغلاق الصحيح
- Regenerate session
15) Rate Limiting Absence
Root Cause
عدم تحديد حدود للعمليات الحساسة.
الإغلاق الصحيح
- Throttling
- Per-user limits
16) Password Handling Errors
Root Cause
تخزين أو مقارنة كلمات المرور بشكل غير آمن.
الإغلاق الصحيح
- Strong hashing
- Timing-safe comparison
17) Secrets in Code or Logs
Root Cause
تسريب أسرار عبر الكود أو السجلات.
الإغلاق الصحيح
- Environment isolation
- Masking في logs
18) Dependency Vulnerabilities
Root Cause
استخدام مكتبات قديمة بدون متابعة.
الإغلاق الصحيح
- Security advisories
- Automated audits
19) Misconfigured CORS
Root Cause
CORS مفتوح أكثر من اللازم.
الإغلاق الصحيح
- Origins صريحة
- عدم استخدام wildcard مع credentials
20) Error Handling Information Leak
Root Cause
عرض تفاصيل الأخطاء في الإنتاج.
الإغلاق الصحيح
- رسائل عامة للمستخدم
- تفاصيل في logs فقط
خلاصة
تطبيقات الويب لا تُخترق غالبًا بسبب نقص معرفة، بل بسبب افتراضات غير مكتوبة:
- أن المستخدم لن يجرب
- أن الإدمن لا يخطئ
- أن الـ framework سيغطي كل شيء
الأمان ليس إضافة لاحقة، بل نتيجة قرارات هندسية منذ أول سطر كود.