عملية XSS على أساس ملفات تعريف الارتباط | قصة 2300 دولار علة باونتي

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

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

⠀ 1. CRLF حقن. تحدث مشكلة عدم الحصانة هذه عندما لا يكون هناك تحقق صحيح وحظر أحرف فاصل الأسطر. يمكننا تطبيق رأس مجموعة ملفات تعريف الارتباط استجابةً للاسم المرغوب بالإضافة إلى قيمة ملف تعريف الارتباط وتعيينه في المستعرض. مثال على الحياة الحقيقية: حقن Slippery CRLF على twitter.com في إعادة توجيه - https://twitter.com/login؟redirect_after_login=/jjjkkk 嘍 嘍 Set-Cookie: jjjjj = a؛ domain = twitter.com



يمكن قراءة التقارير المتعلقة بهذا النوع من الضعف على HackerOne hackerone.com/hacktivity؟order_direction=DESC&order_field=popular&filter=type٪3Apublic&querystring=crlf٪20injection

2. XSS الضعف على المجال الفرعي. مطلوب XSS لتكون متاحة للجمهور وتقع على wildcard * .vulnerabledomain.com. بالنسبة إلى العديد من برامج bounty bugy ، تكون النطاقات الفرعية خارج النطاق ، أي في معظم الحالات ، لا يتم قبول الأخطاء على الإطلاق ، أو يتم تلقيها بعلامة "غير مؤهلة للحصول على bounty". في مثل هذه الحالات ، يجب ألا تتراجع ، ولكن من أجل الاتصال بـ XSS المستند إلى ملف تعريف الارتباط ، يمكنك استثمار وقتك في البحث عن XSS للحصول على مكافأة. إذا تم اكتشاف XSS ، فيمكننا تعيين أو إزالة ملف تعريف الارتباط باستخدام دالة document.cookie.

تعزيز التأثير: غالبًا ما تثق الضحية بالمجال الرئيسي لـectedabledomain.com أكثر من ، على سبيل المثال ، jira.vulnerabledomain.com ، وحتى مع URL /plugins/servlet/oauth/users/icon-uri؟consumerUri=https://maliciousdomain.com . من المحتمل أن ينتقل إلى المجال الرئيسي بدلاً من النطاق الفرعي إذا لم يرتبط هذا النطاق الفرعي بحساب شخصي أو تفويض. استنادًا إلى ما تقدم ، يمكننا استخدام وظيفة إعادة التوجيه في الموقع لإعادة التوجيه إلى الضعيفة : domainjetomain.com/login؟redirectUrl=https: //jira.vulnerabledomain.com/path للنطاق الفرعي للحصول على تأثير أفضل.

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

3. الكشف عن ملفات الاختبار التي تسمح بتعيين ملفات تعريف الارتباط. يكفي الكشف عن أداة الكشف عن المحتوى (dirb ، dirserach ، إلخ) ، وبدء الحفر ، وإذا نسي المطورون إجراء التنظيف ، فيمكنك التعثر على هذه الملفات.

لقد عثرت مؤخرًا على صفحة html test servlet والتي كان من الممكن فيها تثبيت ملف تعريف ارتباط باسم وقيمة اعتباطيين. بطبيعة الحال ، كانت الحماية على طلب POST غائبة ، لذلك إذا كانت الضحية تزور استغلال ملف CSRF (أو يمكنك تغيير POST إلى GET) ، فسيكون من الممكن تثبيت ملف تعريف الارتباط في متصفحها.



تم تأهيل هذا الخطأ كبديل للحقن CRLF ، تم إصلاحه عن طريق إزالة / أمثلة / ودفع 150 دولارًا كحدوث خلل منخفض الخطورة. على الرغم من تسليم tri1 h1 المتوسط ​​، إلا أن المطورين كانوا لا يزالون يميلون إلى الاعتقاد بأن هذه القوة منخفضة.



4. رجل في الهجوم الأوسط (MITM). لا يمكن تطبيق هذه الطريقة إلا في حالة عدم وجود علامة آمنة على ملف تعريف الارتباط. إذا كنت لا تعرف نوع العلم الذي تريده أو تريد فقط تحديث ذاكرتك ، فننصحك بمشاهدة عرض أمان ملفات تعريف الارتباط مع OWASP London 2017 www.owasp.org/images/a/a0/OWASPLondon20171130_Cookie_Security_Myths_Misconceptions_David_Johansson.pdf .

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

1) استضافة ملف index.php بالمحتويات التالية:

<?php if ($_SERVER['HTTP_HOST'] == 'non-existed-subdomain.vulnerabledomain.com') { setrawcookie("VID",'\'+alert(123123123)+\'', time()+36000, "/", ".vulnerabledomain.com",0,1); } ?> 

2) أضف السطر التالي إلى / etc / hosts / file: 127.0.0.1 non-existed-subdomain.vulnerabledomain.com

3) قم بزيارة non-existed-subdomain.vulnerabledomain.com وبعد ذلك افتح الصفحة التي ينعكس فيها ملف تعريف الارتباط.

مثال رائع على استغلال MITM على e.mail.ru هو https://hackerone.com/reports/312548 ، كما ترون ، كانت MITM كافية لإثبات وجود خطر صغير من الضعف ، لكن الجائزة لم تتطابق مع مستوى تخزين XSS ، حيث تم عرضه فقط الوضع "المحلي" للعملية ، وهذا ليس ، "في البرية". إذا قضى الباحث بعض الوقت في البحث عن حقن XSS أو CRLF (والذي لا يعد ولا يحصى) الموجود على * .mail.ru ، فيمكن زيادة المكافأة قليلاً.

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

أثناء اختبار الموقع ، رأيت فجأة أن قيمة ملفات تعريف الارتباط المنقوصة تنعكس في أحد الأدلة الفرعية للموقع. أول شيء فعلته هو التحقق من عرض الأحرف "" / <>. اتضح أنه تم تصفية الأحرف <> فقط ، وهذا يخبرنا أننا لا نستطيع تجاوزها ، ولكن يصبح من الواضح أيضًا أن الأحرف الأخرى لا يتم تصفيتها وبدون تفكير مرتين ، ننفذ '-ertert (document.domain) -' ويتم تنفيذ js.

نظرًا لأن المطورين لم يمنحوا ملف تعريف الارتباط علامة آمنة ، في هذه الحالة تعمل طريقة MITM. تقرر إرسال تقرير إلى البرنامج مع التأثير التالي:



أوضح موظفو HackerOne (الترياق) أن هذا هو XSS ذاتي ويجب أن أجربه:



بعد ذلك ، بدأت أتصفح الموقع وأحاول أن أجد CRLF injection أو XSS لإثبات الخطر.

had اضطررت إلى توسيع قائمة المجالات الفرعية بمساعدة قاموس كبير ، وإلغاء النطاقات الفرعية بشهادات SSL واستخدام بعض الحيل الأخرى. لم تكن النتيجة طويلة في المستقبل ، لأن معظم الأدوات التي أقوم بتشغيلها باستخدام VPS. من وقت لآخر ، تم اكتشاف أخطاء أخرى أيضًا على طول الطريق ، والتي أبلغت عنها ، مما يجعل النطاق خارج النطاق ، إذا لزم الأمر. لقد صادفت العديد من عمليات إعادة التوجيه المفتوحة وحتى خلل التحكم في الوصول غير المناسب بمبلغ 5000 دولار ، لكن لا يزال يتعذر عليّ اكتشاف الثغرات الضرورية للحزمة. الخطأ المذكور أعلاه مثير للاهتمام وخطير للغاية ، فقد تم أخذ النطاق الفرعي بالكامل في وضع عدم الاتصال فورًا بعد التقرير ، وربما في المستقبل سأفتح التقرير على hackerone.com/w2w ، إذا أصبح البرنامج عامًا.

بعد أسبوع ، تم فحص نتائج البرنامج النصي لاكتشاف المحتوى ، حيث تم العثور على نقطة النهاية / التحقق ، والتي لم أعلق عليها أهمية خاصة في البداية ، ولكن لا يزال يتم تعيين البرنامج النصي عليه - تم العثور على الدليل الفرعي للتحقق / login. بعد النقل ، يتم عرض /verification/login/؟redirect_uri=https://vulnerabledomain.com ، والتي تمت إعادة توجيهها إلى قيمة redirect_uri بعد تسجيل الدخول أو إعادة توجيهها على الفور إذا كانت هناك جلسة. بعد السفر إلى المتسلل ، تم اكتشاف تجاوز مفتوح لحماية إعادة التوجيه -. حاولت استرخاء الخطأ إلى XSS - javascript: فشل حمولة alert (1) ، javascript: alert (1) // أيضًا. لكن حمولة جافا سكريبت: // https: //vulnerablesite.com/٪250A1؟ تنبيه (1): 0 لقطة ، لأنه بسبب وجود هشاشة ، فقد مرت المعلمة التحقق من صحة القائمة البيضاء.



بعد دفع الماوس بشكل محموم عبر نافذة الإشعارات (أفعل دائمًا) ، قمت على الفور بالعمل على XSS المستند إلى ملف تعريف الارتباط. باستخدام javascript: https: //vulnerabledomain.com/٪0A1؟ المستند٪ 2ecookie٪ 20٪ 3d٪ 20٪ 27SID٪ 3d137gf6g67f76fg6766123٪ 5c٪ 27-alert٪ 28document٪ 2edomain٪ 29-٪ 5c٪ 27٪ 3b٪ 20 Expires٪ 3dFri٪ 2c٪ 203٪ 20Aug٪ 202019٪ 2020٪ 3a47٪ 3a11٪ 20UTC٪ 3b٪ 20path٪ 3d٪ 2f٪ 3b٪ 20domain٪ 3d٪ 2evulnerabledomain٪ 2ecom٪ 3b٪ 27٪ 3a0 تم وضع ملف تعريف الارتباط بنجاح على * .vulnerabledomain.com . بعد الانتقال إلى الصفحة مع ملف تعريف الارتباط ، أقلع التنبيه الذي يعتز به! XSS مزدوج ، هتافات! :) لقد استكملت التقرير وانتظرت إجابة.



في نفس اليوم ، حلقت لعبة "Nice catch" من الثلاثية (إذا كان بإمكانك تسميتها) ، وتم دفع المكافأة. بارك الله في الشركات التي تدفع على الفرز!

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

نتائج الاختبار

1000 دولار + 1000 دولار + 200 دولار (أو) + 100 دولار (أو) = 2300 دولار

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



وأيضًا ، كان هذا البرنامج هو الذي منحني دفعة جديدة (mail.ru - أول برنامج) ، حيث حصلت على 2500 سمعة (hello hoodie) وحصلت على المركز السادس والثلاثين في قائمة المتصدرين للسمعة في 90 يومًا ، وهو ما ينبغي أن يمسك بزمام جديد. . على الرغم من أنه يبدو أن الطعوم تصل بغض النظر عن التواجد على لوحة المتصدرين ، إلا أنني ألغيت في الغالب ترقيعًا قديمًا وأنتظر صراعا جديدة في الطابور.

موجز موجز

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

إذا كنت ترغب في مواكبة آخر المقالات والأخبار الخاصة بي ، فإنني أنصحك بالاشتراك في قناة / twitter telegram ، الروابط التي يمكن العثور عليها أدناه.