الأمن السيبراني وأمن المعلومات

Cross-Site Scripting: المخزن، المنعكس و DOM

7 دقيقة قراءةتاريخ النشر: 5 أغسطس 2026
توضيح بصري احترافي حول اختبار XSS في مجال Web و API PT
إجابة سريعة

يتم اختبار XSS فقط في المختبر أو في نظام مرخص. يتم فحص Request/Response، سلوك الخادم، الأدوار، الحالة والتأثير، باستخدام اختبارات دنيا لا تضر بالبيانات.

يجب أن يفحص اختبار أمان الويب و API حدود الثقة، الأذونات، الإدخال، الحالة والمنطق التجاري. كل اختبار في المقالة مخصص للمختبر، CTF أو نظام تم منح إذن صريح له. تركز المقالة الحالية على اختبار XSS وهي مخصصة لطلاب Web PT والمطورين. الهدف هو تقديم طريقة عمل يمكن تطبيقها في التدريب، في مقابلة مهنية وفي بيئة العمل، دون الاكتفاء بتعريف معجمي.

التحدي الرئيسي هو أن البيانات شبه كاملة دائمًا. context، encoding، CSP يمكن أن تشير إلى اتجاه، ولكن معناها يعتمد على الوقت، الأصل، المستخدم والنشاط المتوقع. لذلك سنبني الاختبار حول سؤال تحقيق، أدلة مطلوبة ومعيار واضح للانتهاء.

السيناريو العملي في المقالة هو: رسم خرائط Input-to-Sink في تطبيق مختبر. جميع الأمثلة هي بيانات مختبر أو وصف عمليات. عندما يتعلق الأمر باختبار الاختراق (Penetration Testing) أو الويب أو السحابة، يجب العمل فقط بإذن صريح، نطاق محدد وقدرة على إيقاف الاختبار.

كيف ينشأ XSS

موضوع 'كيف ينشأ XSS' هو جزء أساسي من العمل على اختبار XSS. يوصى بتقسيمه إلى ثلاثة أسئلة: ما هو الإدخال، ما هو القرار الذي نريد اتخاذه، وما هو الدليل الكافي لتبريره. تمنع هذه الأسئلة الاستخدام التلقائي للأداة دون فهم الهدف.

في التدريب، سجل الـ context، encoding، CSP، stored/reflected/DOM، sanitization، قارن بالسلوك المتوقع وحدد Pivot واحدًا على الأقل. يجب أن تكون النتيجة قابلة للفحص من قبل محلل إضافي، بما في ذلك القيود والخطوات التالية.

Reflected و Stored

موضوع 'Reflected و Stored' هو جزء أساسي من العمل على اختبار XSS. يوصى بتقسيمه إلى ثلاثة أسئلة: ما هو الإدخال، ما هو القرار الذي نريد اتخاذه، وما هو الدليل الكافي لتبريره. تمنع هذه الأسئلة الاستخدام التلقائي للأداة دون فهم الهدف.

في التدريب، سجل الـ context، encoding، CSP، stored/reflected/DOM، sanitization، قارن بالسلوك المتوقع وحدد Pivot واحدًا على الأقل. يجب أن تكون النتيجة قابلة للفحص من قبل محلل إضافي، بما في ذلك القيود والخطوات التالية.

DOM-based XSS

موضوع 'DOM-based XSS' هو جزء أساسي من العمل على اختبار XSS. يوصى بتقسيمه إلى ثلاثة أسئلة: ما هو الإدخال، ما هو القرار الذي نريد اتخاذه، وما هو الدليل الكافي لتبريره. تمنع هذه الأسئلة الاستخدام التلقائي للأداة دون فهم الهدف.

في التدريب، سجل الـ context، encoding، CSP، stored/reflected/DOM، sanitization، قارن بالسلوك المتوقع وحدد Pivot واحدًا على الأقل. يجب أن تكون النتيجة قابلة للفحص من قبل محلل إضافي، بما في ذلك القيود والخطوات التالية.

Context و Encoding

موضوع 'Context و Encoding' هو جزء أساسي من العمل على اختبار XSS. يوصى بتقسيمه إلى ثلاثة أسئلة: ما هو الإدخال، ما هو القرار الذي نريد اتخاذه، وما هو الدليل الكافي لتبريره. تمنع هذه الأسئلة الاستخدام التلقائي للأداة دون فهم الهدف.

في التدريب، سجل الـ context، encoding، CSP، stored/reflected/DOM، sanitization، قارن بالسلوك المتوقع وحدد Pivot واحدًا على الأقل. يجب أن تكون النتيجة قابلة للفحص من قبل محلل إضافي، بما في ذلك القيود والخطوات التالية.

CSP، العلاج وإعادة الاختبار

يبدأ الاختبار الاحترافي لـ XSS بشروط النجاح وشروط الفشل. يتم تعريف حالة إيجابية، حالة سلبية، حالة حدية ونشاط شرعي مماثل. وبهذه الطريقة يمكن تحديد كل من False Negative و False Positive.

في بيئة مرخصة، يتم استخدام إجراء بسيط يثبت الادعاء دون التسبب في ضرر. يتم حفظ الإدخال، الإخراج، الوقت والإصدار، وبعد الإصلاح يتم إجراء Retest في نفس السيناريو ويتم فحص Regression أيضًا على الوظائف المجاورة.

نقاط اختبار فريدة

في هذا الموضوع، يوصى ببناء خريطة أدلة مركزة مسبقًا. نقاط الاختبار الرئيسية هي: context، encoding، CSP، stored/reflected/DOM، sanitization، sink/source. القائمة ليست قائمة تحقق تلقائية؛ تم اختيار كل عنصر لأنه يمكن أن يربط بين كيان، فعل ووقت أو يشرح سلوكًا شرعيًا.

  • context: حدد القيمة المتوقعة، وما الذي سيعتبر غير عادي، وما هو المصدر الإضافي الذي سيؤكد النتيجة.
  • encoding: حدد القيمة المتوقعة، وما الذي سيعتبر غير عادي، وما هو المصدر الإضافي الذي سيؤكد النتيجة.
  • CSP: حدد القيمة المتوقعة، وما الذي سيعتبر غير عادي، وما هو المصدر الإضافي الذي سيؤكد النتيجة.
  • stored/reflected/DOM: حدد القيمة المتوقعة، وما الذي سيعتبر غير عادي، وما هو المصدر الإضافي الذي سيؤكد النتيجة.
  • sanitization: حدد القيمة المتوقعة، وما الذي سيعتبر غير عادي، وما هو المصدر الإضافي الذي سيؤكد النتيجة.
  • sink/source: حدد القيمة المتوقعة، وما الذي سيعتبر غير عادي، وما هو المصدر الإضافي الذي سيؤكد النتيجة.

عندما لا يكون أحد النقاط متاحًا، يجب توثيق الفجوة واختيار بديل. على سبيل المثال، إذا كان Process identifier غير مستقر، يمكن الاستعانة بالوقت، Host، User و Parent؛ إذا كان Payload مشفرًا، يتم استخدام Metadata، الحجم، التردد و TLS/DNS context.

عملية عمل موصى بها

  1. حدد Scope وسؤال عمل واحد حول اختبار XSS.
  2. سجل مصادر البيانات والأدلة المطلوبة: context، encoding، CSP، stored/reflected/DOM.
  3. أنشئ خط أساس قصير لسلوك سليم أو نتيجة متوقعة.
  4. قم بإجراء الاختبار الأدنى في بيئة المختبر واحفظ الوقت، الإدخال والإخراج.
  5. أنشئ جدولًا زمنيًا أو جدول مقارنة وافصل بين الحقيقة والتفسير.
  6. قم بإجراء Pivot إلى مصدر إضافي لتأكيد أو دحض التفسير الأولي.
  7. لخص القرار، القيود، الإجراء الموصى به ومعيار Retest.

سيناريو عملي

السيناريو المختار هو رسم خرائط Input-to-Sink في تطبيق مختبر. الهدف من التمرين ليس إثبات القدرة على الهجوم، بل ممارسة الجمع، المقارنة والتوثيق بطريقة آمنة. قبل بدء العمل، يتم تحديد بيانات وهمية، نافذة زمنية ونتيجة متوقعة.

في نهاية التمرين، يجب تقديم منتج يمكن لمحلل أو مختبر آخر مراجعته: صورة أو تصدير للدليل، جدول زمني قصير، افتراض أولي، دليل تأكيد، قيود وتوصية. عندما لا يكون هناك دليل كافٍ، فإن الاستنتاج الصحيح هو أن السيناريو لم يثبت.

المرحلةما يتم تنفيذهالمنتج
التحضيرحدد Scope، الوقت والهدف. سجل الحقول أو الأدلة المتوقعة من context، encoding، CSP.خطة اختبار قصيرة
إنشاء البياناتنفذ إجراءً آمنًا ومحاكيًا يتعلق باختبار XSS، بدون معلومات حقيقية أو تأثير على نظام الإنتاج.حدث/طلب/تدفق متحكم به
الجمعاجمع الدليل الخام والسياق من مصدر إضافي. تأكد من Time zone، المعرفات وسلامة البيانات.دليلان مرتبطان
التحليلاكتب ما يثبته كل دليل، وما لا يثبته، وما هو التفسير المشروع المحتمل.استنتاج وسيط
الانتهاءاختر إغلاقًا، تصعيدًا، Finding أو Tuning؛ أضف توصية و Retest.منتج موثق

قائمة تحقق عملية

  • تحقق ووثّق: Role و session.
  • تحقق ووثّق: Endpoint و method.
  • تحقق ووثّق: Request/Response.
  • تحقق ووثّق: Object identifier.
  • تحقق ووثّق: Server-side effect.
  • تحقق ووثّق: Control expected و remediation.
  • اذكر Time zone، إصدار الأداة ووقت التجميع.
  • احفظ البيانات الخام قبل التصفية أو التغيير.
  • اكتب ما تثبته النتيجة وما لا يزال مجهولاً.
  • حدد المالك والإجراء التالي مع تحديد موعد.

أخطاء شائعة

  • التحقق فقط من Status code.
  • الاعتماد على تغيير من جانب العميل (Client-side).
  • استخدام Payload خطير.
  • عدم التحقق من أدوار مختلفة (Roles).
  • تجاهل منطق العمل.
  • التبليغ بدون Request/Response نظيف.

تعميق مهني: الجودة، السياق والتحكم

يُقاس العمل الجيد في مجال اختبار XSS أيضًا بالقدرة على إعادة بناء الطريق إلى الاستنتاج. يُوصى بحفظ Query، Filter، Scope، Timestamp، Dataset وإصدار الأداة. بهذه الطريقة يمكن إعادة فحص نفس الحالة بعد تغيير التكوين أو بعد الحصول على معلومات إضافية.

يغير السياق التجاري المعنى التقني. الأصول الحساسة، الحسابات ذات الصلاحيات أو الخدمات التي تواجه الإنترنت تتطلب مستوى مختلفًا من الحذر عن مختبر معزول. ومع ذلك، فإن Criticality ليست بديلاً للأدلة: فهي تؤثر على Priority وعلى إجراءات الاستجابة، وليس على ما إذا كان السلوك قد حدث بالفعل.

مراجعة الأقران هي وسيلة فعالة لتقليل الأخطاء. يجب أن يتلقى محلل إضافي الوثائق فقط وأن يكون قادرًا على فهم السؤال، إعادة إنتاج البحث والوصول إلى نفس الاستنتاج. إذا احتاج إلى تفسيرات شفوية، فإن الوثائق لا تزال غير مكتملة.

أخيرًا، يجب أن يصبح كل منتج فرصة للتحسين: مصدر سجل مفقود، Playbook غير واضح، Rule مزعج، صلاحية واسعة أو تعليمات اختبار غير دقيقة. توثيق الإجراء و Retest هما ما يربط بين التحقيق لمرة واحدة والتحسين المستمر لقدرة المنظمة.

ملخص و CTA

Cross-Site Scripting: المخزن، المنعكس و DOM هو موضوع يربط المعرفة التقنية بالانضباط في العمل. ابدأ بسؤال، اجمع فقط الأدلة ذات الصلة، احتفظ بالسياق والوقت، واختر إجراءً يمكن تبريره وإعادة فحصه.

في مسار Cybersecurity & AI في HPI، يتم ممارسة هذه المبادئ من خلال الأنظمة، السجلات والمختبرات. الخطوة الطبيعية التالية هي الانتقال إلى المقالات المرتبطة، إجراء تمرين المختبر وحفظ المنتج كجزء من محفظة مهنية.

الأسئلة الشائعة

هل يُسمح باختبار XSS على موقع عام؟

لا، ليس بدون إذن صريح من مالك النظام. حتى الاختبار الذي يبدو سهلاً قد يغير البيانات، يشغل آليات الحماية أو يعتبر وصولاً غير مصرح به.

ماذا نفعل عندما تكون بعض البيانات مفقودة؟

نوثّق النقص، نتحقق من مصدر بديل ونقلل من مستوى الثقة. لا يجب إكمال الحقول بالتخمين أو عرض Unknown كصحيح.

كم من الوقت يجب الاحتفاظ بالأدلة؟

يعتمد الوقت على السياسة، التنظيم، التكلفة ونوع الحدث. من المهم تحديد Retention، Legal hold والقدرة على تصدير الأدلة بتنسيق يمكن التحقق منه مسبقًا.

كيف نتدرب دون تعريض نظام حقيقي للخطر؟

نستخدم آلات افتراضية، بيانات وهمية، CTF أو مختبرًا مخصصًا. في الاختبارات المرخصة، نحدد Scope، Stop conditions ونسخة احتياطية قبل بدء العمل.

هل تريد التحقق مما إذا كان هذا المسار يناسبك؟

اترك تفاصيلك وسيتصل بك مستشار من HPI لإجراء مكالمة قصيرة لتقييم الملاءمة، دون أي التزام.

يتم تخزين بياناتك بأمان.

لدراسة SOC والأمن السيبراني ضمن برنامج Cybersecurity & AI

هل ترغب في تفاصيل البرنامج؟ اترك بياناتك وسنتواصل معك.

مقالات ذات صلة