أمن تطبيقات الويب: فهم الثغرات وكيفية اكتشافها وحمايتها | الجزء الثاني
في الجزء الأول من سلسلة أمن تطبيقات الويب تعرّفنا على الأساسيات والمفاهيم التي يحتاجها أي شخص يريد دخول عالم Web Application Security.
أما الآن، فسنبدأ بالدخول إلى المنطقة التي تصبح فيها الصورة أكثر وضوحًا.
تطبيق الويب ليس مجرد صفحة تراها في المتصفح.
خلف زر تسجيل الدخول، وخلف نموذج البحث، وخلف كل طلب HTTP، توجد مجموعة من العمليات التي تتعامل مع البيانات، الجلسات، الحسابات، قواعد البيانات والصلاحيات.
وأي خطأ صغير في واحدة من هذه الطبقات قد يتحول إلى ثغرة أمنية حقيقية.
«ملاحظة: الأمثلة والمفاهيم في هذا المقال مخصصة للتعلم والاختبار داخل بيئات تملك تصريحًا لاختبارها، مثل المختبرات التعليمية وCTF والأنظمة التي تملكها.»
---
ما الذي يحدث عندما تستخدم تطبيق ويب؟
عندما تفتح موقعًا وتضغط على زر أو ترسل نموذجًا، لا يحدث الأمر بطريقة سحرية.
المتصفح يرسل طلبًا إلى الخادم، والخادم يعالج الطلب ثم يعيد استجابة.
يمكن تبسيط العملية هكذا:
المستخدم → المتصفح → HTTP Request → Web Server → Application → Database
ثم تعود النتيجة:
Database → Application → Web Server → HTTP Response → المتصفح
وهنا تبدأ الأسئلة الأمنية المهمة:
- هل يستطيع المستخدم إرسال بيانات لم يكن من المفترض أن يرسلها؟
- هل يتحقق الخادم من صلاحيات المستخدم؟
- هل يتم تنظيف البيانات المدخلة؟
- هل يمكن التلاعب بالمعرفات؟
- هل الجلسة محمية؟
- هل المعلومات الحساسة تظهر في الاستجابة؟
- هل التطبيق يثق بالمتصفح أكثر مما ينبغي؟
وهذه النقطة الأخيرة مهمة جدًا:
لا تثق بالمتصفح
المتصفح موجود عند المستخدم.
وهذا يعني أن المستخدم يستطيع مشاهدة الطلبات التي يرسلها، تعديل بعض البيانات، إعادة إرسال الطلبات، وتغيير القيم التي يرسلها التطبيق.
لذلك يجب أن تكون التحققات الأمنية الحقيقية على الخادم.
إذا كان التطبيق يرسل:
role=user
فليس من المنطقي أن يعتمد الخادم على هذه القيمة وحدها ليقرر صلاحيات المستخدم.
القاعدة الذهبية:
كل شيء يأتي من العميل يجب اعتباره غير موثوق حتى يثبت العكس.
---
1. حقن SQL — عندما تصل البيانات إلى قاعدة البيانات بطريقة خطرة
واحدة من أشهر فئات ثغرات تطبيقات الويب هي SQL Injection.
تحدث المشكلة عندما يقوم التطبيق ببناء استعلام قاعدة البيانات بطريقة غير آمنة باستخدام بيانات يتحكم بها المستخدم.
فكر في تطبيق يحتوي على نموذج بحث.
المستخدم يكتب:
عبدالله
والتطبيق يبحث في قاعدة البيانات.
المشكلة تبدأ عندما يتم دمج إدخال المستخدم مباشرة داخل استعلام SQL بدل استخدام آليات آمنة مثل Parameterized Queries.
النتيجة قد تكون أن بيانات المستخدم لا تبقى مجرد "بيانات"، بل تبدأ بالتأثير على منطق الاستعلام نفسه.
وهنا يظهر الفرق بين:
Data
و
Code
التطبيق الآمن يحافظ على الفصل بين الاثنين.
كيف تتم الحماية؟
أهم الإجراءات:
- استخدام Parameterized Queries.
- استخدام ORM بطريقة صحيحة.
- التحقق من المدخلات.
- إعطاء قاعدة البيانات أقل صلاحيات ممكنة.
- عدم إظهار أخطاء SQL للمستخدم.
- مراقبة الاستعلامات غير الطبيعية.
والأهم:
لا تعتمد على إخفاء رسالة الخطأ فقط.
إخفاء الخطأ لا يصلح الثغرة؛ هو فقط يخفي الدليل عليها.
---
2. XSS — عندما يتحول إدخال المستخدم إلى محتوى قابل للتنفيذ
ثغرة Cross-Site Scripting (XSS) تحدث عندما يستطيع مهاجم جعل متصفح الضحية يتعامل مع إدخال غير موثوق باعتباره محتوى قابلًا للتنفيذ.
توجد عدة أنواع معروفة من XSS، منها:
Reflected XSS
يحدث عندما ينعكس الإدخال في استجابة الخادم دون معالجة مناسبة.
Stored XSS
يتم تخزين الإدخال الخبيث في النظام، ثم يتم عرضه لاحقًا للمستخدمين.
وهذا النوع قد يكون أخطر لأنه يمكن أن يؤثر على عدة مستخدمين.
DOM-based XSS
تحدث المشكلة في جانب العميل عندما تتعامل JavaScript مع بيانات غير موثوقة بطريقة غير آمنة.
---
كيف نحمي التطبيق من XSS؟
الحماية ليست مجرد حذف بعض الرموز.
يجب استخدام:
- Output Encoding المناسب للسياق.
- Sanitization عند الحاجة.
- Content Security Policy.
- تجنب التعامل غير الآمن مع DOM.
- عدم إدخال بيانات المستخدم مباشرة داخل HTML أو JavaScript.
- استخدام أطر عمل توفر حماية تلقائية عند استخدامها بالشكل الصحيح.
والقاعدة المهمة:
تعامل مع بيانات المستخدم كبيانات، وليس ككود.
---
3. Broken Access Control — أخطر مما يبدو
تسجيل الدخول لا يعني أن المستخدم يستطيع الوصول إلى كل شيء.
هناك فرق بين:
Authentication
و
Authorization
Authentication تعني:
«من أنت؟»
Authorization تعني:
«ماذا يُسمح لك أن تفعل؟»
قد يكون المستخدم مسجل الدخول بشكل صحيح، ومع ذلك يستطيع الوصول إلى مورد لا يملك صلاحية الوصول إليه.
وهنا تظهر مشاكل Broken Access Control.
مثال بسيط:
لديك مستخدمان:
User A
User B
كل مستخدم لديه حسابه الخاص.
إذا كان التطبيق لا يتحقق بشكل صحيح من ملكية المورد الذي يطلبه المستخدم، فقد يتمكن User A من الوصول إلى بيانات تخص User B.
المشكلة هنا ليست في كلمة المرور.
المشكلة في منطق الصلاحيات.
---
4. IDOR — عندما يصبح الرقم مفتاحًا لكل شيء
من الأمثلة الشهيرة على مشاكل التحكم في الوصول:
Insecure Direct Object Reference (IDOR)
تخيل أن التطبيق يستخدم معرفًا لعرض ملف:
/profile/1001
ثم يوجد:
/profile/1002
وجود رقم مختلف لا يعني أن المستخدم يجب أن يستطيع الوصول إلى المورد.
التطبيق الآمن لا يقول:
«المستخدم طلب 1002، إذن أعطه 1002.»
بل يسأل:
«هل المستخدم الحالي يمتلك أصلًا صلاحية الوصول إلى 1002؟»
هذه عقلية مهمة جدًا في اختبار الاختراق.
لا تسأل فقط:
"هل الصفحة تعمل؟"
اسأل:
"هل يجب أن تعمل لهذا المستخدم تحديدًا؟"
---
5. Authentication — كلمة المرور ليست النظام كله
تسجيل الدخول أحد أهم أجزاء تطبيق الويب.
لكن المصادقة الآمنة تحتاج إلى أكثر من مجرد:
Username + Password
يجب التفكير في:
- تخزين كلمات المرور بطريقة آمنة.
- حماية جلسات المستخدم.
- تحديد محاولات تسجيل الدخول.
- منع الهجمات الآلية.
- استخدام MFA عندما يكون مناسبًا.
- إدارة استعادة الحسابات بشكل آمن.
- إنهاء الجلسات بطريقة صحيحة.
- حماية Cookies.
كلمة المرور القوية مهمة، لكن إذا كانت جلسة المستخدم نفسها ضعيفة فقد تصبح كل قوة كلمة المرور بلا قيمة.
---
6. Session Management — الجلسة هي هوية المستخدم بعد تسجيل الدخول
بعد تسجيل الدخول، يحتاج التطبيق إلى معرفة أن الطلبات التالية تأتي من المستخدم نفسه.
هنا تظهر Session.
غالبًا يتم تخزين معرف الجلسة داخل Cookie.
ولهذا يجب حماية الـ Cookie باستخدام خصائص مناسبة مثل:
Secure
HttpOnly
SameSite
Secure
يساعد على منع إرسال Cookie عبر اتصال غير مشفر.
HttpOnly
يقلل من قدرة JavaScript على الوصول إلى Cookie.
SameSite
يساعد في تقليل بعض أنواع هجمات Cross-Site Request Forgery.
لكن لا توجد خاصية واحدة تستطيع إصلاح تصميم جلسات سيئ.
الأمان الحقيقي يأتي من التصميم الكامل لنظام الجلسات.
---
7. CSRF — عندما يتم استغلال ثقة الموقع في جلسة المستخدم
Cross-Site Request Forgery تعتمد على فكرة بسيطة:
المستخدم لديه جلسة موثوقة مع موقع معين، ثم يتم خداع المتصفح لإرسال طلب إلى ذلك الموقع.
إذا كان التطبيق لا يتحقق من أن الطلب مقصود فعلًا من المستخدم، فقد تحدث عمليات غير مرغوبة.
من وسائل الحماية:
- CSRF Tokens.
- SameSite Cookies.
- التحقق من Origin/Referer في الحالات المناسبة.
- تصميم واجهات حساسة بطريقة تقلل مخاطر الطلبات غير المقصودة.
لكن مرة أخرى:
لا تستخدم وسيلة واحدة وتعتبر المهمة انتهت.
الأمان طبقات.
---
8. Server-Side Request Forgery — عندما يصبح الخادم نفسه أداة طلب
ثغرة SSRF مختلفة قليلًا.
بدل أن يطلب المهاجم من متصفحه الوصول إلى مورد معين، يحاول جعل الخادم ينفذ الطلب نيابة عنه.
وهذا يصبح خطيرًا خصوصًا عندما يمتلك الخادم إمكانية الوصول إلى شبكات أو خدمات لا يستطيع المستخدم الوصول إليها مباشرة.
التطبيقات التي تستقبل روابط من المستخدم تحتاج إلى التعامل معها بحذر شديد.
من إجراءات الحماية:
- Allowlist للوجهات المسموح بها.
- منع الوصول إلى العناوين الداخلية الحساسة.
- التحقق الصارم من URL.
- التحكم في إعادة التوجيه.
- عزل الخدمات الحساسة عن التطبيق قدر الإمكان.
- استخدام مبدأ أقل صلاحية.
---
9. File Upload — ملف واحد قد يصبح مشكلة كبيرة
ميزة رفع الملفات تبدو بسيطة:
Choose File → Upload
لكن أمنيًا، هي سطح هجوم مهم.
يجب على التطبيق ألا يعتمد على اسم الملف أو امتداده فقط.
من الأفضل:
- التحقق من نوع الملف الحقيقي.
- تحديد الأحجام المسموحة.
- إعادة تسمية الملفات.
- تخزين الملفات خارج المسارات الحساسة.
- منع تنفيذ الملفات المرفوعة.
- استخدام صلاحيات مناسبة.
- فحص الملفات حسب طبيعة التطبيق.
فكرة مهمة:
الملف الذي يرفعه المستخدم ليس ملفًا "موثوقًا" لمجرد أن الامتداد يبدو صحيحًا.
---
10. Security Misconfiguration — عندما تكون المشكلة في الإعدادات
أحيانًا لا تكون هناك ثغرة معقدة في الكود.
المشكلة تكون في الإعدادات.
مثل:
- رسائل أخطاء تفصيلية في بيئة الإنتاج.
- خدمات غير ضرورية مفعلة.
- إعدادات افتراضية لم يتم تغييرها.
- Headers أمنية ناقصة.
- صلاحيات واسعة.
- معلومات حساسة مكشوفة.
- ملفات أو لوحات إدارة يمكن الوصول إليها دون حماية مناسبة.
وهنا تظهر قاعدة مهمة:
الأمان ليس فقط كتابة كود جيد؛ بل تشغيل النظام بطريقة صحيحة أيضًا.
---
11. كيف يفكر مختبر اختراق تطبيقات الويب؟
المبتدئ قد ينظر إلى الموقع ويقول:
«"هل توجد ثغرة؟"»
أما المختبر المحترف فيبدأ بأسئلة مختلفة:
أولًا: ما الذي أستطيع الوصول إليه؟
يبدأ بفهم التطبيق:
- الصفحات.
- النطاقات الفرعية.
- نقاط API.
- نماذج الإدخال.
- ملفات JavaScript.
- آليات تسجيل الدخول.
- الوظائف المختلفة.
ثانيًا: ما البيانات التي أتحكم بها؟
كل إدخال مهم:
Username
Search
ID
URL
File
JSON
Headers
Cookies
Parameters
ثالثًا: أين تذهب هذه البيانات؟
هل تصل إلى:
- قاعدة البيانات؟
- HTML؟
- JavaScript؟
- نظام الملفات؟
- خدمة خارجية؟
- API آخر؟
رابعًا: ما الذي يحدث إذا تغيرت الصلاحيات؟
وهذه من أهم الأسئلة.
اختبار الأمان الحقيقي لا يركز فقط على:
«ماذا يستطيع المستخدم أن يفعل؟»
بل أيضًا:
«ماذا يستطيع المستخدم أن يفعل ولا ينبغي له أن يستطيع فعله؟»
---
12. HTTP هو قلب عملية الاختبار
لفهم أمن تطبيقات الويب بعمق، يجب أن تصبح مرتاحًا مع HTTP.
طلب HTTP يمكن أن يحتوي على:
Method
URL
Headers
Cookies
Parameters
Body
والخادم يرد بـ:
Status Code
Headers
Body
مثلًا:
200 OK
يعني أن الطلب تمت معالجته بنجاح.
بينما:
401 Unauthorized
يشير عادةً إلى مشكلة في المصادقة.
و:
403 Forbidden
يعني أن الوصول مرفوض.
و:
404 Not Found
يعني أن المورد غير موجود أو غير متاح.
فهم هذه التفاصيل يجعل أدوات اختبار الويب أكثر فائدة بكثير.
---
13. الأدوات لا تصنع مختبر اختراق
هناك أدوات كثيرة في مجال أمن تطبيقات الويب.
مثل:
- Burp Suite
- OWASP ZAP
- Nmap
- Browser DevTools
لكن هناك خطأ شائع:
«"إذا تعلمت الأداة، أصبحت مختبر اختراق."»
لا.
الأداة مجرد عدسة.
إذا لم تفهم HTTP والجلسات والصلاحيات وقواعد البيانات وJavaScript، فلن تعرف ماذا تبحث عنه حتى لو كان أمامك مباشرة.
المحترف لا يعتمد على الأداة وحدها.
هو يفهم ما الذي يجب أن يراه قبل أن يضغط الزر.
---
14. منهجية بسيطة لاختبار تطبيق ويب
يمكن بناء منهجية تعليمية بهذا الشكل:
المرحلة الأولى — Reconnaissance
جمع المعلومات المسموح بها عن التطبيق.
المرحلة الثانية — Mapping
رسم خريطة للصفحات والوظائف ونقاط API.
المرحلة الثالثة — Authentication
فهم نظام تسجيل الدخول والجلسات.
المرحلة الرابعة — Authorization
اختبار الحدود بين المستخدمين والأدوار.
المرحلة الخامسة — Input Validation
فهم كيفية تعامل التطبيق مع المدخلات.
المرحلة السادسة — Business Logic
وهذه من أهم المراحل.
لأن بعض المشاكل لا تكون ثغرات تقنية واضحة، وإنما أخطاء في منطق التطبيق نفسه.
المرحلة السابعة — Configuration
مراجعة الإعدادات والرؤوس والخدمات والمعلومات المكشوفة.
المرحلة الثامنة — Reporting
توثيق المشكلة وتأثيرها وطريقة إصلاحها.
---
15. أخطر شيء ليس دائمًا الثغرة الأشهر
من السهل أن تنشغل بـ:
SQL Injection
أو:
XSS
لكن تطبيقًا قد يكون خاليًا منهما ومع ذلك يحتوي على مشكلة خطيرة جدًا في الصلاحيات أو منطق الأعمال.
مثال:
متجر إلكتروني يمنع المستخدم من شراء أكثر من 5 تذاكر.
قد تكون قاعدة التحقق موجودة في الواجهة فقط.
إذا كان الخادم لا يفرض الحد، فالمشكلة ليست في HTML أو JavaScript.
المشكلة في Business Logic.
وهنا نصل إلى مستوى مختلف من التفكير:
«لا تختبر الكود فقط. اختبر القواعد التي يفترض أن تحكم التطبيق.»
---
الخلاصة
أمن تطبيقات الويب ليس سباقًا للعثور على أكبر عدد من الثغرات.
إنه فهم عميق للطريقة التي يتحرك بها البيانات والصلاحيات والثقة داخل النظام.
تعلم أن تسأل:
من يرسل البيانات؟
أين تذهب؟
من يستطيع تعديلها؟
هل الخادم يتحقق منها؟
من يملك صلاحية الوصول إليها؟
ماذا يحدث عندما تتغير القيم؟
إذا بدأت تفكر بهذه الطريقة، ستتغير نظرتك إلى مواقع الويب بالكامل.
لن ترى الصفحة كصورة جميلة وزر تسجيل دخول فقط.
ستبدأ برؤية:
Client → HTTP → Server → Application → Database → Authentication → Authorization → Business Logic
وهنا يبدأ الانتقال الحقيقي من شخص يستخدم أدوات الأمن إلى شخص يفهم أمن تطبيقات الويب.
وفي الجزء القادم، سننتقل خطوة أخرى إلى الأمام وندخل في منهجية عملية لتحليل تطبيق ويب داخل بيئة تدريبية، وكيفية اكتشاف نقاط الدخول ورسم خريطة للتطبيق قبل البدء في اختبار الثغرات.🔥🚀
تعليقات