OWASP Top 10: أهم الثغرات في تطبيقات الويب

مقدمة

منظمة OWASP (Open Worldwide Application Security Project) هي منظمة غير ربحية عالمية تهدف إلى تحسين أمان البرمجيات، وتوفر مشاريع وأدوات مجانية للمطورين وخبراء الأمن. تأسست سنة 2001 ولها مجتمع نشط في جميع أنحاء العالم. من أبرز مشاريعها قائمة OWASP Top 10، وهي تقرير دوري يحدد أهم وأخطر الثغرات الأمنية في تطبيقات الويب، ويُستخدم كمرجع تدريبي ومعياري من طرف الشركات والجامعات وخبراء الأمن.

إذا كنت مطوّر ويب أو هاوي أمن معلومات، أكيد سمعت على مصطلح OWASP Top 10. هذي القائمة ماشي أي كلام، بل هي معيار عالمي يحدّد أخطر وأشهر الثغرات الأمنية في تطبيقات الويب. تصدر هاد الترتيب كل بضع سنوات بعد تحليل آلاف التطبيقات، باش تعاون المطوّرين وأصحاب المشاريع يفهموا وين كاين الخطر وكيفاش يتفادوه.

في نسخة 2021، القائمة تغطي كل شيء من مشاكل Broken Access Control حتى Server-Side Request Forgery (SSRF). الهدف من هاد المقالة هو نشارك معاكم، بأسلوب بسيط، كل ثغرة واش معناها، نعطي أمثلة من الواقع، ونحكي على طرق عملية باش تقلّل المخاطر. ماشي باش نعلّم، وإنما باش نتقاسم اللي عرفت ونفتح المجال للنقاش والتجربة.

كيف يتم ترتيب الثغرات في OWASP؟

ترتيب الثغرات في مشروع OWASP لا يتم بشكل عشوائي، بل يعتمد على عدة معايير أساسية يتم تقييمها من خلال تحليل بيانات حقيقية من آلاف التطبيقات وتقارير اختبارات الاختراق. أهم هذه المعايير هي:

1. مدى انتشار الثغرة (Prevalence)
   يقيس مدى شيوع وجود الثغرة في تطبيقات الويب، ويتم جمع البيانات باستخدام أدوات فحص تلقائي وتقارير Pentesting من مختلف المصادر.
2. شدة الثغرة (Severity)
   يحدد مقدار الضرر الذي يمكن أن تسببه الثغرة، بناءً على تأثيرها على سرية البيانات، سلامتها، وتوافرها (Confidentiality, Integrity, Availability).
3. سهولة الاستغلال (Exploitability)
   يدرس مدى سهولة استغلال الثغرة، من حيث الوقت والمهارات والأدوات التي يحتاجها المهاجم.
4. تأثيرها على الأعمال (Business Impact)
   يقدر حجم الأثر المحتمل على الشركة، سواء كان ماليًا، قانونيًا، أو على السمعة، في حال تم استغلال الثغرة.

A01 – تخطي صلاحيات الوصول Broken Access Control

هذي الثغرة ببساطة تصير كي يكون النظام ما يراقبش ولا ما يفرضش القيود على صلاحيات المستخدمين بالشكل الصحيح. النتيجة؟ واحد يقدر يوصل لحاجة ماشي من حقه.

مثال بسيط:
تخيل موقع فيه صفحات ملفات المستخدمين بالشكل:

/profile?id=100

إذا المستخدم غيّر id=100 لـ id=101 ولقى نفسه يشوف ملف شخص آخر، هذا معناه عندك Insecure Direct Object Reference (IDOR)، وهو واحد من أشكال Broken Access Control.

⚠ عواقبها:

• سرقة بيانات شخصية أو حساسة.
• تعديل أو حذف بيانات الغير.
• الوصول لمناطق إدارية أو سرية في التطبيق.

🛡 كيفاش نقلّل الخطر:

• فرض التحقق من الصلاحيات على مستوى الخادم (Server-side).
• ما تعتمدش على تغييرات الواجهة (Front-end) فقط.
• مراجعة وتحديث نظام إدارة الأذونات بانتظام.
• استخدام آليات Session Management قوية وربط كل طلب بالمستخدم المصرّح له.

🧩 أمثلة عملية وكتابات CTF عن هذه الثغرة:

A02 –فشل آلية التشفير Cryptographic Failures

زمان كانو يسمّوها Sensitive Data Exposure، واليوم اسمها تغيّر باش يركّز أكثر على السبب: مشاكل التشفير. الفكرة هي أنّ أي معلومة حساسة (كلمات مرور، بطاقات بنكية، بيانات شخصية…) لازم تكون محمية بتشفير قوي أثناء النقل والتخزين.

مثال بسيط:

• موقع يسجّل كلمات المرور بنص صريح (Plaintext) في قاعدة البيانات.
• تطبيق يرسل بيانات تسجيل الدخول عبر HTTP عادي بلا HTTPS.

⚠ عواقبها:

• تسريب كلمات مرور أو معلومات بنكية.
• تسهيل عمليات انتحال الهوية.
• تعريض بيانات الزبائن أو المستخدمين للبيع في السوق السوداء.

🛡 كيفاش نقلّل الخطر:

• دايمًا استعمل بروتوكول HTTPS مع شهادات موثوقة.
• خزّن كلمات المرور باستخدام خوارزميات تجزئة قوية مثل bcrypt أو Argon2.
• شفر البيانات الحساسة وهي مخزّنة أو وهي تنتقل.
• راقب أي مكوّنات أو مكتبات تشفير قديمة وحدثها باستمرار.

🧩 أمثلة عملية وكتابات CTF عن هذه الثغرة:

A03 – الحقن  Injection

ثغرات الحقن تصير كي يكون التطبيق يستعمل بيانات جايّة من المستخدم بطريقة مباشرة في أوامر أو استعلامات، بلا ما يتحقق منها أو يفلترها. المهاجم هنا يقدر يحقن أوامر خبيثة تغيّر سلوك التطبيق أو قاعدة البيانات.

أمثلة شائعة:

• SQL Injection: إدخال كود SQL في خانة البحث أو تسجيل الدخول باش يرجّع كل البيانات.
• XSS (Cross-Site Scripting): إدخال جافاسكريبت خبيث في التعليقات أو النماذج باش ينفذ في متصفحات الناس.
• Command Injection: حقن أوامر نظام التشغيل عبر واجهة ويب.

⚠ عواقبها:

• سرقة أو تعديل البيانات.
• السيطرة على الحسابات أو حتى الخادم.
• نشر برمجيات خبيثة للمستخدمين.

🛡 كيفاش نقلّل الخطر:

• استعمل استعلامات مُعَدّة مسبقًا (Prepared Statements) بدل الدمج المباشر.
• فلتر وتعقيم كل المدخلات، حتى لو كانت من مصادر “موثوقة”.
• استخدم جدران حماية تطبيقات الويب (WAF) إذا كان ممكن.
• عطّل أي أوامر أو دوال خطيرة ما تحتاجهاش.

🧩 أمثلة عملية وكتابات CTF عن هذه الثغرة:

A04 – التصميم الغير آمن Insecure Design

هنا المشكلة ماشي في الكود نفسه، بل في الفكرة والتصميم من الأساس. يعني حتى لو كان الكود مكتوب بطريقة صحيحة، التطبيق يبقى فيه ثغرات لأنه ما تمش التفكير في الأمان أثناء التخطيط.

مثال واقعي:

• تطبيق بنكي يسمح بمحاولة إدخال كلمة المرور عدد غير محدود من المرات، لأنه في التصميم ما تحطّاش خاصية “إقفال الحساب بعد محاولات فاشلة”.
• منصة بيع ما حسبتش حساب حماية ملفات PDF للزبائن، فصار أي واحد يقدر يشارك الرابط ويتفرج بدون شراء.

⚠ عواقبها:

• تسهيل تنفيذ هجمات brute-force أو credential stuffing.
• تسريب محتوى أو بيانات حساسة بلا ما يكون فيه كود “خاطئ” بالضرورة.

🛡 كيفاش نقلّل الخطر:

• إدماج Threat Modeling في المراحل الأولى من تطوير المشروع.
• مراجعة التصميم مع فريق أمني قبل بدء البرمجة.
• اتباع مبادئ Secure by Design: أقل صلاحيات ممكنة، تحديد معدّل الطلبات، حماية تدفق البيانات…

🧩 أمثلة عملية وكتابات CTF عن هذه الثغرة:

A05 – الإعدادات الأمنية الخاطئة – Security Misconfiguration

هذي من أكثر الثغرات شيوعًا، وتجي غالبًا من إعدادات خاطئة أو ترك الإعدادات الافتراضية كما هي. حتى لو الكود نظيف، التهيئة الغلط تفتح الباب للهجمات.

أمثلة شائعة:

• ترك لوحة الإدارة مكشوفة بدون كلمة مرور قوية أو حتى بدون حماية.
• عدم حذف ملفات أو صفحات الاختبار من بيئة الإنتاج.
• إعدادات HTTP headers ناقصة أو خاطئة.
• تمكين مكونات أو خدمات ما تحتاجهاش في الخادم.

⚠ عواقبها:

• كشف معلومات حساسة عن التطبيق أو الخادم.
• تسهيل استغلال ثغرات أخرى.
• منح المهاجم صلاحيات ما كانش لازم يتحصل عليها.

🛡 كيفاش نقلّل الخطر:

• عزل بيئات التطوير، الاختبار، والإنتاج.
• حذف أي موارد أو صفحات غير مستخدمة.
• مراجعة الإعدادات الأمنية بشكل دوري.
• استعمال أدوات فحص الأمان الآلي لاكتشاف التهيئات الضعيفة.

🧩 أمثلة عملية وكتابات CTF عن هذه الثغرة:

A06 –الثغرات و المكونات الغير المحدثة – Vulnerable and Outdated Components

هذي الثغرة تصير كي التطبيق يعتمد على مكتبات، إضافات، أو مكونات قديمة فيها مشاكل أمنية معروفة، وما تمّش تحديثها. المهاجمين يعرفو الثغرات ويستغلوها بسهولة، لأن التفاصيل غالبًا تكون علنية.

مثال بسيط:

• موقع يستعمل نسخة قديمة من jQuery فيها ثغرة XSS معروفة.
• تطبيق يعتمد على مكتبة PHP أو Python ما تمش ترقيتها من سنوات وفيها Remote Code Execution.

⚠ عواقبها:

• اختراق الخادم أو التطبيق.
• الوصول لبيانات حساسة.
• تسهيل هجمات متسلسلة باستغلال مكون واحد فقط.

🛡 كيفاش نقلّل الخطر:

• احتفظ بجرد كامل لكل المكونات والإصدارات اللي تستعملها (Software Bill of Materials).
• فعل تنبيهات التحديثات الأمنية.
• حدث المكونات بانتظام، خاصة المكتبات مفتوحة المصدر.
• استعمل أدوات فحص الثغرات في Dependencies مثل npm audit أو pip-audit.

🧩 أمثلة عملية وكتابات CTF عن هذه الثغرة:

A07 – الهوية و فشل عملية التحقق – Identification and Authentication Failures

هذي الثغرات مرتبطة بكيفية تعريف المستخدمين والتحقق من هويتهم. إذا كانت الطريقة ضعيفة أو فيها أخطاء، المهاجم يقدر ينتحل شخصية مستخدم آخر أو يتجاوز تسجيل الدخول.

أمثلة شائعة:

• كلمات مرور ضعيفة أو بدون سياسة إلزامية للتعقيد.
• غياب التحقق المتعدد العوامل (MFA).
• جلسات (Sessions) ما تنتهيش بعد وقت معيّن أو ما تلغيش بعد تسجيل الخروج.
• إرسال رموز التحقق أو إعادة التعيين عبر قنوات غير آمنة.

⚠ عواقبها:

• سرقة حسابات المستخدمين.
• دخول غير مصرح به لمناطق حساسة.
• تنفيذ عمليات باسم الضحية.

🛡 كيفاش نقلّل الخطر:

• فرض سياسة كلمات مرور قوية وتغييرها بشكل دوري عند الحاجة.
• تفعيل التحقق المتعدد العوامل (MFA) لكل الحسابات الحساسة.
• تحديد صلاحية الجلسات، ومسحها بعد الخروج.
• استخدام قنوات آمنة (مثل HTTPS) لكل عمليات المصادقة.

🧩 أمثلة عملية وكتابات CTF عن هذه الثغرة:

A08 –  فشل سلامة البيانات والبرمجيات – Software and Data Integrity Failures

هذي الثغرات تصير كي التطبيق ما يتحققش من سلامة البرمجيات أو البيانات اللي يستعملها. يعني ممكن حد يحقن كود أو يعدّل ملفات أثناء عملية التحديث أو النشر، والتطبيق يشتغل عادي كأن ما صرالو والو.

أمثلة شائعة:

• تحميل مكتبة أو سكريبت من مصدر خارجي بدون التحقق من توقيعه أو سلامته.
• تحديثات برمجية تجي من سيرفر غير مؤمّن.
• ضعف في حماية CI/CD pipeline، يخلي أي واحد يعدّل الكود قبل النشر.

⚠ عواقبها:

• إدخال برمجيات خبيثة داخل التطبيق.
• التلاعب بالبيانات أو نتائج العمليات.
• اختراق أنظمة الإنتاج عبر سلسلة التوريد (Supply Chain Attack).

🛡 كيفاش نقلّل الخطر:

• التحقق من سلامة الملفات باستخدام التواقيع الرقمية أو checksums.
• تأمين قنوات نقل التحديثات.
• حماية بيئة CI/CD بصلاحيات صارمة ومصادقة قوية.
• اعتماد مبدأ “Zero Trust” حتى مع مكونات داخلية.

🧩 أمثلة عملية وكتابات CTF عن هذه الثغرة:

A09 – فشل في تسجيل السجلات الأمنية والمراقبة – Security Logging and Monitoring Failures

هذي الثغرة تصير كي التطبيق ما يسجّلش الأحداث الأمنية بشكل كافي، أو يسجّلها لكن ما يراقبهاش. النتيجة: الهجمات ممكن تستمر لفترة طويلة بلا ما يتم اكتشافها.

📌 أمثلة شائعة:

• ما كاينش تسجيل لمحاولات تسجيل الدخول الفاشلة.
• تسجيل الأحداث موجود، لكن ما فيش نظام تنبيه أو مراقبة حية.
• حذف السجلات (Logs) بسرعة أو تركها مكشوفة بدون حماية.

⚠ عواقبها:

• الهجمات تمرّ بدون ملاحظة لأسابيع أو أشهر.
• صعوبة التحقيق بعد الاختراق.
• فقدان أدلة مهمة لتحديد مصدر المشكلة.

🛡 كيفاش نقلّل الخطر:

• تفعيل تسجيل شامل للأحداث المهمة (عمليات الدخول، التغييرات، الأخطاء).
• وضع نظام مراقبة وتنبيه لحظي (مثل SIEM).
• الاحتفاظ بالسجلات لفترة كافية وبطريقة آمنة.
• مراجعة السجلات بشكل دوري حتى لو ما كانش فيه إنذار.

🧩 أمثلة عملية وكتابات CTF عن هذه الثغرة:

A10 – تزوير الطلبات من جانب الخادم SSRF – Server-Side Request Forgery (SSRF)

ثغرة SSRF تصير كي التطبيق يسمح للمستخدم يحدد روابط (URLs) أو عناوين يروح لها الخادم مباشرة، بدون ما يتحقق من صحتها أو أمانها. المهاجم يستغل هذا باش يخلي الخادم يطلب موارد داخلية أو خارجية ما كانش لازم يوصل لها.

مثال بسيط:

• تطبيق يطلب صورة من رابط يعطيه المستخدم: https://site.com/fetch?url=http://example.com/image.jpg المهاجم يغيّر الرابط لشيء داخلي: http://localhost/admin وهكذا يقدر يوصل لمناطق داخلية أو حتى يتفاعل مع خدمات محمية.

⚠ عواقبها:

• كشف معلومات داخلية عن الشبكة أو الخادم.
• استغلال خدمات داخلية لتنفيذ أوامر.
• فتح الباب لهجمات متسلسلة عبر الشبكة الداخلية.

🛡 كيفاش نقلّل الخطر:

• تحديد قائمة بيضاء (Allowlist) للروابط المسموح بها.
• منع الوصول لعناوين داخلية (مثل 127.0.0.1 أو 10.x.x.x).
• التحقق من كل الروابط على مستوى الخادم قبل المعالجة.
• استعمال مكتبات HTTP آمنة تدعم الحماية من SSRF.

🧩 أمثلة عملية وكتابات CTF عن هذه الثغرة:

الخاتمة

قائمة OWASP Top 10 ماشي مجرد نظرية، بل هي انعكاس لواقع الهجمات اللي تصير كل يوم على تطبيقات الويب. الهدف منها هو رفع الوعي، باش كل واحد فينا — سواء مطوّر، صاحب مشروع، أو حتى هاوي أمن معلومات — يعرف وين الأخطار الحقيقية ويقدر يواجهها.

أنا شخصيًا نشوف أن التعامل مع هذي القائمة لازم يكون عادة في أي مشروع، مش مرة وحدة وتنسى. كل ما تتطور التقنية، تظهر أساليب جديدة للهجوم، وبالتالي القائمة تتجدد وتتلاءم مع التهديدات الحالية.

رح نحدّث هذا المقال بشكل دوري، ونضيف أمثلة وسيناريوهات واقعية وحتى تحديات CTF فيها استغلالات للـ OWASP Top 10 باش تتعرف عليهم أكثر وتتمرن على كشفهم.

إذا كان أي نقطة من اللي حكينا عليها اليوم ما كانتش واضحة، أو حاب تشوف مثال عملي على وحدة منها، مرحبا بك تراسلني. نحب نتعلم معاكم ونشارك اللي نعرفه، وبلا شك أن النقاشات تضيف أفكار وتجارب جديدة للجميع.

روابط مفيدة:

• OWASP Top 10 (الموقع الرسمي)
• OWASP Top 10 (ويكيبيديا)