الوحدة 4: ثغرات OWASP Top 10 (وتطبيقات عملية للحماية)

تعرف على أخطر الثغرات الأمنية في تطبيقات الويب وكيفية حمايتها.

1. الوصف العام

تركّز هذه الوحدة على أهمّ فئات الثغرات التي تصنّفها مبادرة OWASP كأخطر مشكلات تطبيقات الويب (OWASP Top 10). سنتعرف على كل فئة — الجذر التقني للمشكلة، أمثلة واقعية ومبسطة، كيفية اكتشافها باستخدام أدوات وفحصٍ آلي ويدويّ، وكيفية إصلاحها وتضمين الحماية في دورة تطوير البرمجيات. مصدر التعريفات والإرشادات العملية الأساسي: OWASP Top-10 وCheat-Sheets وWSTG.

2. أهداف الوحدة

بعد إتمام الوحدة يتوقع أن يكون المتدرّب قادرًا على:

  • تفسير كل فئة من OWASP Top-10 (2021) وفهم السبب الجذري لكل ضعف.
  • استخدام أدوات لاكتشاف الثغرات (DAST/SAST/IAST) وبيئات مختبرية (Juice Shop, DVWA).
  • كتابة أمثلة تصحيحية (secure-by-design) في الكود لتفادي الثغرات الشائعة.
  • إعداد تقرير فني يشمل طريقة الاكتشاف، دليل الاستغلال (باختبار قانوني في مختبر)، وخطة التخفيف.
  • اقتراح تحسّينات في SDLC (سياسات، اختبارات، مراجعات) لمنع تكرارها.

3. قائمة OWASP Top-10 (مختصرة، مع تفصيل لكل بند)

ملاحظة: OWASP Top-10 (2021) هو مرجعيّة مخصّصة للوعي ولتوجيه المطورين ومدققي الأمان — راجع الصفحة الرسمية للمزيد من التفصيل: OWASP Top 10 Official Page.

A01 — Broken Access Control (كسور التحكم في الوصول)

ما هي؟ فشل في فرض سياسات التفويض (authorization) يسمح لمهاجم بالوصول أو تعديل موارد ليس لديه صلاحية لها. OWASP Link

كيف تحدث؟ أمثلة: اعتراض معرّفات موارد (IDs) وتغييرها (IDOR)، إبقاء واجهات إدارية مكشوفة، عدم التحقق من العلاقة بين المستخدم والموارد.

مثال بسيط (IDOR):


GET /invoices/view?id=123
                        

إذا سمح التطبيق لأي مستخدم بقراءة أي id دون فحص علاقته بالمستخدم، فمهاجم يغير id إلى 124 ويطلع على فواتير مستخدم آخر.

الاكتشاف: اختبار يدوي (تفكير هجومي)، فحص endpoints باستخدام Burp / ZAP، فحص قواعد الوصول في الكود ومراجعات Authorization. PortSwigger | OWASP WSTG

التصحيح / الحماية:

  • لا تعتمد على القيم التي يقدّمها المستخدم لتقرير التفويض — تحقق دائمًا على الخادم (server-side) أن المستخدم مخوّل للمورد.
  • طبّق مبدأ Least Privilege واحتفظ بخريطة صلاحيات مركزية. استخدم Access-Control lists أو نماذج Roles/Claims مع تحقق دائم. راجع دليل Access Control Cheat Sheet: OWASP Cheat Sheet Series.

A02 — Cryptographic Failures (سوء استخدام/فشل التشفير)

ما هي؟ استخدام تشفير ضعيف، عدم تشفير بيانات حساسة، إدارة مفاتيح سيئة، أو استخدام تجزئات/خوارزميات مهترئة. OWASP Link

أمثلة شائعة: تخزين كلمات المرور بنص واضح، استخدام MD5/SHA1 كـ password hashing، تخزين مفاتيح في الكود.

المثال & الحل: استخدم تجزئة آمنة مع salt مثل bcrypt/Argon2 لحفظ كلمات المرور؛ لا تستخدم تشفير قابل للعكس لتخزين كلمات المرور. استخدم خدمات إدارة مفاتيح (KMS) بدلًا من متغيّرات بيئة مكشوفة. راجع Cryptographic Storage Cheat Sheet: OWASP Cheat Sheet Series

أداة التحقق: مراجعة الكود (SAST) للتأكد من خلو المشروع من استخدامات خوارزميات/نماذج ضعيفة.

A03 — Injection (حقن: SQL, OS, LDAP, NoSQL, …)

ما هي؟ إدخال بيانات من المستخدم تُعامل كأوامر/استعلامات مما يسمح للمهاجم بحقن استعلامات أو أوامر ضارة. OWASP Cheat Sheet Series

مثال تعليقي لنمط SQL-i:

مدخل: username = ' OR '1'='1 يؤدي لتجاوز التحقق إذا استُخدمت عبارات سلسلة مباشرة.

Payload بسيط: '; DROP TABLE users; -- (لأغراض تعليمية داخل بيئة مختبرية فقط).

الاكتشاف: أدوات مثل sqlmap وDAST (Burp / ZAP) تكشف نقاط الإدخال الضعيفة. sqlmap.org | PortSwigger

الحماية:

  • استخدم استعلامات مُهيأة (prepared statements) أو ORM التي تُعالِج المعاملات بأمان.
  • تحقق من صحة المدخلات (whitelisting) بدلًا من محاولات تنظيف (blacklisting). راجع SQL Injection Prevention Cheat Sheet: OWASP Cheat Sheet Series

مثال كود (Python + SQLite — parameterized):


# خطأ: تجميع سلسلة
# cursor.execute(f"SELECT * FROM users WHERE username='{u}' AND pass='{p}'")

# صحيح: parameterized
cursor.execute("SELECT * FROM users WHERE username=? AND pass=?", (u, p))
                        

A04 — Insecure Design (تصميم غير آمن)

ما هي؟ ضعف في مستوى التصميم المعماري والتخطيط الأمني (absence of secure design patterns, threat-modeling). OWASP Link

الأسباب: غياب نمذجة التهديد (Threat Modeling)، متطلبات أمنية غير واضحة، اعتماد كبير على مكونات خارجية دون تقييم.

المعالجة: إدراج Threat Modeling في المراحل المبكرة، تبنّي أنماط Secure Design (defense-in-depth، least-privilege) وASVS/architecture reviews. راجع WSTG وممارسات التصميم الآمن: OWASP WSTG - Design.

A05 — Security Misconfiguration (تهيئة/إعداد خاطئ)

ما هي؟ إعدادات غير مُحكَمَة عبر الخادم/التطبيق/قاعدة البيانات/السحابة (المخلفات الافتراضية، أخطاء في الCORS، رؤوس الأمان مفقودة). OWASP Link

أمثلة: صفحات الخطأ التي تُظهر Stack Traces، لوحات إدارة مكشوفة، إعدادات TLS غير صحيحة، سياسات CORS ممتدة.

الحماية: تشديد الإعدادات (Harden images, remove default accounts), ضبط رؤوس الأمان (HSTS, X-Content-Type-Options, X-Frame-Options, CSP)، واختبارات المزامنة مع CI/CD. راجع HTTP Headers Cheat Sheet: OWASP Cheat Sheet Series.

A06 — Vulnerable and Outdated Components

ما هي؟ استخدام مكتبات أو خدمات قديمة بها ثغرات (مثل مكتبة JS قديمة أو صورة حاوية غير محدثة). OWASP Link

مخاطر: مهاجمون يستغلون ثغرات في المكتبات للوصول أو تنفيذ تعليمات عن بُعد.

الإجراءات: سياسة تحديث دوري، استخدام SCA (Software Composition Analysis) مثل OWASP Dependency-Check أو أدوات سحابية لفحص الـ dependencies.

A07 — Identification & Authentication Failures (فشل التعرّف والمصادقة)

ما هي؟ ضعف في آليات تسجيل الدخول، إدارة الجلسات (sessions) أو تنفيذ سيء للمصادقة (مثل كلمات مرور ضعيفة، عدم وجود حماية ضد credential stuffing). OWASP Link

الحماية: تطبيق مصادقة متعددة العوامل (MFA)، حماية ضد credential-stuffing (rate-limiting, IP-reputation)، استخدام جلسات آمنة (Secure, HttpOnly, SameSite cookies) ومراجعة سياسات "reset password". راجع Authentication Cheat Sheet وCredential Stuffing Prevention: OWASP Authentication Cheat Sheet | OWASP Credential Stuffing Prevention.

A08 — Software and Data Integrity Failures

ما هي؟ فشل ضمان سلامة البرامج/المكونات أثناء التحديث أو تحميل المكونات من مصادر لا تُظهر سلامتها (مثال: تحميل حزم npm بدون تحقق من التوقيع). OWASP Link

التعويض: التحقق من التواقيع الرقمية، استخدام SLSA, التحقق من checksums والتوقيع عند تحديث الحزم، استخدام سياسة عدم السماح لتنفيذ ملفات غير موثوقة.

A09 — Security Logging & Monitoring Failures

ما هي؟ غياب سجلات كافية أو مراقبة تؤدي لتأخر اكتشاف الحوادث أو عدم وجود بيانات لعبور التحقيق (forensics). OWASP Link

ما يجب تطبيقه: سجلات مركزية (SIEM)، رصد محاولات الاستغلال والـAlerts، retention مناسب للسجلات، واختبارات كشف التسلل. راجع WSTG للاختبارات المنهجية: OWASP WSTG - Logging and Monitoring.

A10 — Server-Side Request Forgery (SSRF)

ما هي؟ التطبيق يقوم بطلبات HTTP مُنشأة بواسطة مدخلات المستخدم إلى موارد داخلية/خارجية دون تحقق، ما يتيح الوصول إلى شبكات داخلية أو خدمات حساسة. OWASP Link

مثال: واجهة تحميل عنوان URL تعرض محتوى خارجي، مهاجم يقدم http://169.254.169.254/latest/meta-data/ للوصول إلى بيانات instance metadata في بيئات السحابة.

الحماية: تقييد الوجهات المسموح بها (allowlist), التحقق من URLs، منع الشبكات الداخلية في الطلبات الصادرة، واستخدام WAF/Proxy لحماية هذا النوع من الطلبات.

4. أدوات الاكتشاف والاختبار المقترحة (عمليًّا)

  • Burp Suite (Community / Pro): اعتراض/تغيير الطلبات، فحص أوتوماتيكي وتدقيق يدوي. PortSwigger
  • OWASP ZAP: بديل مفتوح المصدر للفحص الديناميكي. OWASP ZAP
  • sqlmap: لأتمتة كشف واستغلال SQL-i (في بيئة مختبرية مرخّصة فقط). sqlmap.org
  • SAST & SCA: SonarQube, Dependency-Check، Checkmarx (لمراجعة الكود والمكونات).
  • بيئات مختبرية آمنة: OWASP Juice Shop, DVWA, WebGoat — لتمارين محاكاة الاستغلال ثم الإصلاح.

5. أمثلة كود وتصحيحات نموذجية (مختصرة)

5.1 منع SQL Injection (PHP PDO — مثال صالح)


// ضع مدخلات المستخدم في prepared statement
$stmt = $pdo->prepare('SELECT * FROM users WHERE email = :email');
$stmt->execute(['email' => $user_input_email]);
$user = $stmt->fetch();
                    

5.2 منع XSS (إخراج HTML مُرمّز — PHP)


// عند عرض قيمة في HTML
echo htmlspecialchars($user_input, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
                    

(بالإضافة إلى استخدام Content Security Policy على مستوى الرأسّات للحد من تحميل السكربتات غير الموثوقة). راجع XSS Prevention Cheat Sheet: OWASP XSS Prevention Cheat Sheet.

5.3 التحقق من التفويض (مثال خادمي - Python)


# تحقق أن 'resource.owner_id' == current_user.id قبل الارجاع/التعديل
if resource.owner_id != current_user.id:
    abort(403) # Forbidden
                    

6. تمارين ومشاريع مختبرية مقترحة

  • تمرين 1 — تقييم OWASP Juice Shop: نفّذ دورة كاملة لاكتشاف 10 تحديات متعلّقة بالـTop10، وثّق خطوات الاكتشاف وكيفيّة التصحيح. (Juice Shop يُغطّي معظم الثغرات).
  • تمرين 2 — DVWA / WebGoat: افحص صفحة تحتوي SQL-i وXSS على مستويات صعوبة مختلفة، ثم صحّح الكود. DVWA GitHub | WebGoat
  • تمرين 3 — تقرير إصلاح (Remediation Report): اختر ثلاث ثغرات واقعية، حرّر تقريرًا يصف: الاكتشاف، درجة الخطورة (مثلاً CVSS)، خطوات الإصلاح، تقدير الجهد.

7. موارد ومراجع مفيدة (مباشرة)

📚 مقالات ودلائل
🛠 أدوات عملية

8. مقترح تقييم ومخرجات الوحدة (خريطة التقييم)

  • مهمة عملية (60%): تنفيذ تمرين على Juice Shop أو DVWA، تقرير تقني (اكتشاف + PoC مختصر داخل مختبر قانوني + remediation).
  • واجب نظري (25%): سؤال/إجابة عن كل 10 فئات (تعريف + طرق الحماية).
  • مشاركة صفية وشفهي (10%): مناقشة حالة واقعية ودروس مستفادة.
  • سلوك الأمان الأخلاقي (5%): الالتزام بسياسة الأخلاقيات عند إجراء اختبارات على بيئات غير مرخصة.

9. ملاحظات أمنية وأخلاقية (هامة — اقرأها قبل أي تمرين)

  • جميع تقنيات الاكتشاف والاستغلال التي تُمارَس في المقرر يجب أن تُطبق فقط داخل بيئات مرخّصة ومحمية (مختبراتك المحلية، Juice Shop، DVWA، أو بيئات خاصة مُعدّة للتجربة). لا تستخدمها ضد مواقع أو أنظمة في العالم الحقيقي دون تفويض كتابي وصريح.
  • توثّق دائمًا النتائج واطّلع على سياسات المؤسسة قبل أي اختبار.

خاتمة الوحدة

الوحدة الرابعة هي قلب الجانب العملي في أمن التطبيقات: فهم هذه الفئات (OWASP Top-10) وتمارين التطبيقية عليها تمنح المتدرب قدرة فعلية على اكتشاف المخاطر وإصلاحها ورفع مستوى الأمان داخل دورة حياة تطوير البرمجيات. ابدأ بالمفاهيم ثم انتقل للتمارين العملية في Juice Shop/DVWA مع أدوات مثل Burp وZAP، ودوّن دائمًا خطواتك وطرق إصلاحك لكتابة تقرير احترافي.