إذا كنت خبيرًا في اختبار الأمان وشاركت مرة أو مرتين في برامج المكافآت لشركات تكنولوجيا المعلومات الكبيرة ، وكان عدد XSS الذي وجدته في العشرات أو حتى المئات ، يمكنك تجاهل هذه المقالة بأمان. إذا كنت جديدًا على الموضوع وبدأت للتو في الاهتمام بالعثور على نقاط الضعف - مرحبًا بك تحت cat.
تعريف
XSS (Cross-Site Scripting) هي ثغرة أمنية شائعة يمكن العثور عليها في العديد من تطبيقات الويب. جوهرها بسيط للغاية: تمكن المهاجم من إدخال كود JavaScript في الصفحة التي لم يتم توفيرها من قبل المطورين. سيتم تنفيذ هذا الرمز في كل مرة يزور الضحايا (المستخدمون العاديون) صفحة التطبيق حيث تمت إضافة هذا الرمز. ثم هناك عدة سيناريوهات للتطوير.
أولاً ، سيتمكن المهاجم من الحصول على بيانات اعتماد المستخدم وتسجيل الدخول إلى حسابه.
ثانيًا ، يمكن للمهاجم دون أن يلاحظه أحد من قبل الضحية إعادة توجيهه إلى صفحة استنساخ أخرى. قد تبدو هذه الصفحة متطابقة تمامًا مع الصفحة التي توقع المستخدم التواجد عليها. لكنها ستنتمي إلى الدخيل. إذا لم يلاحظ المستخدم الاستبدال وأدخل بعض البيانات الحساسة في هذه الصفحة ، أي البيانات الشخصية ، فسيحصل المهاجم عليها.
الثالث ... نعم ، بشكل عام ، هناك الكثير الذي يمكنك التفكير فيه. كل شيء تقريبًا يمكن لـ JavaScript القيام به يكون متاحًا للمهاجم. أدناه سوف نلقي نظرة فاحصة على أحد هذه الأمثلة. في الوقت الحالي ، دعنا نحاول مناقشة كيفية عمل الثغرة بمزيد من التفصيل. ولماذا يتمكن المهاجم من حقن الكود الخاص به في تطبيق شخص آخر دون الوصول إلى مصدره.
تحذير بسيط. يتم تقديم جميع المعلومات أدناه لأغراض إعلامية فقط. يجب أن يكون المختبر قادرًا على اختبار تطبيق الويب الخاص به بحثًا عن نقاط الضعف. ومع ذلك ، فمن غير القانوني استغلال ثغرات XSS على موارد الآخرين.
إذا تحدثنا عن التشريع الروسي الحالي ، عندما يقوم الباحث باختبار منتج شخص آخر بحثًا عن نقاط ضعف أو دخول شبكة شخص آخر دون معرفة وموافقة المالك ، يمكن اعتبار أفعاله غير قانونية.
لكن العودة إلى XSS.
كيف تعمل الثغرة الأمنية؟
بادئ ذي بدء ، كيف يمكنك بالضبط إدخال شفرة JavaScript في صفحة لم تكن موجودة من قبل؟ وكيف توزع هذا الكود على مستخدمين آخرين؟
على سبيل المثال ، يمكنك إضافة كود JavaScript إلى حقل إدخال ، يتم حفظ النص منه وعرضه لاحقًا على الصفحة لجميع المستخدمين. يمكن أن يكون هذا حقلاً لإدخال معلومات عنك في صفحة ملف تعريف الشبكة الاجتماعية أو التعليقات في المنتدى.
يقوم المهاجم بإدخال نص (ورمز ضار واحد) ، يتم حفظه في الصفحة. عندما يزور المستخدمون الآخرون نفس الصفحة ، سيقومون بتنزيل JavaScript الخاص بالمهاجم مع النص. في لحظة التحميل ، سيعمل هذا الرمز. بالطبع ، لن تعمل الثغرة الأمنية إلا إذا لم يكن النص آمنًا عند حفظه. سنتحدث لاحقًا عن كيفية القيام بذلك ، ولماذا ينسى المطورون ذلك أحيانًا.
هذا فقط هو المثال الأبسط والأكثر وضوحًا على المكان الذي يمكن فيه إخفاء الثغرة الأمنية. أدناه سننظر في مثال أكثر إثارة للاهتمام على صفحة تجريبية معدة خصيصًا.
حتى ذلك الحين ، دعنا ننتقل.
لماذا توجد مثل هذه الأخطاء غالبًا في مشاريع الويب؟
خلاصة القول هي أن المتصفح لا يمكنه التمييز بشكل مستقل بين النص العادي والنص ، وهو كود CSS أو HTML أو JavaScript. سيحاول التعامل مع أي شيء بين علامات <script> على أنه كود JavaScript. أي شيء يقع بين علامات <style> يعتبر CSS. وكل ما يشبه الوسم يعتبر كود HTML.
إذا أراد المطور أن يبدو بعض النص مثل الكود فقط ، لكنه ليس كذلك (أي أنه لم تتم معالجته بواسطة المتصفح ، ولكن يتم عرضه كما هو) ، فيجب معالجة هذا النص بشكل خاص قبل إعطائه للمتصفح. هذه المعالجة تسمى "التدريع".
في عملية الهروب من النص في هذا النص ، جميع العروض الخاصة. يتم استبدال الأحرف بـ "نظرائهم" ، والمتصفح يعرف بالفعل على وجه اليقين أنه مجرد نص. أهم شيء هو معالجة النص الذي يأتي من المستخدم ، حيث يمكن لأي مستخدم أن يتحول إلى مهاجم ويرسل بعض التعليمات البرمجية مع النص. للأسف ، ينسى المطورون أحيانًا الهروب في أماكن معينة في تطبيق ويب ، ويتم عرض النص دون أي معالجة. قد يكون هناك عدة أسباب لذلك.
على سبيل المثال ، لا يضع المبرمج دائمًا في الاعتبار جميع الأماكن التي يظهر فيها النص المحدد من قبل المستخدم على الصفحة. علاوة على ذلك ، في بعض الأحيان يمكن إنشاء أجزاء مختلفة من الموقع في أوقات مختلفة و / أو بواسطة أشخاص مختلفين. في هذه الحالة ، يزداد احتمال الخطأ.
قد يكون سبب آخر هو أن الثغرة الأمنية ليست في كود المطور نفسه ، ولكن في كود المكتبة التي يستخدمها. عادة ما تكون هذه بعض الأطر الجاهزة لإنشاء خدمات الويب. في هذه الحالة ، قد لا يشك المطور ، بالطبع ، في أنه من خلال ربط هذا الإطار بالمشروع ، فإنه يقوم تلقائيًا بربط ثغرة جاهزة به.
هناك دائما مثل هذا الخطر. ومع ذلك ، فإن كتابة تطبيق بالكامل من الصفر ، دون استخدام أي مكتبات على الإطلاق ، يعد طويلًا ومكلفًا في الوقت الحاضر. لا تستطيع كل شركة تطوير هذا المستوى.
في هذه الحالة ، كل الأمل هو للمختبرين.
لماذا تعتبر ثغرة XSS خطيرة؟
دعنا مرة أخرى ، بمزيد من التفصيل ، نتحدث عن مخاطر ثغرة XSS. الضعف في حد ذاته ليس خطيرًا. يصبح الأمر خطيرًا عندما يجدها متطفل ويبدأ في استخدامه لأغراضه الخاصة. يُطلق على استغلال الثغرة الأمنية اسم "ناقل الهجوم". في حالة XSS ، هناك عدد غير قليل من نواقل الهجوم.
أبسط مثال على ذلك هو سرقة ملفات تعريف الارتباط الخاصة بالتخويل من مستخدمي تطبيق ويب. في أغلب الأحيان ، يميز الموقع الذي يوجد به ترخيص المستخدم المرخص بما يسمى ملف تعريف ارتباط الجلسة. إذا لم يكن كذلك ، فهذا يعني أن المستخدم غير مصرح له. وإذا كان الأمر كذلك ، فبفضل قيمة ملف تعريف الارتباط هذا ، يمكن للخادم تمييز مستخدم عن آخر.
يتم تخزين جميع ملفات تعريف الارتباط على كمبيوتر المستخدم. إذا قمت بتسجيل الدخول باعتباري المستخدم الخاص بي ، فسوف أرى قيمة ملفات تعريف الارتباط الخاصة بي. ولا يمكنني معرفة معنى شخص غريب.
الشيء نفسه ينطبق على كود JavaScript الذي يتم تشغيله في متصفح المستخدم. ستشاهد شفرة JavaScript هذه قيمة ملف تعريف الارتباط للمستخدم الذي يتم تنفيذه في متصفحه فقط.
لنفترض الآن أن المهاجم نجح في إدخال كود JavaScript في صفحة تطبيق ويب. أي مستخدم يزور هذه الصفحة الآن سيتم تنفيذ كود JavaScript في المتصفح. سيقرأ قيمة ملف تعريف الارتباط لهذا المستخدم (الآن الضحية). يبقى فقط تمرير هذه القيمة إلى المهاجم - ويتم إنجاز المهمة. ولكن كيف تمرر القيمة ، حيث يتم تنفيذ الشفرة الخبيثة في متصفح الضحية؟
انها بسيطة جدا. يمكن أن تنشئ شفرة JavaScript نفسها طلب AJAX للخادم البعيد. على سبيل المثال ، إلى عنوان URL التالي: www.zloy-site.ru/stolen= { ضحايا_cookie_value }
ينتمي مجال zloy -site إلى المهاجم من مثالنا. يتم تسجيل جميع الطلبات التي تصل إلى هذا المجال في قاعدة البيانات. من خلال النظر في معلمات URL ، يتعرف المهاجم على قيم ملفات تعريف الارتباط الخاصة بالضحية ويمكنه استخدامها للوصول إلى حساباتهم.
كما ناقشنا أعلاه ، ليس هذا هو الشيء الوحيد الذي يجعل ثغرة XSS خطيرة. لذلك من أجل الأمن وحماية المستخدمين ، يجب أن تكون قادرًا على العثور على مثل هذه الثغرات الأمنية وإصلاحها في مشاريعك.
أين يمكنني أن أجد XSS؟ كيفية التعامل معها؟ الصفحة التجريبية مع المثال
بادئ ذي بدء ، من المفيد التحقق من ثغرات XSS في تلك الأماكن الموجودة على الموقع والتي تتاح فيها الفرصة للمستخدم العادي للتأثير على المحتوى. إذا كان بإمكانه إضافة بعض النص في مكان ما ، فيمكنه محاولة إضافة كود JavaScript أيضًا.
لنلق نظرة على هذا بمثال محدد. لقد أعددت صندوق رمل بسيط للغاية حيث تم إخفاء ثغرة XSS. أقترح محاولة العثور عليه معًا.
فتح صندوق الحماية: https://playground.learnqa.ru/demo/xss
أولاً ، دعنا نرى كيف تعمل الصفحة. إنه في الأساس كتالوج كتاب بسيط للغاية يمكن البحث فيه. إذا أدخلنا "Ray Bradbury" في الاستعلام ، فسنرى جميع الكتب الموجودة في دليل هذا المؤلف.
لقد لاحظ المستخدم اليقظ بالفعل أن النص الذي أدخلناه في حقل البحث انتهى فورًا في عنوان URL. هذه اللحظة لا تزال مفيدة لنا.
في الوقت الحالي ، دعونا نحاول إدخال بعض الهراء في مربع البحث: "fwefewf".
سنرى أنه في هذه الحالة لم يتم العثور على شيء في الصفحة. وتكرر نص الطلب في نص الخطأ:
لذلك ، وجدت أنت وأنا المكان الذي يظهر فيه النص الذي أدخلناه. لذلك ، هذا موقع محتمل لثغرة XSS. دعنا نحاول إدخال كود JavaScript الأكثر شيوعًا للتحقق مما إذا كانت هناك ثغرة أمنية.
<script> alert (123) </script>
إذا كانت الصفحة معرضة للهجوم ، بعد إدخال هذا الرمز ، ستظهر النافذة التالية على الصفحة:
هذا يعني أنه تم تنفيذ كود JavaScript الخاص بنا ووجدنا ثغرة في XSS.
لذلك ، نقوم بإدخال الكود ونرى التحذير التالي:
النموذج لا يسمح لنا بالبحث بهذه القيمة ، حيث تم التحقق من صحة النموذج ويريد العمل فقط مع الأحرف والأرقام. للوهلة الأولى ، يبدو أن المطور أخذ كل شيء في الحسبان وقام بحماية الصفحة من XSS ، لكن هذا ليس صحيحًا تمامًا.
تذكر ، أعلاه ، لاحظنا أن النص الذي ندخله في حقل البحث معروض في عنوان URL في ما يسمى معلمة GET؟ اسم هذه المعلمة هو “q” ، والقيمة هي ما ندخله في حقل البحث. يتم ذلك حتى تتمكن من نسخ عنوان URL مع سلسلة البحث هذه وفي المرة القادمة افتح الصفحة مع المؤلفين المناسبين على الفور.
على سبيل المثال ، سيفتح عنوان URL هذا على الفور صفحة بها كتب Ray Bradbury فقط: playground.learnqa.ru/demo/xss؟q=Ray+Bradbury على
عكس النموذج ، لا يمكن للمطور إجراء التحقق من عنوان URL - يمكن لأي مستخدم إدخال أي عنوان URL في متصفحه كل ما تريد ، بما في ذلك أي قيمة لمعامل GET. تتمثل مهمة المطور في هذه الحالة في عدم نسيان مراعاة جميع الخيارات وكتابة المعالج الصحيح لقيمة معلمة GET هذه.
دعنا نتحقق مما إذا كان مطورنا قد نسي أخذ كل شيء في الاعتبار هنا. دعنا نحاول استبدال نفس كود JavaScript في معلمة "q" GET: https://playground.learnqa.ru/demo/xss؟q= <script> alert (123) </script>
بعد النقر فوق عنوان URL هذا ، نرى ذلك ظهرت نافذة على الصفحة بقيمة 123. لكن لماذا؟
انها بسيطة جدا. تذكر ، عندما يتعذر على موقع ما العثور على الكتب التي يحتاجها لاستعلام بحث معين ، فإنه يعرض نص استعلام البحث هذا في نص خطأ؟ مثل ، لم أجد أي شيء للاستعلام "بلاه بلاه". بدلا من هذا "بلاه بلاه" لدينا الآن كود جافا سكريبت مع تنبيه. كتب المطور التحقق من صحة حقل الإدخال وقرر أن هذه هي الطريقة التي يحمي بها الموقع من تضمين JavaScript في استعلام البحث. ولم يفلت من نص الخطأ. تمكنا من تجاوز التحقق من صحة عنوان URL من خلال تغيير قيمة استعلام البحث هناك.
من أجل الاهتمام ، يمكننا الآن عرض قيمة ملف تعريف ارتباط الجلسة الخاص بنا ، لذلك ، بدلاً من <script> alert () </script> في عنوان URL ، تحتاج إلى استبدال رمز آخر: <script> alert (document.cookie) </script>
سأدعك تلعب بهذا نفسك. :)
بعد العثور على خطأ ، يجب عليك الاتصال بالمطورين - سيقومون بإصلاحه.
هناك طرق عديدة لإغلاق الخطأ. الهروب من النص ليس هو الوحيد. يمكنك أيضًا منع JavaScript نفسها من رؤية بعض ملفات تعريف الارتباط. لهذا ، يحتوي ملف تعريف الارتباط على معلمة خاصة "http فقط". إذا تم ضبطه على TRUE ، فلن يتمكن JavaScript من معرفة أن ملف تعريف الارتباط هذا قد تم تعيينه على الإطلاق ولن يكون قادرًا على قراءته ونقله إلى مهاجم حتى لو تمكن من العثور على XSS في مشروعك.
كل هذا مجرد قائمة صغيرة ، بعيدة عن قائمة كاملة من التلاعبات لمنع ثغرات XSS. كما هو مذكور أعلاه ، إذا تم اكتشاف XSS أثناء الاختبار ، فمن الأفضل التحدث إلى المبرمجين.
إذا كنت مهتمًا بمعرفة المزيد عن اختبار الأمان ، فأنت تريد أن تفهم بشكل أفضل هيكل بنية خادم العميل ، وأن تفهم وتشحذ أكثر الطرق فاعلية للعثور على نقاط الضعف في تطبيق ويب حقيقي ، فانتقل إلى الدورة التدريبية الخاصة بي "اختبار الأمان". كل المعلومات التي تحتاجها موجودة في ملف التعريف الخاص بي.
ستجد فقط نظرية مفيدة وضرورية بدون ماء وعدد كبير من الأمثلة العملية والمهام. سوف تستكشف العديد من صفحات الويب المليئة بمجموعة متنوعة من نقاط الضعف. سيكون العمل النهائي عبارة عن دراسة كبيرة إما لمشروع عملك ، أو أحد تطبيقات الويب لعمالقة مثل Google و Facebook و Twitter وما إلى ذلك.