لاب رقم (6) | DOM XSS in jQuery selector sink using a hashchange event

اكتشف كيفية استغلال DOM XSS عبر حدث hashchange في jQuery. شرح عملي لكيفية استخدام الـ iframes لتنفيذ هجمات تلقائية وتجاوز معالجة jQuery للـ Selectors.

ثغرة DOM XSS: سحر الـ jQuery Selector وحدث الـ hashchange ⚡🎭

ثغرة DOM XSS: سحر الـ jQuery Selector وحدث الـ hashchange ⚡🎭

مرحباً بصيادي الثغرات! اليوم سنتحدث عن نوع ذكي جداً من ثغرات الـ DOM XSS. في اللابات السابقة، كان الكود يتنفذ عند تحميل الصفحة أو الضغط على زر، لكن ماذا لو أخبرتك أن مجرد "تغيير الجزء الأخير من الرابط" قد يفتح ثغرة أمنية؟

تطبيقنا اليوم من PortSwigger هو:
DOM XSS in jQuery selector sink using a hashchange event

اليوم سنتعلم كيف تسيء مكتبة jQuery فهم ما نكتبه داخل "الهاش" (Hash) في الرابط، وكيف نستغل ذلك لصالحنا. لنبدأ! 🚀


🔍 ما هو الـ jQuery Selector Sink؟

في مكتبة jQuery، نستخدم علامة الدولار $() لاختيار العناصر. مثلاً $('#menu') تختار العنصر الذي يحمل ID "menu".

الخطورة تكمن في أن jQuery قديماً كانت إذا أعطيتها وسم HTML بدلاً من اسم عنصر (مثل $('<img src=x>'))، فإنها تحاول إنشاء هذا العنصر فوراً في الصفحة! هذا السلوك هو الـ Sink الذي سنستغله.


🧠 تحليل كود اللاب (The Event Listener)

إذا نظرت إلى كود الصفحة، ستجد وظيفة (Function) تستمع لحدث يسمى hashchange:

$(window).on('hashchange', function() {
    var element = $(location.hash);
    element[0].scrollIntoView();
});

ماذا يحدث هنا؟
1. الكود ينتظر أي تغيير في الـ "Hash" (وهو الجزء الذي يبدأ بعلامة # في نهاية الرابط).
2. بمجرد أن يتغير، يأخذ القيمة الموجودة بعد العلامة ويضعها مباشرة داخل محرك البحث الخاص بـ jQuery $().
3. ثم يحاول جعل هذا العنصر يظهر في الشاشة باستخدام scrollIntoView().

المطور هنا افترض أن المستخدم سيضع ID لعنصر ما (مثل #section1)، لكنه لم يتخيل أننا سنضع كود HTML كاملاً! 😈


🛠️ خطة الهجوم (The Auto-Exploit)

بما أننا نحتاج لتغيير الـ Hash "تلقائياً" لكي يظهر التأثير، سنحتاج لإنشاء صفحة خارجية (أو استخدام الـ Exploit Server في بورتسويجر) تقوم بتغيير الرابط للضحية.

الـ Payload السحري:

<iframe src="https://YOUR-LAB-ID.web-security-academy.net/#<img src=x onerror=alert(1)>" onload="this.src+=' '"></iframe>

كيف يعمل هذا الهجوم؟
1. الـ iframe يفتح موقع اللاب ويضع في نهايته (بعد الـ #) وسم صورة ملغم.
2. خاصية onload في الـ iframe تقوم بإضافة "مسافة" بسيطة للرابط، مما يجبر المتصفح على اعتبار أن الـ Hash قد "تغير" (Trigger hashchange).
3. كود jQuery يستلم الوسم <img>، وبدلاً من البحث عن عنصر، يقوم بإنشائه، فيحدث الـ onerror وينطلق الـ alert! 💥


📝 خطوات الحل العملية

  1. اذهب إلى Exploit Server الخاص باللاب.
  2. في قسم الـ Body، ضع كود الـ iframe المذكور أعلاه (تأكد من وضع رابط اللاب الخاص بك مكان YOUR-LAB-ID).
  3. اضغط على Store ثم Deliver exploit to victim.

النتيجة: مبروك! لقد قمت بعمل هجوم تلقائي بالكامل يعتمد على أحداث المتصفح. 🥳


💡 نصيحة الصياد (Bug Bounty Tip)

  • راقب الروابط: أي موقع يتغير محتواه عند إضافة # في الرابط دون تحديث الصفحة هو مرشح قوي لوجود هذه الثغرة.
  • قوة الـ Iframe: في الـ Bug Bounty، الـ Iframe هو صديقك الصدوق لإثبات أن الثغرة يمكن تنفيذها تلقائياً دون تدخل كبير من المستخدم.

🚀 الخاتمة

ثغرة الـ hashchange تعلمك أن الثغرات ليست دائماً في إرسال البيانات للسيرفر، بل أحياناً في كيفية تعامل المتصفح مع روابط الـ URL الداخلية. استمر في تحليل الأكواد، فالشيطان دائماً يكمن في التفاصيل!

إرسال تعليق