ما هى ثغرة الـ Cross-Site Scripting (XSS) وانواعها

ثغرة الـ XSS: كابوس المتصفحات وكنز الـ Bug Bounty 🕷️💻

هل تخيلت يوماً أن موقعاً إلكترونياً عملاقاً ومؤمناً بالكامل قد يسقط ضحية لمجرد "نص" صغير يُكتب في خانة بحث أو تعليق؟ نعم، هذا ما تفعله ثغرة الـ Cross-Site Scripting أو ما نعرفه اختصاراً بـ XSS.

إذا كنت بدأت رحلتك في مجال الـ Bug Bounty، فهذه الثغرة هي رفيقك الدائم. هي "السهل الممتنع"؛ سهلة الفهم، لكن اكتشافها بطرق إبداعية يحتاج إلى فنان. دعونا نغوص في التفاصيل ولكن بدون ملل! ☕

🧐 ما هي الـ XSS ببساطة؟

بكل بساطة، ثغرة XSS تحدث عندما يثق الموقع في كلام المستخدم "ثقة عمياء".

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

في عالم الويب:
المهاجم يقوم بحقن كود خبيث (غالباً بلغة JavaScript) داخل صفحة ويب يزورها ضحية آخر. المتصفح لا يعلم أن هذا الكود خبيث، فيقوم بتنفيذه فوراً. والنتيجة؟ سرقة بيانات، تحويل مسار، أو حتى السيطرة على حساب الضحية! 💥

🚦 أنواع الـ XSS الثلاثة (عائلات الرعب)

في عالم الـ Bug Bounty، نحن نقسم الـ XSS إلى ثلاثة أنواع رئيسية، وكل نوع له تكتيك خاص في الاصطياد:

1. الـ Reflected XSS (المنعكسة) 🪞

هذا النوع هو الأكثر شيوعاً. سُمي "منعكساً" لأن الكود الخبيث "ينعكس" من السيرفر للمتصفح فوراً.

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

2. الـ Stored XSS (المخزنة) 💾

هذا هو النوع الأخطر والأحب لقلب الـ Hackers!

• كيف يحدث؟ هنا الكود الخبيث لا ينعكس فقط، بل يتم "حفظه" داخل قاعدة بيانات الموقع (Database).
• السيناريو: تخيل قسماً للتعليقات في مدونة. المهاجم يكتب تعليقاً يحتوي على كود خبيث. الآن، أي شخص يزور هذه الصفحة ويقرأ التعليقات سيتم تنفيذ الكود في متصفحه تلقائياً دون أن يضغط على أي شيء!
• خطورتها: عالية جداً لأنها تصيب عدداً كبيراً من الضحايا وتعتبر دائمة حتى يتم حذفها.

3. الـ DOM-Based XSS (المخادعة) 👻

هنا اللعبة تختلف قليلاً. الثغرة لا تحدث في السيرفر، بل تحدث بالكامل داخل متصفح الضحية (Client-side).

• كيف يحدث؟ المطور يستخدم دوال JavaScript تأخذ بيانات من المستخدم (Source) وتضعها في الصفحة (Sink) بطريقة غير آمنة.
• مثال تقني: استخدام document.write() أو innerHTML مع بيانات قادمة من الرابط location.hash بدون فلترة.

🍪 ماذا يمكن أن نفعل بـ XSS؟ (Impact)

قد يسألك أحدهم: "يا أخي مجرد نافذة منبثقة (Alert Box) ظهرت، ما المشكلة؟"
هنا يأتي دورك لتشرح الخطورة الحقيقية. الـ alert(1) هي مجرد إثبات وجود (PoC)، لكن الضرر الحقيقي يشمل:

1. سرقة الكوكيز (Cookie Stealing): الاستيلاء على جلسة المستخدم والدخول لحسابه دون كلمة مرور. 🕵️‍♂️
2. التصيد (Phishing): إظهار نافذة تسجيل دخول وهمية لسرقة الباسورد.
3. Keylogging: تسجيل كل ما يكتبه الضحية على لوحة المفاتيح.
4. Redirecting: تحويل الضحية لموقع آخر خبيث.

💡 نصيحة لصياد الثغرات (Hunter Tip)

عندما تبحث عن XSS، لا تكن روبوتاً يجرب <script>alert(1)</script> في كل مكان.

• افهم التطبيق: كيف يتعامل مع المدخلات؟
• تجاوز الحماية (Bypass): المطورون يستخدمون فلاتر (Filters)، حاول التفكير خارج الصندوق لتخطيها.
• السياق (Context): هل الكود يتم حقنه داخل وسم HTML؟ أم داخل كود JS؟ السياق يحدد طريقة كتابة الـ Payload.

🚀 وفي النهاية

ثغرة الـ XSS ليست مجرد كود، هي فن فهم كيف تتحدث المتصفحات مع السيرفرات. كباحث أمني، إتقانك لهذه الثغرة يفتح لك أبواباً واسعة في برامج المكافآت.

ابدأ بتجربة المعامل (Labs) مثل PortSwigger لتتدرب بشكل قانوني وعملي. ولا تنسَ، الإنترنت الآمن يبدأ بباحث ذكي مثلك! 😉

هل واجهت XSS غريبة من قبل؟ شاركنا تجربتك في التعليقات! 👇