الثغرات في تطبيقات الويب
دليل شامل

ما الذي ستخرج به من هذا الدرس؟

هذا الدرس ليس قائمة حمولات تُنسخ وتُلصق. الهدف أن تبني نموذجًا ذهنيًا يجعل كل ثغرة جديدة تراها لاحقًا تندرج تلقائيًا في مكانها الصحيح: أي طبقة؟ أي حدود ثقة؟ ما شكل البيانات؟ وما الذي ينكسر حين تعبر هذه البيانات من طبقة إلى أخرى؟

المتطلبات المسبقة

• أساسيات HTTP: الطلب والاستجابة، الترويسات، الكوكيز، انعدام الحالة (Stateless).
• قراءة كود PHP أو JavaScript بمستوى متوسط — لا تحتاج كتابة أنظمة كاملة.
• سطر أوامر Linux مريح: cd, grep, curl, chmod, ss.
• جهاز افتراضي أو Docker — كل شيء داخل مختبرك المحلي.

أربعة أجزاء، مسار واحد من النظرية إلى الاستغلال

الدرس مبني على تسلسل واحد لا يُقفز فوقه: نفهم المسار، ثم نحدد موضع الكسر، ثم نستغل، ثم نُصلح ونوثّق. الجزء الثالث (DVWA) هو التطبيق العملي للجزء الثاني، والجزء الرابع هو ما يفصل الهاوي عن المحترف.

كيف تدرس هذا الدرس؟

1. شغّل المختبر أولًا

   لا تقرأ الجزء الثاني قبل أن يكون DVWA يعمل على localhost:8080. الفهم يأتي من ملاحظة الاستجابة تتغير أمامك.

2. اقرأ المستوى Low ثم افتح الكود

   DVWA يعرض الكود المصدري لكل مستوى في زر View Source. اقرأ السطر الذي سبب الثغرة قبل أن تطبّق الحمولة.

3. اصعد المستويات بالترتيب

   كل مستوى يعلّمك دفاعًا واحدًا وكيف يُلتف عليه. عندما تصل إلى Impossible تكون قد رأيت الحل الصحيح.

4. أعد كتابة السلسلة بيدك

   بعد كل ثغرة اكتب في دفترك: المدخل ← السياق ← الحمولة ← النتيجة ← الإصلاح. هذه البطاقة هي مخرَج التعلم الحقيقي.

مفهوم أساسي واحد يفسّر تسعين بالمئة من الثغرات

كل ثغرة في هذا الدرس تقريبًا هي الخطأ نفسه في ثوب مختلف: بيانات قدّمها المستخدم تم تفسيرها — في طبقة ما — كأنها تعليمات. المتصفح يفسّرها كـHTML، قاعدة البيانات كـSQL، والصدفة (Shell) كأمر تنفيذي. حين تنجح في جعل طبقة ما تعتقد أن بياناتك "كود"، فقد اخترقتها.

حدود الثقة (Trust Boundaries)

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

جدول السياقات: أين تُكسر البيانات؟

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

ثلاثة محاور تحكم الدرس كله

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

الطبقات السبع في سطر واحد لكل طبقة

هذه هي البنية التي سيُبنى عليها المخطط في القسم التالي، وستُستخدم كفهرس مرجعي لكل ثغرة في الدرس.

مسار الحزمة عبر الطبقات

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

أين تقع الثغرة على المخطط؟

الخطأ الأول الذي يقع فيه المبتدئ هو ظنّ أن الثغرة "تسكن" في مكان واحد. في الحقيقة لكل ثغرة ثلاثة مواضع: موضع الحقن (Injection Point)، وموضع التنفيذ (Execution Point)، وموضع الأثر (Impact Point). الثغرة تبدأ عند حدّ ثقة، لكنها تُنفَّذ في طبقة أخرى غالبًا.

القاعدة العملية: المهاجم يفكر من النهاية

المختبِر المتمرّس يبدأ من الأثر الذي يريده ثم يرجع للخلف: أريد بيانات المستخدمين ← أحتاج استعلامًا أتحكم فيه (L5) ← أحتاج مدخلًا يصل إلى الاستعلام دون ترميز (L4) ← أبحث عن حقل يُبنى به الاستعلام. هذا التفكير العكسي هو ما يحوّل قائمة ثغرات إلى خطة اختبار. وبالمثل: أريد كودًا ينفّذ في متصفح المدير ← أبحث عن حقل يُعرض للمدير دون ترميز (Stored XSS) ← أفحص لوحة الإدارة ومنطق الموافقة على الطلبات.

أين تحدث الثغرات في كل طبقة؟

هذا هو المخطط الشامل الذي سنفصّله في الأقسام 07–13. اقرأه كخريطة لا كقائمة حفظ: كل صف هو عائلة ثغرات، وكل عائلة لها سؤال اختبار واحد يميّزها.

الطبقة 1 · المتصفح (Browser): حيث تتحول البيانات إلى كود

المتصفح ليس نافذة عرض سلبية؛ إنه نظام تشغيل صغير ينفّذ كودًا بلغات ثلاث (HTML، CSS، JavaScript)، ويملك مخزنًا للأسرار (الكوكيز وlocalStorage)، ويحمل صلاحية التصرف باسم المستخدم في كل موقع. لذلك فكل بيانات تصل إليه من الخادم تُعدّ "كودًا محتملًا" حتى تُثبت العكس.

ماذا يحدث فعلًا عند وصول الصفحة؟

1. التحليل (Parsing)

   يقرأ HTML ويبني شجرة DOM. أي وسم <script> يقابله يوقف التحليل وينفّذ الكود فورًا — هذه هي نقطة قوة XSS الأولى.

2. بناء الأنماط

   CSS يُبنى في شجرة أخرى (CSSOM). وسم <style> أو سمة style يمكن أن تُستغل لتسريب بيانات عبر background:url().

3. تنفيذ JavaScript

   المحرّك (V8/SpiderMonkey) ينفّذ الكود داخل سياق أصل (Origin) محدد. كل ما يملكه الكود هو ما تملكه الصفحة: الكوكيز غير HttpOnly، الـDOM، والطلبات باسم المستخدم.

4. تطبيق السياسات

   قبل كل طلب: SOP يمنع القراءة عبر الأصول، CORS يحدد الاستثناءات، CSP يقيّد مصادر السكربتات، SameSite يقيّد إرسال الكوكيز.

النموذج الأمني: سياسة الأصل الواحد (SOP)

"الأصل" (Origin) ليس النطاق فقط، بل ثلاثي: scheme + host + port. فـ https://a.com وhttp://a.com أصلان مختلفان، وكذلك a.com:443 وa.com:8443. الخطأ الشائع في الفهم: SOP لا يمنع إرسال الطلب، بل يمنع قراءة الاستجابة. لهذا تنجح هجمات CSRF: الطلب يُرسل، والفعل يحدث، والمهاجم لا يرى الرد — ولا يحتاج أن يراه.

عائلات الثغرات في هذه الطبقة

1) XSS — الحقن في سياق المتصفح

ثلاثة أنواع، والفرق بينها هو مكان تخزين الحمولة: المنعكس (Reflected) يمرّ في الطلب ويعود في نفس الاستجابة؛ المخزّن (Stored) يُحفظ في قاعدة البيانات ليصيب كل من يفتح الصفحة؛ وDOM يبقى داخل المتصفح ولا يلمس الخادم أبدًا لأن المشكلة في كود JavaScript نفسه.

// المصدر (Source): يقرأ من العنوان الذي يتحكم به المهاجم
var name = location.hash.slice(1);

// الحوض (Sink): يفسّر النص كـHTML — هنا يولد XSS
document.getElementById("greeting").innerHTML = "مرحبًا " + name;

// البديل الآمن: النص يبقى نصًا
document.getElementById("greeting").textContent = "مرحبًا " + name;

المصادر الشائعة: location.search/hash، document.referrer، localStorage، event.data من postMessage. الأحواض الخطرة: innerHTML، document.write، eval، setTimeout(string)، element.setAttribute('href')، jQuery.html().

السؤال الذي يحدد خطورة XSS ليس "هل ظهرت نافذة تنبيه؟" بل في سياق من ينفّذ السكربت؟ إذا كان الضحية مديرًا، فالسكربت يقرأ كل شيء يراه المدير: قائمة المستخدمين، رموز CSRF، وأحيانًا يحوّل المتصفح إلى محطة تحكم كاملة. لهذا يُعدّ alert(1) مجرد إثبات وجود الثغرة، لا استغلالًا.

2) Clickjacking — استغلال ثقة المستخدم لا ثقة الخادم

تُوضع الصفحة الحساسة في iframe شفاف فوق زر جذّاب، فيضغط الضحية على "احصل على جائزة" وهو يضغط فعليًا على "حذف الحساب". الحل في الطبقة 1 بحت: X-Frame-Options: DENY أو Content-Security-Policy: frame-ancestors 'none'. وبما أن هذا العطب يُصنّف في OWASP تحت A05 (Misconfiguration)، فهو مثال جيد على ثغرة "سياسة" لا "كود".

3) postMessage غير محكم

عندما يفتح التطبيق نافذة أو إطارًا خارجيًا ويستقبل رسائل بـ window.addEventListener('message', handler) دون التحقق من event.origin، يمكن لأي موقع إرسال أمر إليه. الشكل الصحيح: تحقق من الأصل، وتحقق من شكل البيانات، ولا تستخدم eval(event.data) أبدًا.

4) Prototype Pollution

دمج كائن JSON يحتوي __proto__ أو constructor.prototype في كائن آخر يلوّث كل الكائنات في التطبيق — وقد ينتهي الأمر بتنفيذ كود عبر مكتبات تستدعي خصائص موروثة. المصدر النموذجي: دوال الدمج العشوائي (deep merge) في مكتبات قديمة.

5) إساءة إعداد CORS

ترويسة Access-Control-Allow-Origin: * مع Allow-Credentials: true تفتح البيانات لكل المواقع. والأخطر: السماح بأصل يُشتق من ترويسة Origin كما هي، أو استخدام تعبير نمطي واسع مثل /example\.com/ الذي يقبل example.com.evil.tld. الفحص السريع:

$ curl -sI https://target.tld/ | grep -Ei 'content-security-policy|x-frame|strict-transport|set-cookie'
$ curl -sI -H "Origin: https://evil.tld" https://target.tld/api/me | grep -i 'access-control'
$ curl -s -o /dev/null -w "%{http_code}\n" https://target.tld/.git/HEAD

6) منطق يعمل في المتصفح فقط

أي فحص يُنفَّذ في JavaScript فقط هو اقتراح لا حكم: إخفاء حقل، تعطيل زر، التحقق من السعر، تحديد الدور. المستخدم يملك المتصفح، ويستطيع تعديل الحالة قبل الإرسال. في DVWA سنرى هذا حرفيًا في ثغرة "JavaScript Attacks": الرمز يُحسب في الصفحة، وأنت تملك الصفحة.

الطبقة 2 · الشبكة والنقل: من يقرأ ما تكتبه؟

هذه الطبقة لا تحتوي منطقًا ولا بيانات؛ تحتوي طريقًا. وأي طريق غير محصّن يعني أن كل ما يمرّ فيه — بما في ذلك كوكيز الجلسة وكلمات المرور — قابل للقراءة أو التعديل. الثغرات هنا غالبًا "صامتة": لا تظهر في سجل التطبيق، ولا يشتكي منها المستخدم.

# 1) شهادة TLS وتواريخها
$ openssl s_client -connect target.tld:443 -servername target.tld </dev/null 2>/dev/null | openssl x509 -noout -dates -subject

# 2) إصدارات وأُطر تشفير ضعيفة
$ nmap -p443 --script ssl-enum-ciphers target.tld

# 3) هل يوجد HSTS أصلاً؟
$ curl -sI http://target.tld | grep -i strict-transport-security

# 4) هل يقبل الخادم ترويسة Host غريبة؟
$ curl -s -H "Host: evil.tld" http://target.tld/reset | grep -o 'https\?://[^"]*' | head

الطبقة 3 · خادم الويب والوكيل: الأبواب التي نسيها أحد

معظم عمليات "الاختراق السريعة" لا تخترق كودًا؛ تستغل إعدادًا. ملف .git مكشوف يعني استرجاع الكود المصدري بالكامل — أي خريطة للثغرات. ملف نسخة احتياطية باسم backup.zip يعني قاعدة بيانات. صفحة phpinfo() تعني إصدارات، مسارات، ومتغيرات بيئة قد تحتوي مفاتيح.

ما تبحث عنه في هذه الطبقة

# بصمة سريعة + ترويسات
$ whatweb -a 3 http://localhost:8080
$ curl -sI http://localhost:8080/ | head -20

# تعداد مسارات بالقوائم الشائعة
$ ffuf -u http://localhost:8080/FUZZ -w /usr/share/seclists/Discovery/Web-Content/common.txt -mc 200,301,403 -fs 0

# فحص إعدادات معروفة الخطأ
$ nikto -h http://localhost:8080 -C all

# هل الكود المصدري مكشوف عبر git؟
$ git-dumper http://localhost:8080/.git/ ./loot-git

الطبقة 4 · التطبيق: حيث تُولد معظم الثغرات

هنا يتقابل المستخدم مع البيانات الحقيقية: منطق الأعمال، المصادقة، الصلاحيات، رفع الملفات، والـAPI. الطبقات السابقة يمكن تأمينها بإعداد واحد، أما هذه الطبقة فتُؤمَّن سطرًا بسطر — ولهذا تحتوي أغلب الثغرات التي ستستغلها في مختبر DVWA.

العائلات الثماني الكبرى

كيف يبدو الفرق بين الكود المثقوب والكود الآمن؟

// ── مثقوب: التسلسل النصي يخلق تعليمات جديدة ──
$id  = $_GET['id'];
$sql = "SELECT first_name, last_name FROM users WHERE user_id = '$id'";

// ── آمن: البيانات تُرسل منفصلة عن نص الاستعلام ──
$stmt = $pdo->prepare("SELECT first_name, last_name FROM users WHERE user_id = ?");
$stmt->execute([$id]);

// ── مثقوب: مدخل المستخدم يدخل الصدفة ──
system("ping -c 1 " . $_GET['ip']);

// ── آمن: قائمة بيضاء + تهريب صريح ──
if (!filter_var($ip, FILTER_VALIDATE_IP)) die("bad input");
system("ping -c 1 " . escapeshellarg($ip));

// ── مثقوب: المسار يتحكم به المستخدم ──
include($_GET['page'] . '.php');

// ── آمن: قائمة بيضاء صريحة ──
$pages = ['home', 'about', 'contact'];
$p = in_array($_GET['page'], $pages, true) ? $_GET['page'] : 'home';
include __DIR__ . "/pages/$p.php";

CSRF: الثغرة التي لا تحتاج إلى اختراق الخادم

الفكرة: المتصفح يرسل كوكي الجلسة تلقائيًا مع أي طلب إلى النطاق، حتى لو كان الطلب صادرًا من موقع آخر. فإذا كان تغيير كلمة المرور يتم عبر GET أو POST دون رمز عشوائي، يكفي أن يزور الضحية صفحة يُديرها المهاجم ليُغيَّر كلمة مروره. الدفاع ثلاثي: رمز CSRF فريد لكل جلسة/نموذج، وكوكي SameSite، ورفض الطلبات العابرة للنطاق على الأفعال الحساسة.

ثلاث ثغرات حديثة لا تظهر في DVWA

لأن المختبر يركّز على الكلاسيكيات، اعرف شكل الثغرات التي ستقابلها في تطبيقات 2026: SSRF (خادمك يجلب عنوانًا يتحكم به المهاجم فيصل إلى خدمات داخلية مثل 169.254.169.254 في السحابة)، وDeserialization (بيانات مخزّنة تُفكّ إلى كائنات فتُنفّذ سلاسل gadgets)، وBusiness Logic (خصم يُطبَّق مرتين، أو كمية سالبة تُنتج رصيدًا — لا يمكن لأي ماسح اكتشافها). هذه الثغرات لا تُكتشف بالأدوات؛ تُكتشف بفهم التطبيق.

الطبقة 5 · قاعدة البيانات: ما يحدث بعد أن ينجح الحقن

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

version(), user(), database()          -- من أنا وأين أقف
SELECT schema_name FROM information_schema.schemata;
SELECT table_name  FROM information_schema.tables  WHERE table_schema = database();
SELECT column_name FROM information_schema.columns WHERE table_name = 'users';
SELECT user, password FROM users;      -- الهدف النهائي
SELECT @@secure_file_priv;             -- هل أستطيع القراءة/الكتابة على القرص؟
SELECT LOAD_FILE('/etc/passwd');

ثلاثة أسئلة تحدد حجم الكارثة بعد الحقن. الأول: ما نوع حساب قاعدة البيانات؟ إن كان التطبيق يتصل بـroot فأنت تملك كل قواعد الخادم لا قاعدة تطبيق واحد. الثاني: هل توجد صلاحية FILE؟ حينها يمكن قراءة ملفات النظام — وأحيانًا كتابة ملف PHP في مجلد الويب، أي تحويل حقن SQL إلى تنفيذ كود كامل. الثالث: كيف تُخزَّن كلمات المرور؟ تجزئة بلا ملح (مثل MD5 في المستويات الدنيا من DVWA) تُكسر في ثوانٍ بالقواميس، بينما bcrypt/Argon2 تجعل الكسر مكلفًا.

$ hashid '5f4dcc3b5aa765d61d8327deb882cf99'        # ما نوع التجزئة؟
$ hashcat -m 0 hashes.txt /usr/share/wordlists/rockyou.txt   # MD5
$ john --format=raw-md5 --wordlist=rockyou.txt hashes.txt

الطبقة 6 · نظام التشغيل: من ثغرة في صفحة إلى سيطرة على الخادم

عندما تنجح في حقن أمر (Command Injection) أو رفع ملف قابل للتنفيذ، تنتقل من "مستخدم تطبيق" إلى "عملية على الخادم" — وغالبًا باسم www-data. السؤال التالي ليس "ماذا أفعل؟" بل "من أنا وما الذي أملكه؟".

1. تثبيت الموطئ (Foothold)

   التحقق من الهوية والنظام: id; uname -a; cat /etc/os-release. ثم اختبار القدرة على تنفيذ أمر خارجي (curl، wget، nc، python).

2. الحصول على جلسة تفاعلية

   أمر واحد يفتح صدفة عكسية إلى مستمع على جهازك يعطي استقرارًا أكبر من حقن أمر في كل مرة. المبدأ: الخادم يتصل بك، لا أنت به (لتجاوز الجدار الناري).

3. تعداد النظام (Enumeration)

   المستخدمون، الخدمات، المهام المجدولة، الملفات القابلة للكتابة، أسرار التطبيق في .env أو إعدادات الاتصال — وهي غالبًا كنز أكبر من صلاحيات الجذر.

4. رفع الصلاحيات (Privilege Escalation)

   البحث عن sudo بلا كلمة مرور، ملفات SUID، إصدار نواة قديم، أو مهمة مجدولة تعمل بصلاحية أعلى.

5. الحركة الجانبية والتثبيت

   من الخادم إلى قاعدة بيانات داخلية، أو خادم آخر على نفس الشبكة، ثم إنشاء طريق عودة دائم — وهو ما يُكشف عادةً في الطبقة 7 لا في L6.

$ id; whoami; hostname; uname -a
$ sudo -l 2>/dev/null                       # ماذا أستطيع تشغيله كجذر؟
$ find / -perm -4000 -type f 2>/dev/null     # ملفات SUID
$ ls -la /var/www/html; cat /var/www/html/config.php 2>/dev/null
$ ss -tulpn                                  # ما الخدمات الداخلية المتاحة؟

الطبقة 7 · الهوية والعمليات: من قال إنك أنت؟ ومن سيلاحظ؟

هذه الطبقة لا تحمي البيانات مباشرة؛ تحمي الادعاءات: "أنا فلان"، "أنا مخوّل"، "لم يحدث شيء". وأغلب الاختراقات الكبيرة لم تُكتشف لأن إحدى الطبقات السابقة سقطت، بل لأن هذه الطبقة لم تكن تراقب.

ماذا يُسجَّل فعلاً؟

السجل المفيد ليس "GET /login 200" بل: من الطالب، من أي IP وجهاز، بأي رمز جلسة، وما القيم التي أرسلها (مع حجب الحقول الحساسة)، وما الذي تغيّر. على هذا الأساس تُبنى قواعد الكشف: محاولات دخول فاشلة متكررة، تغيّر مفاجئ في عنوان IP داخل نفس الجلسة، طلبات تحمل ' أو UNION أو ../، أو ارتفاع في أخطاء 403 — كلها إشارات لا ثغرات.

تجهيز DVWA في خمس دقائق

DVWA (Damn Vulnerable Web Application) تطبيق PHP/MySQL صُمّم عمدًا ليحتوي على ثغرات شائعة، ويعرض لك كود المصدر بجانب كل تحدي. أشهر طريقة لتشغيله اليوم هي Docker — معزول، سريع، وقابل للحذف بالكامل.

# الطريقة 1: صورة جاهزة
$ docker run --rm -it -p 8080:80 --name dvwa vulnerables/web-dvwa

# الطريقة 2: من المستودع الرسمي (أحدث إصدار)
$ git clone https://github.com/digininja/DVWA.git && cd DVWA
$ docker compose up -d

# التحقق
$ docker ps --filter name=dvwa
$ curl -sI http://localhost:8080 | head -3

خطوات التهيئة الأولى

1. افتح http://localhost:8080

   ستظهر صفحة الدخول: المستخدم admin وكلمة المرور password.

2. اضغط Create / Reset Database

   يُنشئ الجداول ويملأ بيانات المستخدمين. إن ظهر خطأ، عد إلى صفحة Setup وأعد الإنشاء.

3. اضبط مستوى الأمان

   من DVWA Security اختر Low للبداية. سنصعد إلى Medium ثم High ثم Impossible مع كل ثغرة.

4. أضف كوكي الأمان إلى أدواتك

   كل أداة خارجية (sqlmap، hydra، ffuf) تحتاج PHPSESSID وsecurity=low. انسخهما من DevTools ← Application ← Cookies.

ست عشرة ثغرة، بنفس المنهج

كل ثغرة تُقدَّم بنفس القالب: الهدف ← الخطوات ← الأمر/الحمولة ← النتيجة المتوقعة ← سبب النجاح في الكود ← الدفاع. ابدأ من الأعلى خطرًا إن كان وقتك محدودًا: SQLi وCommand Injection وFile Upload تمنحك في العادة أكبر أثر.

بطاقة الإصلاح: من الثغرة إلى السطر الذي يمنعها

الدفاع ليس "استخدم مكتبة أمان". الدفاع هو أن تعرف السبب الجذري فتُصلح المكان الصحيح. هذا الجدول هو خلاصة المختبر — استخدمه كقائمة مراجعة عند تصميم أي تطبيق جديد.

كيف تعمل في اختبار حقيقي؟

الفرق بين من "يعرف الثغرات" ومن "يُجري اختبارًا" هو المنهجية: ترتيب، توثيق، ونطاق. المنهجية المرجعية هي OWASP WSTG — إطار يغطي ما يجب فحصه، لا كيف تُستغل النتيجة فقط.

1. التخطيط والنطاق

   ما المسموح؟ أي بيئات؟ أي ساعات؟ من نقطة الاتصال للطوارئ؟ كل شيء خارج هذا لا يُلمس.

2. الاستطلاع (Recon)

   معلومات عامة، نطاقات فرعية، تقنيات مستخدمة، بصمة الخادم — دون لمس التطبيق بعد.

3. الرسم (Mapping)

   تصفّح التطبيق بوكيل اعتراض، سجّل كل نقطة إدخال وكل دور مستخدم وكل تدفق (تسجيل، دفع، استعادة كلمة مرور).

4. الاختبار (Testing)

   طبّق بنود WSTG: مصادقة، جلسات، صلاحيات، حقن، منطق أعمال، معالجة أخطاء، تشفير نقل.

5. الاستغلال المُثبت (PoC)

   أثبت الأثر بأقل تدخل ممكن. لا تفجّر قاعدة بيانات لتثبت وجود ثغرة قراءة.

6. التقرير والمتابعة

   كل ثغرة بخطوات إعادة إنتاج دقيقة، أثر تجاري واضح، وإصلاح محدد. ثم إعادة اختبار بعد الإصلاح.

العدّة الأساسية

قالب تقرير يفهمه المطوّر والإدارة

الثغرة التي لا تُوثَّق لا تُصلَح. التقرير الجيد يجيب على أربعة أسئلة: ماذا؟ أين؟ كيف أعيد إنتاجها؟ وما الأثر التجاري؟ ثم يقدّم إصلاحًا محددًا لا نصيحة عامة.

## [HIGH] SQL Injection في معامل id
الموضع: GET /vulnerabilities/sqli/?id=
CVSS: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
CWE: 89  |  OWASP: A03:2021 Injection

الوصف:
يُبنى الاستعلام بالتسلسل النصي من مدخل المستخدم، ما يسمح بتغيير منطق
الاستعلام واستخراج بيانات من جداول أخرى.

خطوات إعادة الإنتاج:
1. سجّل الدخول كمستخدم عادي.
2. افتح /vulnerabilities/sqli/?id=1
3. أرسل: 1' UNION SELECT user, password FROM users #
4. تظهر أسماء المستخدمين وتجزئات كلمات المرور.

الأثر: كشف كامل لبيانات الاعتماد (5 حسابات) → سيطرة على
حسابات إدارية → تعديل بيانات العملاء.

الإصلاح المقترح:
- استبدال بناء الاستعلام بـ Prepared Statement مع ربط الأنواع.
- تقليل صلاحيات مستخدم قاعدة البيانات.
- إخفاء رسائل الخطأ وإرجاع رمز 500 عام.
المرجع: OWASP WSTG-INPV-05

تمارين تُثبت أنك تعلمت

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

للرجوع والتوسّع

• OWASP Top 10 (2021) — الإطار المرجعي لتصنيف المخاطر في تطبيقات الويب.
• OWASP Web Security Testing Guide (WSTG) — دليل بنود الاختبار خطوة بخطوة.
• OWASP ASVS — متطلبات التحقق الأمني عند البناء والمراجعة.
• PortSwigger Web Security Academy — مختبرات تفاعلية مجانية لكل فئة من الثغرات.
• DVWA (digininja/DVWA) — المستودع الرسمي، مع الشروحات وكود المستويات.
• CWE / MITRE — تصنيف أسباب الثغرات (CWE-79, CWE-89, CWE-78…).
• CVSS v3.1 Calculator (FIRST) — لحساب شدة الثغرة بشكل موحّد.