Reflected XSS,  Impact,  Contexts, Testing, FAQs | هانت لرن

Cross-site scripting (XSS)

زمان مطالعه :5 دقیقه

Reflected XSS, Impact, Contexts, Testing, FAQs

 

Reflected XSS

https://portswigger.net/web-security/cross-site-scripting/reflected#common-questions-about-reflected-cross-site-scripting

 

      در این بخش، cross-site scripting را توضیح می‌دهیم، تأثیر reflected XSS attacks  را شرح می‌دهیم، و نحوه یافتن آسیب‌پذیری‌های reflected XSS را توضیح می‌دهیم.

 

?What is reflected cross-site scripting

Reflected cross-site scripting (یا  XSS) زمانی رخ می‌دهد که یک برنامه کاربردی داده‌ای را در یک HTTP request دریافت کرده و آن داده را به صورت ناایمن در پاسخ فوری (immediate response) خود قرار می‌دهد.

فرض کنید یک وبسایت دارای یک تابع جستجو (search function)است که عبارت جستجوی ارائه شده توسط کاربر را در یک URL parameter دریافت می‌کند:

https://insecure-website.com/search?term=gift

 

برنامه عبارت جستجوی ارائه شده (supplied search)را در پاسخ به این URL بازتاب می‌دهد:

<p>You searched for: gift</p>

 

با فرض اینکه برنامه هیچ پردازش دیگری بر روی داده‌ها انجام نمی‌دهد، یک attacker می‌تواند حمله‌ای به شکل زیر بسازد:

https://insecure-website.com/search?term=<script>/+Bad+stuff+here...+/</script>

 

این URL منجر به پاسخ زیر می‌شود:

<p>You searched for: <script>/* Bad stuff here... */</script></p>

 

اگر کاربر دیگری از برنامه این URL مهاجم را درخواست کند، اسکریپتی که توسط مهاجم ارائه شده است در مرورگر کاربر قربانی اجرا خواهد شد، در زمینه session آنها با برنامه.

 

Impact of reflected XSS attacks 

      اگر یک attacker بتواند اسکریپتی را کنترل کند که در مرورگر قربانی اجرا می‌شود، معمولاً می‌تواند به طور کامل آن کاربر را در اختیار بگیرد. در میان چیزهای دیگر، مهاجم می‌تواند:

·        هر عملی را که کاربر می‌تواند در برنامه انجام دهد، انجام دهد.

·        هر اطلاعاتی را که کاربر قادر به مشاهده آن است، مشاهده کند.

·        هر اطلاعاتی را که کاربر قادر به تغییر آن است، تغییر دهد.

·        تعاملاتی با سایر کاربران برنامه، شامل حملات مخرب، که به نظر می‌رسد از طرف کاربر قربانی اولیه آغاز شده است، شروع کند.

 

       روش‌های مختلفی وجود دارد که یک attacker ممکن است یک کاربر قربانی را به ارسال درخواستی که کنترل می‌کند، تحریک کند تا یک حمله reflected XSS را تحویل دهد. این شامل قرار دادن لینک‌ها در یک وبسایت کنترل شده توسط مهاجم، یا در وبسایت دیگری که اجازه تولید محتوا می‌دهد، یا ارسال لینک در یک ایمیل، توییت یا پیام دیگر می‌شود. حمله می‌تواند مستقیماً علیه یک کاربر شناخته شده هدف قرار گیرد، یا می‌تواند یک حمله بی‌تفاوت (indiscriminate attack)علیه هر کاربر برنامه باشد.

نیاز به یک مکانیزم تحویل خارجی برای حمله به این معناست که تأثیر reflected XSSعموماً کمتر از  stored XSS شده است، جایی که یک حمله خودکفا می‌تواند در خود برنامه آسیب‌پذیر، تحویل داده شود.

Read more

Exploiting cross-site scripting vulnerabilities

Reflected XSS in different contexts

انواع مختلفی از reflected cross-site scripting  وجود دارد. مکان reflected data در response برنامه تعیین می‌کند چه نوع payloadی برای بهره‌برداری مورد نیاز است و ممکن است تأثیر آسیب‌پذیری را نیز تحت تأثیر قرار دهد.

علاوه بر این، اگر برنامه هر گونه اعتبارسنجی (validation)یا پردازش دیگری بر روی داده‌های ارسالی انجام دهد قبل از بازتاب (reflected)آن، این عموماً بر نوع payload XSS مورد نیاز تأثیر می‌گذارد.

 

Read more

Cross-site scripting contexts

 

How to find and test for reflected XSS vulnerabilities

اکثریت عظیم آسیب‌پذیری‌های reflected cross-site scripting می‌توانند به سرعت و به صورت قابل اعتمادی با استفاده از Burp Suite's web vulnerability scanner  پیدا شوند.

آزمایش دستی برای آسیب‌پذیری‌های reflected XSS  شامل مراحل زیر است:

·        Test every entry point. هر نقطه ورود (entry point)داده را در HTTP requestهای برنامه به صورت جداگانه آزمایش کنید. این شامل parameters یا داده‌های دیگر در URL query string  و message body و مسیر فایل URL می‌شود. همچنین شامل HTTP headers  می‌شود، اگرچه رفتار XSSمانندی که تنها از طریق برخی HTTP headers قابل فعال‌سازی است ممکن است در عمل قابل بهره‌برداری نباشد.

·        Submit random alphanumeric values. برای هر نقطه ورود(entry point)، یک مقدار تصادفی منحصر به فرد ارسال کرده و تعیین کنید آیا مقدار در پاسخ بازتاب داده می‌شود یا خیر. مقدار باید به گونه‌ای طراحی شود که اکثر اعتبارسنجی‌های ورودی را تحمل کند، بنابراین باید نسبتاً کوتاه باشد و تنها حاوی حروف و اعداد باشد. اما باید به اندازه‌ای بلند باشد که احتمال تطابق تصادفی در پاسخ را به شدت کاهش دهد. یک مقدار تصادفی الفبایی عددی حدود ۸ حرف معمولاً ایده‌آل است. می‌توانید از Burp Intruder's number payloads با مقادیر تصادفی hex تولید شده برای ایجاد مقادیر تصادفی مناسب استفاده کنید. و می‌توانید از Burp Intruder's grep payloads settings  برای خودکارسازی پرچم‌گذاری   (automatically flag responses) پاسخ‌هایی که حاوی مقدار ارسال شده هستند استفاده کنید.

·        Determine the reflection context. برای هر مکان در response که مقدار تصادفی بازتاب (reflected)داده شده است، context  آن را تعیین کنید. این ممکن است در متن بین HTML tags، در یک ویژگی tag که ممکن است نقل قول (quoted)شده باشد، در یک رشته  JavaScript، و غیره باشد.

·        Test a candidate payload. بر اساس context بازتاب، یک  XSS payload کاندید اولیه را آزمایش کنید که اجرای JavaScript را فعال می‌کند اگر به صورت تغییرنیافته در پاسخ بازتاب داده شود. ساده‌ترین راه برای آزمایش payloadها ارسال درخواست به Burp Repeater است، درخواست را برای وارد کردن payload کاندید تغییر دهید، درخواست را ارسال کنید، و سپس پاسخ را بررسی کنید تا ببینید آیا payload کار کرده است یا خیر. یک راه کارآمد این است که original random value را در درخواست بگذارید XSS payload کاندید را قبل یا بعد از آن قرار دهید. سپس random value را به عنوان Burp Repeater's response view  تنظیم کنید. Burp هر مکان را که عبارت جستجو در آن ظاهر می‌شود برجسته می‌کند، به شما اجازه می‌دهد تا بازتاب را به سرعت پیدا کنید.

·        Test alternative payloads. اگر XSS payload کاندید، توسط برنامه تغییر داده شده یا به کلی مسدود شده باشد، باید payloadها و تکنیک‌های جایگزین را آزمایش کنید که ممکن است یک حمله XSS کارآمد را بر اساس context of the reflection و نوع اعتبارسنجی ورودی (input validation)که انجام می‌شود، تحویل دهند. برای جزئیات بیشتر، به cross-site scripting contexts مراجعه کنید.

·        Test the attack in a browser. در نهایت، اگر موفق به پیدا کردن یک payload شوید که به نظر می‌رسد در Burp Repeater کار می‌کند، حمله را به یک مرورگر واقعی منتقل کنید (با چسباندن URL در نوار آدرس، یا با تغییر درخواست در Burp Proxy's intercept view) و ببینید آیا JavaScript تزریق شده واقعاً اجرا می‌شود. اغلب، بهتر است برخی JavaScript ساده مانند  alert(document.domain) را اجرا کنید که اگر حمله موفق شود یک پنجره پاپ‌آپ قابل مشاهده (visible popup within)در مرورگر ایجاد می‌کند.

 

Common questions about reflected cross-site scripting

تفاوت بین reflected XSS و stored XSS چیست؟  reflected XSS زمانی رخ می‌دهد که یک برنامه برخی ورودی‌ها را از یک HTTP request دریافت کرده و آن ورودی را به صورت ناایمن در پاسخ فوری جاسازی می‌کند. با stored XSS شده، برنامه به جای آن ورودی را ذخیره کرده و آن را به صورت ناایمن در یک پاسخ بعدی جاسازی می‌کند.

تفاوت بین reflected XSS و self-XSS چیست؟ Self-XSS شامل رفتار برنامه مشابه با reflected XSS عادی است، اما نمی‌تواند به روش‌های عادی از طریق یک URL ساخته شده یا یک cross-domain request فعال شود. به جای آن، آسیب‌پذیری تنها زمانی فعال می‌شود که قربانی خودش payload XSS را از مرورگرش ارسال کند. تحویل یک حمله self-XSS معمولاً شامل فریب اجتماعی قربانی برای چسباندن برخی ورودی‌های ارائه شده توسط مهاجم در مرورگر خودشان است. به همین دلیل، به طور معمول به عنوان یک مسئله کم‌اهمیت و بی‌تأثیر در نظر گرفته می‌شود.

امیر رضا کبریادار

امیر رضا کبریادار

تاریخ انتشار : ۵ مرداد ۱۴۰۳

تست

۰

امیر رضا کبریادار

امیر رضا کبریادار

مشاهده مقاله های بیشتر