عبر الموقع XSS البرمجة النصية. باستخدام نقاط الضعف XSS إلى الحد الأقصى. إزالة الرمز الخاص بك
وهو كتاب مدرسي شامل على البرمجة النصية عبر الموقع.
الجزء الأول: نظرة عامة
ما هو XSS؟
البرمجة النصية المتقدمة ( الإنجليزية عبر موقع البرمجة) - هذا هجوم يهدف إلى تنفيذ رمز يسمح للمهاجم بأداء JavaScript الضارة في متصفح مستخدم آخر.
المهاجم لا يهاجم تضحيه مباشرة. بدلا من ذلك، يستخدم مشكلة عدم حصانة موقع الويب يزور الضحية وينفذ رمز جافا سكريبت ضار. في متصفح الضحية، يتم عرض JavaScript الضارة كجزء مشروع من موقع الويب، والموقع نفسه بمثابة شريك مهاجم مباشر.
تنفيذ رمز جافا سكريبت ضار
الطريقة الوحيدة لمهاجمة إطلاق جافا سكريبت ضار في متصفح الضحايا هي تقديمها إلى واحدة من الصفحات التي يتم فيها تنزيل الضحية من الموقع. هذا ممكن إذا كان الموقع يسمح للمستخدمين بإدخال البيانات على صفحاتهم، وسيتمكن المهاجم من إدراج سلسلة يتم تحديدها كجزء من التعليمات البرمجية في متصفح الضحية.
يظهر المثال أدناه برنامج نصي خادم بسيط يستخدم لعرض آخر تعليق على الموقع:
مطبعة " "
مطبعة "آخر تعليق:"
طباعة قاعدة البيانات
مطبعة ""
يفترض البرنامج النصي أن التعليق يتكون فقط من النص. ومع ذلك، منذ فوري مدخلات مخصصةالمهاجم يمكن أن يترك هذا التعليق: "". أي مستخدم يقوم بزيارة الصفحة سيتلقى الآن الإجابة التالية:
آخر تعليق:
عندما يقوم مستعرض المستخدم بتحميل الصفحة، سيؤدي ذلك إلى أداء كل شيء، بما في ذلك رمز JavaScript الموجود داخل العلامات وبعد يشير ذلك إلى أن الوجود البسيط للسيناريو الذي ينفذه المهاجم يمثل مشكلة، بغض النظر عن رمز البرنامج النصي معين يتم تنفيذه بالفعل.
الجزء الثاني: هجوم XSS
XSS الهجوم المشاركين
قبل وصف كيفية وصف بالتفصيل كيف يعمل هجوم XSS، نحتاج إلى تحديد مواضيع هجوم XSS. بشكل عام، في هجوم XSS هناك ثلاثة مشاركين: موقع إلكتروني, ضحية، أنا. لص.
- موقع إلكتروني يعطي صفحات HTML للمستخدمين الذين طلبتهم. في أمثلةنا، يقع على موقع http: // الموقع /.
- قاعدة بيانات الموقع إنها قاعدة بيانات تقوم بتخزين بعض البيانات التي أدخلها المستخدمون على صفحات الموقع.
- ضحية - هذا هو المستخدم العادي الموقع الذي يطلب الصفحات مع متصفحه.
- مهاجمة - هذا مهاجم يعتزم بدء هجوم على الضحية من خلال استخدام مشكلة عدم حصانة XSS على الموقع.
- خادم اللص - هذا خادم ويب تحت سيطرة المهاجم مع الغرض الوحيد - سرقة معلومات الضحية السرية. في أمثلةنا، يقع على HTTP: // المهاجم /.
مثال هجوم سيناريو
سيقوم هذا البرنامج النصي بإنشاء طلب HTTP إلى عنوان URL آخر، مما سيعيد توجيه متصفح المستخدم إلى خادم المهاجم. يتضمن عنوان URL ملفات تعريف الارتباط للضحية كمعلمة استعلام عندما يأتي طلب HTTP إلى خادم المهاجم، يمكن للمهاجم استخراج ملفات تعريف الارتباط هذه من الطلب. بعد تلقي المهاجم ملفات تعريف الارتباط، يمكنه استخدامها لإعطاء نفسه للتضحية وبدء هجوم لاحق.
من هذه النقطة على رمز HTML الموضح أعلاه سيتم استدعاء سلسلة ضارة أو سيناريو ضاروبعد من المهم أن نفهم أن السلسلة نفسها خبيثة فقط إذا تم معالجة رمز HTML في نهاية المطاف في متصفح الضحية، وقد يحدث هذا فقط في حالة توفر مشكلة عدم حصانة XSS على الموقع الإلكتروني.
كيف يعمل هذا المثال
يوضح المخطط أدناه مثالا على هجوم من قبل المهاجم:
- يستخدم المهاجم أحد أشكال الموقع من أجل إدراج سلسلة ضارة إلى قاعدة بيانات الويب.
- الضحية يسأل الصفحة من الموقع.
- يتضمن الموقع سلسلة ضارة من قاعدة البيانات استجابة ويرسلها إلى الضحية.
- يقوم متصفح الضحايا بإجراء سيناريو ضار ضمن الإجابة، وإرسال الضحايا إلى خادم المهاجم.
أنواع XSS.
الغرض من هجوم XSS يرجع دائما إلى ضارة جافا سكريبت سيناريو في متصفح الضحية. هناك العديد من الطرق المختلفة بشكل أساسي لتحقيق هذا الهدف. غالبا ما يتم تقسيم هجمات XSS إلى ثلاثة أنواع:
- تخزين (دائم) XSSحيث تنشأ السلسلة الضارة من قاعدة بيانات الموقع.
- تعكس (غير دائم) XSSحيث يتم إنشاء سلسلة ضارة من طلب الضحية.
- XSS نماذج دومحيث تحدث الثغرة الأمنية في التعليمات البرمجية على جانب العميل، وليس على جانب رمز الخادم.
في المثال السابق، يظهر هجوم XSS المخزن. الآن وصفنا نوعين آخرين من هجمات XSS: عكس XSS ونماذج DOM الهجوم XSS.
تعكس XSS.
في حالة هجوم XSS المنعكس، تعد سلسلة ضارة جزءا من طلب الضحية إلى موقع الويب. يتلقى الموقع وإدراج هذه السلسلة الضارة إلى المستخدم المرسلة إلى المستخدم. يوضح المخطط أدناه هذا البرنامج النصي:
- الضحية ترسل احتيالي طلب URL إلى الموقع الإلكتروني.
- يتضمن الموقع سلسلة ضارة من استعلام URL استجابة للضحية.
- يقوم متصفح الضحية بإجراء سيناريو خبيث يحتوي على الإجابة، وإرسال الضحايا إلى الخادم المتسللين.
كيفية القيام بنجاح هجوم XSS المنعكس؟
قد يبدو هجوم XSS المنعكس غير ضار، لأنه يتطلب الضحية من اسمه لإرسال طلب يحتوي على سلسلة ضارة. نظرا لأنه لن يهاجم أحد طوعا نفسه، إلا أنه يبدو أنه لا توجد وسيلة للتنفيذ الفعلي للهجوم.
كما اتضح، هناك طريقتان مشتركان على الأقل لجعل التضحية لبدء هجوم XSS ينعكس ضد نفسه:
- إذا كان المستخدم شخصية محددة، فيمكن للمهاجم إرسال عنوان URL ضاريا للضحية (على سبيل المثال، باستخدام البريد الإلكتروني أو الرسائل)، وخداع لإجباره على فتح رابط لزيارة الموقع الإلكتروني.
- إذا كان الهدف هو مجموعة كبيرة من المستخدمين، فيمكن للمهاجم نشر رابط لعنوان URL الضار (على سبيل المثال، على موقع الويب الخاص به أو في شبكة اجتماعية) وانتظر الزوار الذين سوف يذهبون على الرابط.
كل من هذه الأساليب متشابهة، وقد يكون كلاهما أكثر نجاحا باستخدام الخدمات "تقصير" عنوان URL، فهم يخفي السلسلة الخبيثة من المستخدمين الذين يمكنهم تحديدها.
XSS في نموذج دوم
XSS في نموذج DOM هو خيار كهجوم XSS المخزن ويعكس. في هجوم XSS هذا، لا تتم معالجة السلسلة الضارة من قبل متصفح الضحية، حتى يتم تنفيذ JavaScript الحقيقي للموقع. يوضح المخطط أدناه هذا البرنامج النصي لهجمات XSS المنعكس:
- يقوم المهاجم بإنشاء عنوان URL الذي يحتوي على سلسلة ضارة ويرسله إلى الضحية.
- الضحية ترسل احتيالي طلب URL إلى الموقع الإلكتروني.
- يتلقى الموقع طلبا، لكنه لا يشمل سلسلة ضارة استجابة.
- يقوم متصفح الضحية بإجراء سيناريو مشروع موجود في الإجابة، مما أدى إلى سيناريو ضار سيتم إدراجها في الصفحة.
- يقوم متصفح الضحية بإجراء برنامج نصي ضار مدرج في الصفحة، وإرسال ملفات تعريف الارتباط الضحية إلى الخادم المتسلل.
ما هو الفرق بين XSS في نموذج دوم؟
في الأمثلة السابقة من هجمات XSS المخزنة والمكسورة، يقوم الخادم بإدراج برنامج نصي ضار إلى الصفحة، والتي يتم إرسالها بعد ذلك استجابة للضحية. عندما تلقى متصفح الضحية إجابة، يفترض أن البرنامج النصي الضار هو جزء من المحتوى الشرعي للصفحة، ويتم تشغيله تلقائيا أثناء تحميل الصفحة، بالإضافة إلى أي سيناريو آخر.
في مثال هجمات XSS في طراز DOM، لا يتم إدراج البرنامج النصي الخبيث كجزء من الصفحة؛ البرنامج النصي الوحيد الذي يتم تنفيذه تلقائيا أثناء تحميل الصفحة هو جزء مشروع من الصفحة. المشكلة هي أن هذا السيناريو الشرعي يستخدم مباشرة إدخال المستخدم من أجل إضافة HTML إلى الصفحة. نظرا لأن السلسلة الضارة مدرجة في الصفحة باستخدام Innerhtml، يتم تحليلها كأملاء HTML، ونتيجة لذلك سيتم تنفيذ البرنامج النصي الضار.
هذا التمييز صغير، ولكنه مهم للغاية:
- في XSS التقليدية، يتم تنفيذ JavaScript الضارة عند تحميل الصفحة، كجزء من HTML المرسل بواسطة الخادم.
- في حالة XSS في نموذج DOM، يتم إجراء JavaScript الضارة بعد تحميل الصفحة، نتيجة لذلك، تتم الإشارة إلى هذه الصفحة مع جافا سكريبت شرعية كوسيلة غير آمنة لإدخال المستخدم (تحتوي على سلسلة ضارة).
كيف يعمل XSS في نموذج DOM؟
في المثال السابق، ليست هناك حاجة لجافا سكريبت؛ يمكن للخادم إنشاء كل HTML بحد ذاته. إذا كان الرمز الموجود على جانب الخادم لا يحتوي على ثغرات نقاط الضعف، فلن يخضع الموقع لمكثير نقاط XSS.
ومع ذلك، نظرا لأن تطبيقات الويب أصبحت أكثر تقدما، يتم إنشاء كمية متزايدة من صفحات HTML باستخدام JavaScript على جانب العميل، وليس على الخادم. في أي وقت، يجب أن يتغير المحتوى دون تحديث الصفحة بأكملها، فمن الممكن باستخدام JavaScript. على وجه الخصوص، هذا هو الحال عند تحديث الصفحة بعد استعلام AJAX.
هذا يعني أن نقاط الضعف XSS قد تكون موجودة ليس فقط في جزء الخادم من رمز موقعك، ولكن أيضا على جانب رمز JavaScript الخاص بعميل موقعك. وبالتالي، حتى مع وجود رمز آمن بالكامل على جانب الخادم، لا يزال بإمكان رمز العميل ممكنا بأمان لإدخال بيانات المستخدم عند تحديث الدوم بعد تنزيل الصفحة. إذا حدث هذا، فإن الرمز من العميل سيسمح لهجوم XSS ليس خطأ الكود من جانب الخادم.
XSS بناء على نموذج DOM يمكن أن يكون غير مرئي للخادم
هناك حالة خاصة لهجمات XSS في نموذج DOM حيث لا يتم إرسال سلسلة ضارة إلى خادم موقع الويب: يحدث هذا عندما يتم احتواء السلسلة الخبيثة في جزء معرف URL (شيء ما بعد الرمز #). لا ترسل المتصفحات هذا الجزء من عنوان URL إلى الخادم، لذلك لا يحتوي الموقع على الوصول إليه باستخدام الرمز الموجود على جانب الخادم. ومع ذلك، فإن الرمز من العميل لديه حق الوصول إليه، وبالتالي فمن الممكن إجراء هجوم XSS من خلال معالجة غير آمنة.
هذه القضية لا تقتصر على معرف الشظايا. يوجد أيضا إدخال مستخدم آخر غير مرئي للخادم، على سبيل المثال، وظائف HTML5 الجديدة، مثل Localstorage و Indexeddd.
الجزء الثالث:
XSS الوقاية
أساليب الوقاية من XSS
أذكر أن XSS هو هجوم من نوع نشر التعليمات البرمجية: يتم تفسير المستخدم الذي أدخله المستخدم عن طريق الخطأ كتعويض برنامج برنامج ضار. من أجل منع هذا النوع من الحقن الرمز، يلزم معالجة الإدخال الآمنة. لمطور الويب، هناك اثنان من الأساسي أساليب مختلفة إجراء معالجة الإدخال الآمنة:
- ترميز - هذه هي الطريقة التي تتيح لك إدخال البيانات من قبل المستخدم فقط كبيانات ولا تسمح بمعالجة المتصفح كصفوفة.
- تصديق - تقوم هذه الطريقة بمرشحات المستخدم إدخال المستخدم بحيث يفسر المستعرض كصنونة بدون أوامر ضارة.
على الرغم من أن هذه طرق مختلفة بشكل أساسي لمنع XSS، فإن لديهم عدة سمات عامة مهمة لفهمها عند استخدام أي منها:
يجب أن يتم معالجة معالجة الإدخال الآمن السياق بشكل مختلف حسب المكان الذي يتم فيه استخدام إدخال المستخدم في الصفحة. يمكن إجراء معالجة الإدخال الآمنة الواردة / المنتهية ولايتها إما عندما يتلقى موقعك بيانات الإدخال (حركة المرور الواردة) أو مباشرة قبل إدراج الموقع إدخال مخصص في محتويات الصفحة (المنتهية ولايته). يمكن إجراء معالجة الإدخال الآمنة العميل / الخادم إما على جانب العميل أو على جانب الخادم، كل خيار ضروري ضمن ظروف مختلفة.
قبل الشرح في تفاصيل كيفية عمل الترميز والتحقق من الصحة، نصف كل من هذه العناصر.
معالجة مدخلات المستخدم في السياقات
هناك العديد من السياقات على صفحة ويب حيث يمكن تطبيق إدخال مخصص. يجب تلبية القواعد الخاصة لكل منها بحيث لا يمكن إدخال المستخدم "الخروج" من سياقه ولا يمكن تفسيره كصنونة ضارة. فيما يلي السياقات الأكثر شيوعا:
ما معنى السياقات؟
في جميع السياقات الموصوفة، قد تحدث مشكلة عدم الحصانة التي تؤدي إلى XSS إذا تم إدخال المستخدم الذي أدخله المستخدم إلى الترميز أو التحقق من الصحة الأول. يمكن للمهاجم تقديم شفرة ضارة ببساطة إدراج فاصل إغلاق لهذا السياق وبعد ذلك هو رمز ضار.
على سبيل المثال، إذا كان موقع الويب في مرحلة ما يشمل إدخال البيانات من قبل المستخدم مباشرة في سمة HTML، فسيكون المهاجم قادرا على تطبيق برنامج نصي ضار عن طريق بدء إدخال اقتباسه كما هو موضح أدناه:
يمكن منع هذا، ببساطة إزالة جميع علامات الاقتباس في إدخال المستخدم، وكل شيء سيكون على ما يرام، ولكن فقط في هذا السياق. إذا تم إدراج المدخلات في سياق آخر، فسيختلف فاصل الإغلاق وسيصبح الحقن ممكنا. لهذا السبب، يجب دائما تكييف معالجة إدخال آمنة للمدخلات مع السياق حيث سيتم إدراج إدخال المستخدم.
معالجة إدخال المستخدم الوارد / الصادر
غريزي، قد يبدو أنه يمكن منع XSS بواسطة الترميز أو التحقق من صحة إدخال المستخدم بأكمله، بمجرد أن يتلقى موقعنا. وبالتالي، سيتم بالفعل تحييد أي خطوط ضارة كلما يتم تضمينها في الصفحة، ولا يجب على البرامج النصية لتوليد HTML العناية بالمعالجة الآمنة لإدخال المستخدم.
المشكلة هي أنه كما هو موضح سابقا من قبل المستخدم الذي أدخله المستخدم يمكن إدراجها في عدة سياقات على الصفحة. و لا طريقة بسيطة حدد متى يأتي إدخال المستخدم في السياق - حيث سيتم إدراجه في النهاية، وغالبا ما يتم إدخال إدخال المستخدم نفسه في سياقات مختلفة. الاعتماد على معالجة المدخلات الواردة لمنع XSS، نقوم بإنشاء حل هش للغاية سيكون عرضا للأخطاء. (اقتباسات سحرية قديمة "PHP هي مثال على هذا الحل.)
بدلا من ذلك، يجب أن يكون معالجة المدخلات الصادرة خط الحماية الرئيسي من XSS، لأنه يمكن أن يأخذ في الاعتبار السياق المحدد، الذي سيتم إدخال المستخدم الذي أدخله المستخدم. إلى حد ما، يمكن استخدام التحقق الوارد لإضافة طبقة حماية ثانوية، ولكن هذا في وقت لاحق.
حيث من الممكن إجراء معالجة مدخلات المستخدم الآمنة
في معظم تطبيقات الويب الحديثة، تتم معالجة إدخال المستخدم على جانب رمز الخادم وعلى جانب رمز العميل. من أجل الحماية من جميع أنواع XSS، يجب تنفيذ معالجة الإدخال الآمنة في الكود على جانب الخادم وجانب رمز العميل.
- من أجل الحماية من XSS التقليدية، يجب إجراء معالجة الإدخال الآمنة في التعليمات البرمجية على جانب الخادم. يتم ذلك مع لغة مدعومة من قبل الخادم.
- من أجل الحماية من هجوم XSS في نموذج DOM، حيث لا يتلقى الخادم سلسلة خبيثة (على سبيل المثال، يجب أن يتم تنفيذ الهجوم الذي سبق وصفه عبر جزء المعرف)، يجب إجراء معالجة الإدخال الآمنة في التعليمات البرمجية على جانب العميل. يتم ذلك مع جافا سكريبت.
الآن، عندما شرحنا لماذا يهم السياق، لماذا الفرق بين معالجة الإدخال الواردة والصادر غير مهم، ولماذا يجب إجراء معالجة الإدخال الآمنة على كلا الجانبين، وعلى جانب العميل وعلى جانب الخادم، يمكننا الاستمرار في شرح كيف يتم تنفيذ نوعين من معالجة الإدخال الآمنة (الترميز والتحقق) بالفعل.
ترميز
الترميز هو وسيلة للخروج من الوضع عندما يكون من الضروري أن يفسر مستعرض إدخال المستخدم فقط كبيانات، وليس رمز. النوع الأكثر شيوعا من الترميز في تطوير الويب هو HTML اخفاء يحول الأحرف مثل < و > في < و > على التوالى.
PSEUdocode التالي هو مثال على كيفية ترميز المستخدم الذي أدخله المستخدم (Enter Enter) باستخدام اخفاء HTML ثم إدراج الصفحة باستخدام سيناريو الخادم:
مطبعة " "
مطبعة "آخر تعليق:"
طباعة encodehtml (userinput)
مطبعة ""
إذا دخل المستخدم السطر التالي سوف تبدو HTML الناتجة مثل هذا:
آخر تعليق:
نظرا لأن جميع الرموز ذات القيم الخاصة كانت مقنعة، فلن يقوم المتصفح بتفكيك أي جزء من إدخال المستخدم ك HTML.
رمز الترميز على جانب العميل والخادم
عند ترميز رمز الترميز من العميل، يتم استخدام لغة JavaScript دائما، والتي تحتوي على وظائف مضمنة تشفير البيانات لمختلف سياقات مختلفة.
عند إجراء الترميز في التعليمات البرمجية الخاصة بك على جانب الخادم، فإنك تعتمد على الميزات المتاحة بلغتك أو إطارك. بسبب عدد كبير اللغات والأطر المتاحة المقدمة درس تعليمي لن تغطي تفاصيل الترميز في أي خادم أو إطار معين. ومع ذلك، يتم استخدام وظائف ترميز JavaScript المستخدمة على جانب العميل عند كتابة التعليمات البرمجية على جانب الخادم.
الترميز على جانب العميل
عند ترميز إدخال عميل مخصص باستخدام JavaScript، هناك العديد من الأساليب والخصائص المضمنة التي ترميز جميع البيانات تلقائيا إلى نمط تعتمد على السياق:
لم يتم تضمين السياق الأخير المذكور أعلاه أعلاه (القيم في JavaScript) في هذه القائمة، لأن JavaScript لا توفر طريقة ترميز البيانات المدمجة، والتي سيتم تمكينها في التعليمات البرمجية المصدر JavaScript.
قيود الترميز
حتى عند الترميز، من الممكن استخدام الخطوط الخبيثة في بعض السياقات. مثال مشرق على هذا هو عندما يتم استخدام إدخال المستخدم لتوفير عنوان URL، على سبيل المثال، في المثال أدناه:
document.QuerySelector ("A"). HREF \u003d UserInput
على الرغم من أن القيمة المحددة في خاصية عنصر HREF ترميزها تلقائيا بحيث لا تصبح أكثر من قيمة السمة، إلا أن هذا في حد ذاته لا يتداخل مع المهاجم إدراج عنوان URL بدءا من "JavaScript:". عند النقر فوق الارتباط، بغض النظر عن البناء، سيتم تنفيذ JavaScript المدمج داخل عنوان URL.
الترميز ليس أيضا حلا فعالا عندما تريد المستخدمين استخدام جزء من رموز HTML على الصفحة. مثال على ذلك صفحة ملف تعريف المستخدم، حيث يمكن للمستخدم استخدام HTML المستخدم. إذا تم ترميز HTML هذا المعتاد، فستتمكن صفحة الملف الشخصي من التصالح فقط من النص البسيط.
في مثل هذه الحالات، يجب الاستكمال الترميز بالتحقق من الصحة التي سنحصل عليها أكثر.
تصديق
التحقق من صحة هو فعل إدخال المستخدم في تصفية المستخدم بحيث تتم إزالة جميع الأجزاء الخبيثة دون الحاجة إلى إزالة الرمز بأكمله فيه. واحدة من أكثر أنواع التحقق المستخدمة في تطوير الويب تتيح لك استخدام بعض عناصر HTML (على سبيل المثال، و ) ولكن من فوربوفوف الآخرين (على سبيل المثال،