البرمجة النصية عبر المواقع (XSS) هي هجوم إلكتروني يقوم فيه أحد المتطفلين بإدخال تعليمات برمجية ضارة في نموذج ويب أو عنوان url لتطبيق ويب. يمكن لهذه الشفرة الضارة ، المكتوبة بلغة برمجة نصية مثل JavaScript أو PHP ، أن تفعل أي شيء من تدمير الصفحة التي تحاول تحميلها إلى سرقة كلمات المرور الخاصة بك أو بيانات اعتماد تسجيل الدخول الأخرى.

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

تحقق أيضًا من:

كيف يعمل هجوم XSS

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

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

هذا الوصف ليس خاطئًا ، لكن بعض الجوانب قديمة (وهي موجودة منذ أكثر من عشر سنوات). أولاً ، العديد من صفحات الويب ، إن لم يكن كلها ، ديناميكية اليوم – أي أنها لا تعرض نفس HTML الثابت لكل زائر ، بل يتم إنشاؤها على الفور من المعلومات الموجودة في قاعدة بيانات الخادم عندما يطلب المستعرض الوصول. غالبًا ما تعتمد الصفحة التي يتلقاها المتصفح من الخادم على المعلومات المرسلة مع الطلب – المعلومات التي تتخذ أحيانًا شكل المعلمات في عنوان URL المستخدم للوصول إلى الموقع. لا تتكون مواقع الويب فقط من HTML و Cascading Style Sheets (CSS) التي تصف كيفية عرض النص والرسومات ، ولكنها تحتوي أيضًا على تعليمات برمجية قابلة للتنفيذ مكتوبة بلغات البرمجة النصية ، وعادةً ما تكون JavaScript.

في هجوم XSS ، يستخدم المتسلل هذا التفاعل بين المستخدم والموقع الإلكتروني لتنفيذ تعليمات برمجية ضارة على كمبيوتر المستخدم. ولكن كيف؟ ضع في اعتبارك عنوان URL التالي:

https://www.google.com/search?q=CSO+online

أدخل هذا في شريط العنوان في متصفحك وسترى نتائج بحث Google عن “CSO Online”. في الواقع ، تبدو الصفحة التي ستراها مماثلة تمامًا كما لو قمت بإدخال “CSO Online” في شريط البحث في متصفحك أو في صفحة Google الرئيسية. ستلاحظ ، من بين أشياء أخرى ، أن هذه العبارة تظهر في عدة أماكن في الصفحة ، بما في ذلك شريط البحث في الجبال:

ماذا لو ، بدلاً من عبارة “CSO online” البريئة والناجحة ، احتوى عنوان URL هذا على شفرة JavaScript ضارة مثل هذه؟

https://www.google.com/search?<script>doEvil()</script>

doEvil () يقوم بوظيفة سيئة حقًا هنا. قد تشعر بالقلق من أن Google ، بدلاً من عرض “CSO Online” على الصفحة التي تعيدها من عنوان url هذا ، ستقوم بدلاً من ذلك بدمج جافا سكريبت السيئ في الصفحة التي تعرضها ديناميكيًا ، وأن هذا البرنامج النصي يتم تنفيذه في متصفحك ، مما يتسبب في فوضى. ستكون مخاوفك بلا أساس ، لأن Google لديها عدد كبير جدًا من المتخصصين الموهوبين في مجال أمن تكنولوجيا المعلومات بين موظفيها وقد نفذت إجراءات علاجية سنتحدث عنها بعد قليل. ومع ذلك ، ليس كل موقع حريصًا جدًا وهذا يمنحك فكرة عن كيفية عمل مثل هذه الهجمات.

أتاكي XSS

تنقسم هجمات XSS إلى عدة فئات: الهجمات المنعكسة ، والهجمات المستندة إلى DOM ، والهجمات المخزنة. إليك كيف تختلف:

• الهجمات المنعكسة: المعروفة أيضًا باسم الهجمات الضعيفة ، يتم إرسال شفرة جافا سكريبت الضارة من متصفح الضحية إلى Google ، ثم تنعكس مرة أخرى في شكل قابل للتنفيذ ، ولا يتم تخزينها نهائيًا على خوادم Google. غالبًا ما تكون هذه الهجمات جزءًا من عملية احتيال تصيد ، حيث يتم إخفاء الرابط الضار على أنه شيء أكثر إمتاعًا ويتم إرساله إلى الضحية عبر البريد الإلكتروني أو الرسائل القصيرة.
• الهجمات المستندة إلى DOM: هذا هو نوع من الهجوم المنعكس المسمى باسم Document Object Model ، وهو واجهة برمجة تطبيقات معيارية تحدد كيفية إنشاء المتصفحات لصفحة ويب من التعليمات البرمجية الأساسية لـ HTML أو JavaScript. تتشابه معظم هجمات DOM مع الهجوم المنعكس الموصوف سابقًا ، مع اختلاف عدم إرسال الشفرة الضارة أبدًا إلى الخادم: بدلاً من ذلك يتم تمريرها كمعامل لبعض وظائف JavaScript التي يتم تنفيذها في المتصفح نفسه ، مما يعني أن الآليات تحمي على جانب الخادم غير قادرة على حماية المستخدم. إذا كنت مهتمًا بالتفاصيل ، فإن PortSwigger لديه وصف أكثر تفصيلاً لكيفية عمل هجمات DOM.
• الهجمات المخزنة: بخلاف ذلك تكون مستمرة ؛ يستخدم المهاجم الميزات التفاعلية لموقع الويب لحفظ التعليمات البرمجية الضارة على خادم الويب. في مثال نموذجي ، يترك المهاجم تعليقًا على منشور مدونة يحتوي على JavaScript ضار. في المرة التالية التي يقوم فيها شخص ما بتحميل هذه الصفحة ، سيتم تنفيذ الكود.
• قابلية التعرض لهجوم XSS

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

والمخاطر كبيرة. الجانب الرئيسي لأمان المتصفح هو ما يسمى ب سياسة نفس الأصل ، والتي تنص على أن البرنامج النصي الذي يتم تنفيذه على صفحة واحدة يمكنه الوصول إلى البيانات الموجودة على الصفحة الأخرى فقط إذا كان لكلا الجانبين نفس الأصل (يُعرّف على أنه مجموعة من مخطط URI واسم المضيف ورقم المنفذ). ومع ذلك ، إذا كان من الممكن تشغيل JavaScript ضار في المتصفح أثناء وصول الضحية إلى موقع الويب ، فسيسمح المتصفح لجافا سكريبت بالوصول إلى البيانات من مواقع الويب الأخرى التي تشارك مصدرًا مع موقع الويب الضعيف. يمكن لـ JavaScript الوصول إلى ملفات تعريف الارتباط ومعلومات جلسة الملكية الأخرى ، وهي وصفة جيدة لاختراق حسابات الإنترنت الخاصة بالضحية.

الحمولات XSS

في لغة البرمجيات الخبيثة ، الحمولة هي رمز قابل للتنفيذ ينفذ الإجراءات المطلوبة من قبل المهاجم. في حالة هجوم XSS ، فإن الحمولة عبارة عن رمز نصي يديره المهاجم لخداع متصفح الضحية ليتم تنفيذه.

توجد قائمة ضخمة من نماذج حمولات XSS في مستودع Payloadbox على GitHub. إذا كنت معتادًا على JavaScript ، فقد تعطيك مراجعتها فكرة عن كيفية قيام مهاجمي XSS بعملهم القذر. ومع ذلك ، فإن هجوم XSS يتجاوز قطع الحمولة ولصقها في عنوان URL: يحتاج المهاجم إلى فهم الوظائف المحددة ونقاط الضعف لتطبيق الويب الذي يريد استغلاله للتخطيط للهجوم. إذا كنت تريد التعمق أكثر ورؤية بعض الأمثلة على هجمات XSS ، فراجع موقع OWASP XSS على الويب للحصول على نظرة متعمقة على كود البرنامج النصي الذي يوضح هجوم XSS.

حماية XSS والوقاية

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

• تعقيم بيانات الإدخال. إن الإجابة الواضحة لمنع تمرير الشفرة البرمجية الخبيثة كمدخلات ورجوعها إلى المستخدم هي ببساطة عدم قبول كود البرنامج النصي كإدخال. يجب عليك بالتأكيد تصفية مدخلاتك مع وضع ذلك في الاعتبار ، لكن قول ذلك أسهل من فعله ؛ يمكن أن تتسلل أجزاء صغيرة من التعليمات البرمجية القابلة للتنفيذ من خلال المرشحات. تتمثل إحدى طرق التعامل مع هذه المشكلة في استخدام القائمة البيضاء بدلاً من نهج القائمة السوداء – على سبيل المثال ، بدلاً من محاولة كتابة عامل تصفية يحظر جميع التعليمات البرمجية الضارة التي يتم إدخالها في نموذج ويب ، يجب عليك كتابة التطبيق الخاص بك لقبول البيانات في أوقات معينة التنسيقات (أرقام الهواتف وعناوين البريد الإلكتروني وما إلى ذلك) فقط عندما يكون هذا هو ما تريده.
• الهروب من الإخراج. هذا هو حل المشكلة من ناحية أخرى. إذا أرسل تطبيق ويب إدخال المستخدم مرة أخرى إلى صفحة ويب ، فيجب تصفية هذه البيانات للتأكد من أنها لن تصبح قابلة للتنفيذ في تلك الصفحة. إذا قام المستخدم بإدخال علامات HTML كمدخلات ، فيجب أن يستخدم التطبيق أحرف تم تجاوزها بحيث تظهر هذه العلامات كنص في صفحة النتائج بدلاً من التكامل مع HTML للصفحة نفسها.
• سياسة أمان المحتوى القياسية (CSP). يأخذ CSP نهج “القائمة البيضاء” خارج إدخال النص إلى مجال البرمجة النصية: يجب على تطبيق الويب فقط تنفيذ التعليمات البرمجية التي حددها المستخدم لتكون آمنة. تمتلك Google بعض الموارد الرائعة حول تنفيذ CSP.

اختبار XSS

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

XSS و CSRF

قد تسمع أن CSRF يُستخدم في نفس سياق XSS. إنه اختصار لتزوير الطلب عبر المواقع ، أي هجوم – مثل XSS – يستهدف متصفح المستخدم. يتمثل الاختلاف الرئيسي في أن CSRF يستخدم جلسة مصدق عليها للمستخدم (ربما قام بتسجيل الدخول إلى حسابه المصرفي) بينما لا يحتاج XSS إلى جلسة مصدق عليها حتى تكون فعالة.

لنفترض أن مستخدمًا قد سجّل الدخول إلى Twitter وبنك إنترنت في نفس الوقت ، ونقر على رابط Twitter يشبه هذا:

http://www.yourbank.com/sendmoney,do?from=you&to=attacker&amount=5000

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

هجمات XSS الأخيرة وسيئة السمعة

حدثت واحدة من أقدم وأشهر هجمات البرمجة النصية عبر المواقع في عام 2005 ، عندما أدرك مستخدم MySpace المغامر سامي كامكار أنه يمكنه إدخال كود JavaScript في ملفه الشخصي الذي من شأنه أن يصادق تلقائيًا أي شخص يزور الموقع – وأيضًا نسخ هذا الرمز للملفات الشخصية من أصدقائك الجدد ، وبفضل ذلك سيكون كل من يزور هذه الصفحات صديقًا له أيضًا. (تأكد النص من أن كل من أصدقاء كامكار الجدد جعلوه في “الثمانية الأوائل” – نخشى أنه لفهم ذلك ، يجب أن تكون هناك ، لكن صدقنا ، كان أمرًا مهمًا). في غضون 24 ساعة ، قام بتكوين أكثر من مليون صديق وأجبر موقع MySpace على إغلاق الموقع بأكمله لفترة قصيرة.

تبين أن ما يسمى بدودة سامي غير ضارة في الغالب. ومع ذلك ، كان البعض الآخر أكثر إزعاجًا:

• كان لدى Ebay ثغرات XSS لسنوات سمحت للقراصنة بسرقة بيانات اعتماد تسجيل دخول المستخدم

• تمكن مهاجمو XSS من سرقة نقود V-Bucks من لاعبي Fortnite في عام 2019.

• هاجمت مجموعة Magecart للقرصنة الخطوط الجوية البريطانية في 2018 بهجوم XSS ، وسرقت مئات الآلاف من هويات المستخدمين

ولا تزال البرمجة النصية عبر المواقع نفسها تشكل تهديدًا خطيرًا اليوم. اعتبارًا من عام 2021 ، تم العثور على ثغرات XSS في منصة البريد الإلكتروني Zimbra و Wordpress ومنصة Nagios مفتوحة المصدر لإدارة تكنولوجيا المعلومات. ضع في اعتبارك أن المتسللين عادةً لا يستخدمون تقنيات الهجوم بمعزل عن غيرها: البرمجة النصية عبر المواقع هي أحد مكونات شكل معقد تم اكتشافه مؤخرًا من هجوم TLS wildcard المعروف باسم ALPACA. لتجنب التهديدات الخطيرة ، تأكد من إغلاق ثغرات XSS.

المصدر: CSO