الويب الأمن اختبار كاتب كيت

مرحبا بالجميع!

اسمي اندريه. منذ 10 سنوات ، كنت أبحث عن نقاط الضعف في مختلف خدمات الويب. وعلى استعداد لتبادل معرفتي معك. في شهر مايو الماضي ، قدمت تقريراً حول هذا الموضوع في مؤتمر Heisenbug ، وأنا الآن على استعداد لمشاركة معرفتي هنا ، أيضًا ، في الأماكن المفتوحة لـ Habr. لذلك دعونا نبدأ.

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

قد تكون العناصر التالية مراحل فحص تطبيقات الويب:

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

سأتحدث عن كل هذا بالتفصيل.

لذلك ، التحضير. لن أركز على جميع أنواع الثغرات الأمنية ، وإلا فستتجاوز كمية النص في المقالة جميع الأحجام المعقولة وغير المتصورة. أنصحك بالبدء في التعلم من قائمة OWASP Top Ten Project . كل بضع سنوات ، يُشكل اتحاد OWASP قائمة بأكثر الثغرات ذات الصلة في الوقت الحالي. سننظر في عدد قليل منها بالتفصيل.

Xss

XSS (البرمجة النصية عبر المواقع) هي هجوم على مستخدم يسمح للمهاجم بتنفيذ نص تعسفي في سياق متصفح ضحيته. في معظم الأحيان ، فإنه ينطوي على تنفيذ علامات HTML والنصوص JS .
مثال: في وقت واحد كان هناك مثل هذه الخدمة Yahoo! Ad Exchange يحتوي نموذج استعادة كلمة المرور على معلمة " إرجاع عنوان URL ". يمكن أن تشير إلى الصفحة التي يجب الرجوع إليها بعد عملية إعادة تعيين كلمة المرور. إذا قمت بإدخال متجه واحد أو آخر يؤدي إلى تنفيذ كود JS ، فيمكنك الحصول على جميع ملفات تعريف الارتباط الخاصة بالمستخدم. سنحلل كيف يحدث هذا ولماذا.


هنا هو ناقل نفسه. في كل مرة:

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

نرى أن returnURL = / login.jsp
هذا يقع في قيمة العلامة <input> .
إذا أضفنا علامة اقتباس بعد jsp ، فسنرى أن بناء جملة HTML قد سكب. لحسن الحظ ، لغة HTML ليست صارمة ، سيتخطى المحلل ولن تكون هناك مشاكل:

أضف شخصية أخرى. نحن هنا خارج سياق العلامة <input> تمامًا :

نضيف الآن فتح علامة <svg> ، ونحصل على علامتين صالحتين من حيث بناء الجملة:

بعد ذلك ، أضف متجه الهجوم بالكامل:

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


هناك أيضًا المزيد من متجهات الهجوم على العميل. سأقدم بعض الأمثلة مع وصف موجز. لكن عليك أولاً أن تفهم كيفية الخروج من السياق:

• خارج السياق. ستساعد هذه الأحرف الستة في الخروج ليس فقط من سياق قيمة معلمة HTML ، ولكن أيضًا من العديد من الشخصيات الأخرى:
  -> "">
  

حسنًا ، في الحقيقة ، أبسط متجهين للهجوم:

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

أين وكيف تبحث عن XSS؟

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

إذا كان لديك بالفعل بيانات من مصادر غير موثوق بها ، فإنني أوصي بما يلي:

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

حقن SQL

تطبيق كود SQL (حقن SQL باللغة الإنجليزية) - مقدمة في استعلام قاعدة بيانات التعليمات التي لم تكن ضمنية هناك.

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

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

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

من أجل التحقق الكامل من وجود ثغرة أمنية ، نضيف شيطلاً بدلاً من الوحدة:

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

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

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

ما هو الخطر في SQL؟

• من الواضح - تسرب المعلومات . إذا كان المهاجم قادرًا على إنشاء استعلامات لقواعد البيانات الخاصة بك ، فيمكنه بطريقة أو بأخرى الحصول على قيم لم يكن من المفترض أن يتم إخراجها (تجزئة كلمة المرور ، عناوين العملاء ، إلخ) ؛
• تغيير البيانات . الآن العديد من المطورين استخدام قواعد البيانات من خلال أنظمة ORM . تتيح لك هذه الأنظمة نفسها ، افتراضيًا ، إجراء استعلامات متعددة في وقت واحد ، كما يسمح لك بناء جملة SQL بالقيام بذلك. إذا كانت هناك ثغرة أمنية ، فكل شيء يمكن أن ينتقل ليس فقط إلى اختيار البيانات ، ولكن أيضًا إلى تغييرها (حتى حذف الجداول ، وتغيير بنية قاعدة البيانات ، وما إلى ذلك).
  في نفس الموقف ، من الممكن زيادة امتيازات المستخدم. قم بتغيير الحقول في جداول معينة (على سبيل المثال ، ضع is_admins = صواب في قاعدة بيانات المستخدمين ) وبالتالي رفع حقوقك إلى المسؤول ؛
• هل . في بعض الحالات ، يمكن أن يؤدي الحقن إلى رفض الخدمة. يتم إنشاء العديد من الاستعلامات الثقيلة إلى قاعدة البيانات ، ويتم تشغيلها في عدة مؤشرات ترابط ، وقد تتوقف الخدمة عن العمل لبعض الوقت ؛
• قراءة ملفات النظام هي كارثة أخرى يمكن أن يسببها حقن SQL. يعتمد حدوث هذا الخطر على نظام قاعدة البيانات الذي تستخدمه ، وكذلك على المستخدم الذي يعمل معه (متميز أو لا) ؛
• RCE (تنفيذ التعليمات البرمجية عن بُعد) هو تنفيذ التعليمات البرمجية. يعتمد بشكل مباشر على نوع قاعدة البيانات المستخدمة (في السابق كان هذا ممكنًا بشكل افتراضي ، مع إعدادات قاعدة البيانات الافتراضية ، في MSSQL).

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

SSRF (تزوير طلب جانب الخادم)

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

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

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

هنا نولي الاهتمام لنقطتين:

• الصورة الرمزية URL نفسه
• والقدرة على تنزيله باستخدام ملف.

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

هل اثنين - انقر فوق " حفظ ". نحصل على روبوت بدلاً من صورتي:

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

نحن نمضي قدما. في حقل " URL avatar " ، أدخل ملف القيمة : /// etc / passwd . يسمح لك هذا التصميم بالوصول إلى بنية الملف. في بعض المكتبات التي تستخدم للعمل مع HTTP ، يتم تشغيل بنية الملفات افتراضيًا وتلقي البيانات من الخوادم التي تم تشغيلها عليها:

ماذا يحدث بعد النقر على زر " حفظ "؟
أولاً ، أصبحت الصورة " خفاش " ، وثانياً ، تغير مسار الملف.

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

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

• ميناء المسح الضوئي. بالنسبة لشبكة خارجية ، تكون خدمتك نقطة دخول واحدة ومنفذين (http و https). من خلال مسح المنافذ من داخل البنية الأساسية الخاصة بك ، يمكن للمهاجم اكتشاف المنافذ المفتوحة ؛
• تجاوز المصادقة المستندة إلى المضيف. ما هي النقطة؟ من الممكن أن تتوفر في هيكلك خدمات متاحة فقط لموارد معينة (اقرأ: قائمة بيضاء IP). لذلك ، إذا كان خادمك الضعيف في القائمة البيضاء ، فيمكنك الوصول إلى تلك الخدمات المتاحة له ، ونتيجة لذلك ، يمكنك معالجتها ؛
• مواصلة تطوير الهجوم المذكور أعلاه ، يمكنك الاستمرار في استغلال البرامج الضعيفة التي تعمل على الإنترانت أو على الخادم المحلي. غالبًا ما تكون هناك مواقف عندما تكون البنية التحتية الداخلية ، التي يتعذر الوصول إليها من الخارج ، تخضع للمراقبة السيئة (لا يتم دائمًا تحديث الإصدارات / تصحيحات الأمان ، وما إلى ذلك) هذا يمكن أن يؤدي أيضا إلى هجمات وسرقة البيانات.
• قراءة البيانات المحلية. لقد عرضت أعلاه مع مثال. يمكن قراءة التكوينات الخاصة بك والوصول إليها ، الرموز وكلمات المرور.

أن ننظر فيها ل SSRF؟

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

• Webhook . إذا تم تكوينها بشكل سيئ ، إذا تم تكوين جدار الحماية بشكل غير صحيح على تلك الخوادم التي يقدم Webhooks منها طلبات ، فيمكن الحصول على ثغرة أمنية ؛
• تحويل HTML . حاول تضمين < url > ، أو <img> ، أو <base> ، أو <script> ، أو CSS url ، الذي يشير إلى خدمة داخلية ؛
• تحميل الملفات المحذوفة . تذكر المثال الرمزية؟ عندما يكون لدى المستخدم فرصة تحميل البيانات عن طريق URL إلى الخادم ، فإن ذلك يستلزم مشاكل كبيرة. حاول إرسال عنوان URL مع المنفذ ومعرفة المحتوى الذي تم تحميله.

كيفية البحث عن SSRF؟

• رفع الخادم وتشغيل المستمع :
  

  user$ nc -1 -n -vv -p 8080 -k 

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

XXE (كيان XML خارجي)

سأبدأ القصة ، كما هو الحال دائمًا مع مثال ، بحيث يكون أكثر وضوحًا:
في خدمة SEMrush المذكورة أعلاه ، هناك هذه الأداة التي تتعامل مع تحليل المحتوى. يقوم المستخدم بالقيادة في عنوان URL لموقعه أو موقع منافس وقبل تحليله ، تقوم الخدمة بتنزيل هذا المحتوى بالذات. شاهد كيف يحدث هذا على الفيديو:



للتنزيل ، تصل الخدمة إلى الموقع المحدد ويقوم الزاحف بتنزيل ملف sitemap.xml . وهذه هي لغة XML التي نتحدث عنها في هذه المجموعة.
في الفيديو ، يمكننا ملاحظة كيف أضاف الموقع المهاجم تعريفًا للكيان الخارجي XXE إلى sitemap.xml ، والذي يشير إلى " file: /// etc / hosts ". على أنظمة Linux ، هذا هو الملف الذي يصف IP الذي يتوافق مع المضيفين إذا لم يكن هناك سجلات DNS لهم.
بعد ذلك ، يشير المهاجم في العلامة <loc> إلى توسيع هذا المتغير. بعد تحليل XML ، وبعد معالجة كل XML في المقصورة ، ستقوم بإدراج القيمة التي كانت في " file: /// etc / hosts " في متغير الموقع (مظللة باللون الأحمر في الفيديو).
يبدأ المهاجم في إطلاق المحلل اللغوي الخاص بنا ، ويذهب إلى السجلات ، وهنا يظهر سطر مظلل باللون الأبيض على الفيديو. هذه هي محتويات ملف " file: /// etc / hosts " الذي تم الحصول عليه في طلب GET في سجلات خادم يتحكم فيه.
ما التالي؟ المهاجم سوف يتحقق من أنه كان على حق. سيغير اسم الملف إلى " file: /// etc / fstab " ، قم بتشغيل المحلل اللغوي مرة أخرى والحصول على إحصائيات حول العمليات الجارية.

وأخيرًا: " file: /// etc / hostname " ، ابدأ المحلل اللغوي ، انتقل إلى السجلات واحصل على اسم مضيف الجهاز الذي نستخدمه.
هذا خطأ حقيقي اكتشفه شخص حقيقي لا علاقة له بشركتنا. اضطررت إلى رش الرماد على رأسي ودفع المال :)

مثال آخر على XXE :

لنفترض أن لدينا نقطة نهاية معينة ، يطلق عليها - example.com/xxe .
نرسل بنية XML إليها → في XML نعلن أن الكيان → الكيان يشير إلى ملف النظام / etc / passwd ويفتح مرة أخرى في نص الاستجابة → نحصل على محتويات هذا الملف استجابة.
تجدر الإشارة إلى أن هذا لا يحدث في كثير من الأحيان كما نود.

لماذا تعمل؟

مستندات XML هي تنسيق بيانات منظم يسمح لك ، من بين أشياء أخرى ، بوصف أنواع البيانات التي قد تحتوي عليها باستخدام علامة DOCTYPE خاصة.
تعريف نوع البيانات (DTD) - تعريف أنواع البيانات داخل مستند XML هذا. هناك ثلاثة خيارات لكيفية القيام بذلك:

• إذا كان المستند يدعم DTD . يوضح المثال التالي بعض XML التي يوجد بها بنية ترتيب ، وهناك عنصر منتج وعنصر حساب (من المفترض: رقم المخزون للمنتج وعدد العناصر في الترتيب). الترتيب هو الأصل لهذين العنصرين:
  
• DTDs الخارجية على الخادم المحلي.
  نفعل نفس الشيء كما في المثال الأول ، لكننا نصنع كل التعريفات في ملف منفصل ، وهو موجود على الخادم المحلي:
  
  
• DTDs الخارجية على خادم جهة خارجية:
  

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

ما هي الكيانات في XML؟

الكيانات في XML . ما هذا هذه فرصة لتعريف قيم معينة ودفعها إلى المتغيرات. الكيانات لها ثلاثة أنواع مختلفة:

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

أن ننظر فيها ل XXE ؟

عدة خيارات:

• معالجة XML في أي مظهر:
  
  • SVG
  • خريطة الموقع
• تحويل HTML إلى صيغ أخرى ؛
• التعامل مع docx ، xlsx والأشكال المماثلة.

كيف تبحث عنهم؟

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

أول شيء نقوم به: إعلان كيان Z معين ، والذي يصل إلى المضيف الذي يتحكم فيه المضيف المهاجم ، يقوم بتوسيعه داخل نص مستند XML .
هنا الخيار الثاني هو ممكن - مجرد جوهر المعلمة . يختلف عن الإعلان الأول (علامة ٪ ). وللتحول إلى هذا الجوهر ، لم تعد هناك حاجة إلى نص المستند. يمكننا الوصول إليه مباشرةً في بنية DOCTYPE وفضح هذا الكيان:

السيناريو الثالث هو معرفة ما إذا كانت القدرة على طلب DOCTYPE من الخدمات الخارجية قيد التشغيل أم لا:

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

ما هو خطر XXE ؟ سأكتب لفترة وجيزة ونقطة:

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

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