كشف تشابك نقاط الضعف على المواقع

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

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

بداية

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

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

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



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



بالعودة إلى اختبار نموذج إرسال الطلب ، وجدت أيضًا ثغرة أمنية في iDOR تسمح لك بتغيير سعر الطلب عن طريق تحرير المعلمات "json_order [0] [السعر]" و "json_order [0] [الإجمالي]" في POST request domain.ru/shop.php . استبدال رابط الطلب في نفس الطلب في الحقل json_order [0] [href] أدى إلى RFI.

لم يرد أي رد على رسالة حول الاكتشافات الجديدة ...

استمرار

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

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

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

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

على أنه مع xss كان قد انتهى ، كان من الممكن أن تنتقل إلى أشياء أكثر إثارة للاهتمام.

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

من المستغرب ، لم يكن هناك حماية ضد CSRF. كان من الممكن إرسال أي طلبات ، لم يتم إجراء عمليات الفحص في أي مكان.
- تغيير معلومات الحساب؟ - من فضلك
- تغيير اسم وسعر البضائع؟ - لا سؤال

في الوقت نفسه ، احتوت ملفات تعريف الارتباط على شيء يسمى "csrftoken".

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

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

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

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

مزيد من أكثر إثارة للاهتمام. جميع البيانات حول البضائع التي أخذها المتجر عبر الإنترنت من crm. أي الاسم والوصف والصورة. كان رابط صورة المنتج هو "yyyy.domain.ru/file/get/id=xxx". حتى يتمكن المتجر عبر الإنترنت من التقاط الصور ، يجب أن يتمتع بحقوق قراءة للجميع. 122.

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

- هل قدمت طلبًا لاستيراد بيانات الطلب في ملف exel؟ - رائع ، الآن يمكن لأي شخص تنزيله.

ربما هناك معرف يشبه "yt5bjFb54hb # HJ٪ $ p" ولم يستسلم للقوة الغاشمة؟ لا كذلك. جميع ملفات الهوية لها تنسيق رقمي وكانت في حدود عدة آلاف. الحماية ضد وحشية ، كما أنني لم يلاحظ. بعد مسح جميع المعرفات 1 إلى 10000 العقبات لم تفي. وكرر عدة مرات ، لم يكن أحد مهتمًا بمثل هذا النشاط.

لقد أجابوا على تقريري في 3 أيام.

فيما يتعلق بعدم وجود علم ، قال httponly أنه مفقود "منذ فترة طويلة على ما يبدو ، منذ أن تم تحديث إصدار php." تحولت في نفس اليوم.

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

لم يكن تحميل الملفات التعسفية على الخادم مصدر قلق كبير لهم ، لأنها لم تنفذ على الخادم ، مما يعني أنه لا يوجد ما يدعو للقلق. فقط في وقت كتابة المقال ، كانت لدي فكرة إذا كان موقع موجود بالفعل على مضيف آخر بخلاف crm يحاول التقاط صورة للمنتج لواجهة المتجر ، لكن يتلقى نصًا php ، هل سينفذها؟ أو بسبب حقيقة أنها مخصصة لعلامة img ، هل ستتم معالجتها كصورة فقط؟ أم أنها تعتمد على إعدادات الخادم؟ يرجى الإجابة على دراية الناس.

تحولت الاستجابة لتقرير csrf إلى أن تكون ممتعة للغاية. أجابوا بسؤال: "ما الذي تعتبره رمزًا للحماية من هجمات csrf؟" حقا ، ما الذي أتحدث عنه؟



قالوا عن حرية الوصول إلى أي ملفات لم يأخذوها في هذه اللحظة. أغلقت على الفور.

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

'' '
نحن راضون عن الصغيرة ، والسعادة ليست في أموال كبيرة
"افعل ما تحب" - موضع تقدير في دوائرنا
'' '© Kolya Manyu - كل يوم

إنهاء

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



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



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

بعد بضعة أسابيع ، تم إصلاح الخلل.

أشكر كل من قرأ حتى النهاية!