نصائح و حيل لاكتشاف الثغرات الامنيه اثناء عمليه الـ Bug Hunting

هذه الثغرات التي تشكل تهديدًا جديًا XSS (Cross-Site Scripting) 

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

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

استكشاف عالم ثغرات XSS: الأنواع و طرق الكشف عنها و منعها

للكشف عن ثغرات الـ XSS يوجد عده طرق لكن قبل الكشف عن الطرق نحتاج اولا الي مخطط لترتيب العمليه :

اختيار الـهدف

اختيار الهدف الذي سنعمل عليه من اهم الخطوات الاوليه و الاكثر اهميه في مرحله الـ Bug Hunting انصحك باختيار احد التطبيقات التي تمتلك العديد من الـ Assets و الـ Subdomains لان هذا سيوسع عمليه البحث لدينا و احتماليه وجود ثغرات في التطبيق تكون اكبر سنجد داخل الـ Scope الخاص بالهدف المختار علامه مميزه و هي ال Wildcard Target و التي يشار لها بالرمز (*) مثل : 

هنا سنجد العديد من ال Assets  و ال Subdomains لهذا التطبيق و اغلبها بداخل الـ Scope لعمليه الـ Bug Hunting 

جمع الـ Subdomains للهدف المختار 

سنستخدم اداه Assetfinder او Subfinder او Amass او Google Dorking لجمع الـ Subdomains  الخاصه بالمعلومات و حفظ جميع الـ Assets في ملف واحد بصيغه txt

الان و بعد الانتهاء من عمليه الـ Scoping لنقوم بالبحث عن الاماكن التي قد تكون مصابه بثغره الـ XSS:

الكشف عن الـ Parameters 

اولا نقوم بجمع الـ Parameters من الـ Subdomains التي قومنا بجمعها و هناك عده طرق منها العمليه اليدويه او باستخدام الادوات 

عند تصفح تطبيق الويب ومشاهدة الـ Parameters المستخدمة واضحة تمامًا أمامك، يمكنك أيضًا اكتشاف المزيد من خلال البحث في HTML Code ال (view-source:) ونموذج DOM (Inspect element) عن مثل هذه الأشياء: <input id='param1' name='param1'> والبدء في بناء قائمة كلمات للاختبار العشوائي. على سبيل المثال، في هذه الحالة، يمكنك تجربة "param1" ك Parameter. يمكنك أيضًا تصفح ملفات .js (بحث عن "var =")

أو يمكنك ببساطة استخدام بعض الادوات مثل Paramspider و waybackurl و غيرهم 

1. Paramspider

git clone https://github.com/devanshbatham/ParamSpider

python paramspider.py –domain target.com

2. Waybackurl

go get github.com/tomnomnom/waybackurls

waybackurls target.com

3. Arjuntool 

git clone https://github.com/s0md3v/Arjun

python arjun.py -u www.domain.com?FUZZ

4. Google Dork - XSS parameters

inurl:q= | inurl:s= | inurl:search= | inurl:query= | inurl:keyword= | inurl:lang= inurl:& site:target[.]com

بعد ان قمنا بجمع الـ Parameters و حفظها في ملف اخر بصيغه txt لننتقل الي الخطوه المنتظره و هي اختبار الـ XSS Payloads

ادخال الـ Payloads في كل مكان 

حاول دائمًا استخدام  XSS Payloads في كل مكان ممكن ليس فقط الـ Parameters التي قمنا بجمعها. قم بتجربة اسمك، وعنوان بريدك الإلكتروني (test+<h2>@test.com)، والسيرة الذاتية الخاصة بك. انظر كيف يتم التعامل معها وعرضها، هل هناك أي تصفية أو تنقية للبيانات؟ لا تستخدم السيناريو الأكثر شيوعًا <script>، لأن معظم تطبيقات الويب تقوم بتنقية هذا النوع من الكود. ابدأ بشيء "غير ضار" مثل <h2>. ستكون هذه الطريقة أكثر نجاحًا خاصة إذا كان يتم استخدام نوع ما من صيغ تحويل ترميز HTML، ويمكنك بناء XSS Payload مؤثر بشكل فعال. 

بعض المصادر التي يمكنك ان تجد فيها الـ XSS Payloads

• https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
• https://gist.github.com/kurobeats/9a613c9ab68914312cbb415134795b45

اختبار XSS و التحقق وفهم التنقيات التي يطبقها التطبيق علي الـ Payloads التي قمنا بادخالها

فهم تصفية XSS (Cross-Site Scripting) أولاً، إذا كنت ترى دائمًا "<script>" أو "%3Cscript%3E" بغض النظر عن الـ Payloads التي تستخدمها، فمن المرجح أن يكون التطبيق غير معرض لثغرة XSS. ومع ذلك، يحب المطورون تطبيق الـ Filters لأسباب مختلفة مما يؤدي إلى خلق فرص XSS. بدلاً من منع HTML Payloads بشكل كامل من خلال الـ (Sanitization/encoding) الصحيح، يختارون تصفية "العلامات الضاره" في علامات HTML. يمكن أن تكون التصفية أحيانًا جيدة بطريقة ما لأنها تعني أنه يمكنك لعب دورك ومحاولة عكس أفكار المطور. من خلال فهم كيف اختار المطور تصفية بعض XSS Payloads، يمكن أن يعطيك فكرة عن مستوى الأمان (ربما يوجد تصفية مماثلة على ثغرة SSRF محتملة؟). فيما يلي بعض الحالات الشائعة عند اختبار XSS وكيفية المضي قدمًا في إنشاء دليل يعمل بشكل صحيح (PoC).

#1

تستخدم  <script>alert(0)</script> وتلاحظ أنه يتم انعكاس "alert(0)" فقط. يمكنك تجربة:

في هذه النقطة، يمكنك البدء في الاستفسار، هل هم يقومون بتصفية بعض علامات HTML؟ جرب Payloads مثل "<script src=//" (بدون إنهاء العلامة) لمعرفة ما إذا كان العلامة "<script>" تم تصفيتها بغض النظر عن الحالة. وفي حالة تصفية "<script>" بغض النظر، هل "<notreal>" (علامة غير حقيقية، هل هي غير مصفاة؟) تعمل؟ بعد ذلك، يمكنك استخدام "<'notreal onpointerrawupdate=alert'0> " و التي تعمل علي متصفح Firefox

#2

عند استخدام  <script>alert(0)</script> وملاحظة أن &lt;script&gt;alert(0)&lt;/script&gt; يتم انعكاسها، يمكنك تجربة بعض الأمور التالية:

1. الاستمرار في التحقق: قد يكون أمرًا محتملًا أن يكون هذا الـ Parameter عرضة لثغرة XSS، لذلك لا تستبعد ذلك بعد. قم بمحاولة اختبار الترميز المختلف مثل %3Cscript%3Ealert(0)%3C%2Fscript%3E حيث قد تكون عملية التصفية تبحث عن الرموز <، ولكن الـ Encoding يتجاوز هذه الفحوصات.
2. تجربة إدخال < بنفسك (ولكن بصورة مشفرة): يمكنك محاولة إدخال < بنفسك، ولكن مشفرة كالتالي %26lt%3Bscript%26gt%3Balert(0)%26lt%3B%2Fscript%26gt%3B. قد يقوم الخادم بمعالجتها ككود HTML صالح في الاستجابة.

#3

الرد يحتوي فقط على جزء من الـ Payload، على سبيل المثال "><script>alert(0)</script>" يعود فقط "><script>.  يمكنك تجربه:

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

الحساب الأول: <script>/*. هذا يبدأ الـ Payload ويعلق كل شيء أدناه بتعليق متعدد

الحساب الثاني: يمكن أن يتم تعيينه لأي شيء.

الحساب الثالث: */</script>. ينهي علامة التعليق المتعدد وينهي الـ Payload.

ثانياً: يتم نشر تعليق من الحساب الثالث لأن أحدث التعليقات تظهر أعلى القائمة. ثم يتم نشر الحساب الثاني الكود البرمجي المراد تنفيذه من خلال نشر التعليق التالي: / alert(0) /. أخيرًا، نترك تعليقًا باستخدام الحساب الأول. نظرًا لأن اسم الحساب الأول "<script>/". حتى يصل إلى تعليقي الذي ينهي التعليق المتعدد وينفذ alert(0). ينهي الحساب الثالث التعليق المتعدد. وهكذا لدينا 3 Payloads متسلسلة تحقق Stored XSS وحلاً جميلاً.

عندما تكون لديك عدد محدود من الأحرف المتاحة، يجب أن تكون إبداعيًا وترى أي خيارات متاحة لك.

مثال:  

<ScRiPt >confirm(1)</ScRiPt> [Blocked]

PFNjUmlQdCA+Y29uZmlybSgxKTwvU2NSaVB0Pg==  [Bypassed]
 

من خلال هذه الخطوات، يتم اختبار التصفية والترميز المستخدم من قبل التطبيق، وقد تساعدك هذه المحاولات في تحديد نقاط الضعف في التصفية وتحديد ما إذا كان التطبيق معرضًا للثغرات المرتبطة بـ XSS (Cross-Site Scripting).