أساسيات القرصنة على الويب wep applications الجزء السادس xss

 

قبل أن ننتقل للتعرف على استغلال XXE ، علينا أن نفهم XML بشكل صحيح.

ما هو XML؟

XML (لغة الترميز الموسعة) هي لغة ترميز تحدد مجموعة من القواعد لترميز المستندات بتنسيق يمكن قراءته بواسطة الإنسان وقراءته آليًا. إنها لغة ترميز تستخدم لتخزين البيانات ونقلها. 

لماذا نستخدم XML؟

1. تعد لغة XML مستقلة عن النظام الأساسي ولغة البرمجة مستقلة ، وبالتالي يمكن استخدامها على أي نظام وتدعم التغيير التكنولوجي عند حدوث ذلك.

2. يمكن تغيير البيانات المخزنة والمنقولة باستخدام XML في أي وقت دون التأثير على عرض البيانات.

3. XMLيسمح بالتحقق من صحة باستخدام DTD والمخطط. يضمن هذا التحقق من الصحة خلو مستند XML من أي خطأ في بناء الجملة.

4. يبسط XML مشاركة البيانات بين الأنظمة المختلفة بسبب طبيعته المستقلة عن النظام الأساسي. لا تتطلب بيانات XML أي تحويل عند نقلها بين أنظمة مختلفة.

بناء الجملة يبدأ

كل مستند XML في الغالب بما يعرف باسم XML Prolog.

<?xml version="1.0" encoding="UTF-8"?>

فوق السطر يسمى XML prolog ويحدد إصدار XML والتشفير المستخدم في مستند XML. هذا السطر ليس إلزاميًا للاستخدام ولكنه يعتبر "ممارسة جيدة" لوضع هذا السطر في جميع مستندات XML الخاصة بك.

يجب أن يحتوي كل مستند XML على عنصر "ROOT". فمثلا:

<?xml version="1.0" encoding="UTF-8"?>

<mail>

   <to>falcon</to>

   <from>feast</from>

   <subject>About XXE</subject>

   <text>Teach about XXE</text>

</mail>

في المثال أعلاه ،  <mail> يعد عنصر الجذر لهذا المستند ، و  ، ،  <to>العناصر  <from>الفرعية   . إذا كان مستند XML لا يحتوي على أي عنصر جذر ، فسيتم اعتباره  أو   مستند XML. شيء آخر يجب تذكره هو أن XML هي لغة حساسة لحالة الأحرف. إذا بدأت العلامة على  هذا النحو  ، فيجب أن تنتهي بـ   وليس بشيء مثل  (لاحظ الكتابة بالأحرف الكبيرة  ) مثل HTML ، يمكننا استخدام السمات في XML أيضًا. صيغة امتلاك السمات مشابهة جدًا أيضًا لـ HTML. فمثلا:<subject><text>wronginvalid

<to></to></To>T

<text category = "message">You need to learn about XXE</text>

في المثال أعلاه  category هو اسم  message السمة وقيمة السمة.

قبل أن نبدأ في التعرف على XXE ، علينا أن نفهم ما هو DTD في XML .

DTD تعني تعريف نوع المستند. يحدد DTD البنية والعناصر والسمات القانونية لوثيقة XML .

دعونا نحاول فهم هذا بمساعدة مثال. لنفترض أن لدينا ملفًا باسم  note.dtd المحتوى التالي:

<!DOCTYPE note [ <!ELEMENT note (to,from,heading,body)> <!ELEMENT to (#PCDATA)> <!ELEMENT from (#PCDATA)> <!ELEMENT heading (#PCDATA)> <!ELEMENT body (#PCDATA)> ]>

الآن يمكننا استخدام DTD هذا للتحقق من صحة معلومات بعض مستندات XML والتأكد من أن ملف XML يتوافق مع قواعد DTD هذا.

على سبيل المثال: يوجد أدناه مستند XML يستخدمه note.dtd

< ؟ xml  version = "1.0"  encoding = "UTF-8" ؟ >

< ! DOCTYPE  note SYSTEM "note.dtd" >

< note >

    < to > falcon < / to >

    < from > feast < / from >

    < العنوان > القرصنة < / العنوان >

    < body > XXE attack < / body >

< / ملاحظة >

الآن دعونا نفهم كيف يقوم DTD بالتحقق من صحة XML . هذا ما تعنيه كل هذه المصطلحات note.dtd  المستخدمة

• ! DOCTYPE note - تحدد عنصر جذر للمستند يسمى  note
• ! ملاحظة ELEMENT - تحدد أن عنصر الملاحظة يجب أن يحتوي على العناصر: "إلى ، من ، العنوان ، النص"
• ! ELEMENT to - تحدد  to العنصر ليكون من النوع "#PCDATA"
• ! ELEMENT from - يحدد  from العنصر ليكون من النوع "#PCDATA"
• ! عنوان ELEMENT - يحدد  heading العنصر ليكون من النوع "#PCDATA"
• ! ELEMENT body - تعريف الجسم  element ليكون من النوع "#PCDATA"

    ملاحظة : #PCDATA تعني بيانات الأحرف القابلة للتحليل.

الآن سنرى بعض حمولة XXE ونرى كيف تعمل.

1) الحمولة الأولى التي نراها بسيطة للغاية. إذا كنت قد قرأت المهمة السابقة بشكل صحيح ، فستفهم هذه الحمولة بسهولة بالغة.

<!DOCTYPE replace [<!ENTITY name "feast"> ]>

 <userInfo>

  <firstName>falcon</firstName>

  <lastName>&name;</lastName>

 </userInfo>

كما نرى ، فإننا نحدد  ENTITY استدعاء  name ونخصص له قيمة  feast. سنستخدم لاحقًا هذا الكيان في التعليمات البرمجية الخاصة بنا.

2) يمكننا أيضًا استخدام XXE لقراءة بعض الملفات من النظام عن طريق تحديد ENTITY وجعله يستخدم الكلمة الأساسية SYSTEM هنا مرة أخرى ، نقوم بتعريف ENTITY بالاسم   ولكن الاختلاف هو أننا نعيِّن قيمته على `SYSTEM` ومسار الملف. إذا استخدمنا هذه الحمولة ، فسيعرض موقع الويب المعرض لخطر XXE (عادةً) محتوى الملف  .

<?xml version="1.0"?>

<!DOCTYPE root [<!ENTITY read SYSTEM 'file:///etc/passwd'>]>

<root>&read;</root>

read

/etc/passwd

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

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

يمكن للزائر المنتظم أن يتمكن من الوصول إلى الصفحات المحمية ، يمكن أن يؤدي إلى ما يلي:

• القدرة على عرض المعلومات الحساسة
• الوصول إلى وظائف غير مصرح بها

OWASP لديها عدد قليل من سيناريوهات الهجوم التي توضح نقاط ضعف التحكم في الوصول:

السيناريو رقم 1:  يستخدم التطبيق بيانات لم يتم التحقق منها في مكالمة SQL التي تصل إلى معلومات الحساب:

pstmt.setString (1، request.getParameter ("acct")) ؛

نتائج ResultSet = pstmt.executeQuery () ،

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

http://example.com/app/accountInfo؟acct=notmyacct

السيناريو رقم 2:  يقوم المهاجم ببساطة بإجبار التصفح على عناوين URL المستهدفة. حقوق المسؤول مطلوبة للوصول إلى صفحة المسؤول.

http://example.com/app/getappInfo

http://example.com/app/admin_getappInfo

إذا كان بإمكان مستخدم غير مصادق الوصول إلى أي من الصفحتين ، فهذا خطأ. إذا كان بإمكان غير المسؤول الوصول إلى صفحة المسؤول ، فهذا خطأ ( إشارة إلى السيناريوهات ).

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

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

على سبيل المثال ، لنفترض أننا نسجل الدخول إلى حسابنا المصرفي ، وبعد التحقق من صحة أنفسنا بشكل صحيح ، تم توجيهنا إلى عنوان URL مثل  https://example.com/bank؟account_number=1234 . في تلك الصفحة ، يمكننا رؤية جميع التفاصيل المصرفية المهمة ، ويفعل المستخدم كل ما يحتاج إلى القيام به ويتحرك في طريقه معتقدًا أنه لا يوجد شيء خاطئ.

ومع ذلك ، هناك مشكلة كبيرة محتملة هنا ، فقد يتمكن المخترق من تغيير معلمة account_number إلى شيء آخر مثل 1235 ، وإذا تم تكوين الموقع بشكل غير صحيح ، فسيكون بإمكانه الوصول إلى المعلومات المصرفية الخاصة بشخص آخر.

خطأ في التكوين الأمني

تختلف التكوينات الخاطئة للأمان عن الثغرات الأمنية العشرة الأخرى ، لأنها تحدث عندما كان من الممكن تكوين الأمان بشكل صحيح ولكن لم يتم تكوينه.

تتضمن التكوينات الخاطئة للأمان ما يلي:

• أذونات مهيأة بشكل سيئ على الخدمات السحابية ، مثل حاويات S3
• تمكين الميزات غير الضرورية ، مثل الخدمات أو الصفحات أو الحسابات أو الامتيازات
• الحسابات الافتراضية بكلمات مرور لم تتغير
• رسائل الخطأ المفصلة بشكل مفرط وتسمح للمهاجمين بمعرفة المزيد عن النظام
• عدم استخدام رؤوس أمان HTTP ، أو الكشف عن الكثير من التفاصيل في الخادم: رأس HTTP

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

لمزيد من المعلومات ، أوصي بإلقاء نظرة على أفضل 10 مدخلات لـ OWASP للتكوين الخاطئ للأمان

كلمات المرور الافتراضية

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

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

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

في أكتوبر 2016 ، تم إلغاء اتصال Dyn ( مزود DNS ) بواحدة من أكثر هجمات DDoS التي لا تنسى في السنوات العشر الماضية. جاء تدفق حركة المرور في الغالب من إنترنت الأشياء وأجهزة الشبكات مثل أجهزة التوجيه وأجهزة المودم المصابة ببرامج Mirai الضارة.

كيف استولت البرامج الضارة على الأنظمة؟ كلمات المرور الافتراضية. تحتوي البرامج الضارة على قائمة مكونة من 63 زوجًا من اسم المستخدم / كلمة المرور ، وحاولت تسجيل الدخول إلى خدمات telnet المكشوفة.

كان هجوم DDoS ملحوظًا لأنه استغرق العديد من مواقع الويب والخدمات الكبيرة في وضع عدم الاتصال. أصبحت Amazon و Twitter و Netflix و GitHub و Xbox Live و PlayStation Network والعديد من الخدمات الأخرى غير متصلة بالإنترنت لعدة ساعات في 3 موجات من هجمات DDoS على Dyn.

مثال عملي

يعرض VM هذاSecurity Misconfiguration ، كجزء من قائمة OWASP Top 10 Vulnerabilities.

انشر الجهاز الظاهري واختراقه من خلال استغلال التهيئة الخاطئة للأمان!