OWASP Top 10 - أشهر ثغرات الويب وطرق الحماية

يعني إيه OWASP وليه نهتم بيها؟ ​

OWASP دي اختصار لـ Open Web Application Security Project - مجتمع بدأ من 2001 هدفه يبسط أمان التطبيقات ويبقى مرجع للمطورين والمهندسين والمسؤولين.
أحسن حاجة في OWASP إنهم بينزّلوا تقرير كل فترة اسمُه OWASP Top 10 - فيه أشهر 10 ثغرات بتهاجم الـ Web Applications، والتقرير ده دليل عملي لأي حد شغّال في الويب.

كل إصدار من الـ Top 10 ممكن يتغير: في حاجات تطلع، حاجات تدخل جديدة، وحاجات تتقدم في الترتيب حسب خطورتها وانتشارها.

ليه البوست ده مهم ليك؟ ​

لو إنت مطور، أو مهندس سيكيوريتي، أو حتى مدير مشروع، فهم الـ OWASP Top 10 يخليك تعرف إيه الأكتر خطورة وتبدأ تحمي بيه التطبيق صح بدل ما تشتغل على صداع مالوش لازمة.
الكلمات المفتاحية اللي لازم نبقى واخدين بالنا منها: OWASP، ثغرات الويب، Injection، XSS، CSRF، APIs، Security Misconfiguration.

Injection - رقم 1 (الحقن) ​

معروف إن Injection مش بس SQL - ده كل نوع من الحقن: SQL, XML, HTML, OS commands, DLL injection... الفكرة إن المهاجم يدخل كود خبيث في مكان التطبيق متوقع فيه data، فالكود يتنفّذ ويعمل retrieve أو execute لحاجة مش مفروض تتنفذ.

أمثلة بسيطة:​

• تحط في input بتاع login: ' OR '1'='1 ويدخلك على طول لو مش معمول prepared statements.
• تحميل ملف بيحتوي DLL أو script يتنفّذ على السيرفر لو الـ upload مش مقيّد.

إزاي نمنعها:​

• استخدم Prepared Statements / Parameterized Queries بدل الـ string concatenation.
• Validate & sanitize المدخلات (Whitelist أحسن من blacklist).
• أخفّض صلاحيات الـ DB والـ OS (least privilege).

Broken Authentication & Session Management - رقم 2 ​

المشاكل هنا في عملية الـ Authentication وإدارة الجلسات (sessions). لو التنفيذ غلط، المهاجم يقدر يتنكر كـ user تاني أو يسرق الـ session ويخش بحساب حد.

أمثلة:​

• Session Fixation: بعد login الـ session id ما بيتجددش.
• Password reset tokens سهلة التخمين أو بتعمر كتير.
• كلمات سر متخزنة clear text.

الحلول:​

• جدّد session id بعد الـ login. استخدم cookies بـ HttpOnly, Secure, وSameSite.
• policies قوية لكلمات السر + rate-limiting على محاولات الدخول.
• خزن الباسوردات hashed (bcrypt/argon2).

​

Cross-Site Scripting (XSS) - رقم 3 ​

XSS بتخلّي المهاجم يشغّل جافاسكربت في متصفح الضحية. خطرها كبير: تقدر تسرق session cookies، تعمل redirect لصفحات تصيّد، تسرّب بيانات المستخدم.

أنواعها:​

• Reflected (non-persistent) - من لينك خبيث.
• Stored (persistent) - السكربت بتتحفظ في DB وتؤثر على كل اللي يزوروا الصفحة.
• DOM-based - كله client-side ومش باين على السيرفر.

منع XSS:​

• Escape output حسب السياق (HTML/Attribute/JS).
• ضبط Content Security Policy (CSP).
• Validate المدخلات على ال server والـ client.

Broken Access Control - رقم 4 ​

هنا المشكلة إن authorization معمول غلط، وده يخلي أي حد يوصل لصفحات أو ملفات مش ليه. يعني أي check كان محتاج يتعمل على السيرفر مش موجود أو سهل تجاوزُه.

حل بسيط:​

• كل resource يتفحّص على السيرفر مش على الـ client.
• استخدم role-based access وفضّل مبدأ least privilege.

Security Misconfiguration - رقم 5 ​

من أكتر المشاكل اللي بتبان في المشاريع: إعدادات سيرفر غلط، رسائل خطأ بتكشف معلومات، default credentials، أو مكونات مش محدثة.

أمثلة:​

• صفحة error بتكشف نسخة الـ DB أو اسم جدول.
• ملفات config فيها مفاتيح أو كلمات سر.

إزاي نتعامل:​

• عمل hardening للسيرفرات (CIS benchmarks).
• خفف معلومات الخطأ اللي بتطلع للمستخدم.
• امنع الوصول للـ admin endpoints بدون حماية.

Sensitive Data Exposure - رقم 6 ​

دي لما الداتا الحساسة (كروت ائتمان، كلمات سر، سجلات طبية...) بتتنقل أو تتخزن من غير تشفير مناسب.

أمثلة:​

• نقل البيانات على HTTP بدل HTTPS.
• تخزين passwords كـ clear text.
• backups من غير تشفير.

الصح:​

• استخدم TLS/HTTPS في كل الحتت (بما فيها الـ APIs).
• خزن الباسورد hashed مع salt.
• شفّر الداتا at rest و in transit.

Insufficient Attack Protection - رقم 7 ​

حاجة جديدة في الــTop 10: معناها إن الـ Owners ما عندهمش آليات سريعة لإصلاح الثغرات أو منع الهجمات وقت ظهورها. يعني المشكلة معروفة، بس مفيش طريقة عملية لعمل patch من غير ما يكسروا حاجة تانية، أو مش عايزين يطفوا الـ app عشان خسارة مالية.

الإجراءات:​

• contingency plans: feature flags، staged deployments، rollback plans.
• تحضير monitoring & alerting كويس.
• اختبارات دورية لعمليات الـ patching.

Cross-Site Request Forgery (CSRF) - رقم 8 ​

الـ CSRF بيخلي الضحية يعمل request غير مقصود لموقع هو أصلاً متسجّل فيه - عن طريق link أو صفحة خبيثة - فيتنفّذ على إنه المستخدم.

الوقاية:​

• ضع anti-CSRF tokens في الفورمات.
• استخدم SameSite cookies أو تحقق من Origin/Referer.
• لعمليات حساسة، اطلب re-auth أو 2FA.

Using Components with Known Vulnerabilities - رقم 9 ​

لو بتستخدم مكتبات أو frameworks قديمة فيها ثغرات، التطبيق بتاعك معرض لأن المهاجم يستغل الثغرات دي حتى لو الكود بتاعك آمن.

الحل:​

• اعمل dependency scanning (Snyk, OWASP Dependency-Check).
• حدّث المكتبات دورياً.
• قلل الصلاحيات اللي بتمنحها للمكتبات.

Unprotected APIs - رقم 10 ​

جديد برضه - معظم التطبيقات الحديثة بتعتمد APIs (REST, SOAP, RPC, GraphQL...). لو الـ APIs مش مأمّنة صح، بتبقى بوابة سهلة للهجوم.

نقاط مهمة:​

• احمِ كل API بـ auth & authorization و rate-limiting.
• استخدم API Gateway وOAuth2 بشكل صحيح.
• اعمل validation للـ inputs وفتح logging مناسب.

الخلاصة: ازاي تشتغل عمليًا مع الـ Top 10 ده؟ ​

1. اعمل inventory لكل الموارد اللي عندك (APIs, libraries, servers).
2. شغّل Static + Dynamic + Dependency scans بانتظام.
3. أصلح الأولويات: Injection، Broken Auth، XSS هم الأول.
4. درّب فريقك: secure coding، code reviews، وسياسات لمتابعة الـ dependencies.
5. جهّز خطة للـ patching وـ rollback.
6. راقب Logs وادِّي alerts للـ anomalies فورًا.