Stored XSS

https://portswigger.net/web-security/cross-site-scripting/stored

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

?What is stored cross-site scripting

cross-site scripting  ذخیره‌شده (که به عنوان second-orderیا persistent XSS نیز شناخته می‌شود) زمانی بروز می‌کند که یک برنامه داده‌هایی را از منبعی نامطمئن دریافت کرده و آن‌ها را به شکلی ناامن در پاسخ‌های بعدی HTTP خود شامل می‌کند.

فرض کنید یک وب‌سایت به کاربران اجازه می‌دهد تا نظرات خود را در پست‌های وبلاگ ارسال کنند، که این نظرات برای سایر کاربران نمایش داده می‌شوند. کاربران نظرات خود را با یک HTTP request  مانند زیر ارسال می‌کنند:

POST /post/comment HTTP/1.1

Host: vulnerable-website.com

Content-Length: 100 

postId=3&comment=This+post+was+extremely+helpful.&name=Carlos+Montoya&email=carlos%40normal-user.net

پس از ارسال این نظر، هر کاربری که پست وبلاگ را مشاهده کند، در پاسخ برنامه چنین چیزی دریافت خواهد کرد:

<p>This post was extremely helpful.</p>

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

<script>/* Bad stuff here... */</script>

در درخواست مهاجم، این نظر به صورت URL-encoded به این شکل خواهد بود:

comment=%3Cscript%3E%2F*%2BBad%2Bstuff%2Bhere...%2B*%2F%3C%2Fscript%3E

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

<p><script>/* Bad stuff here... */</script></p>

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

Impact of stored XSS attacks

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

       از نظر قابلیت بهره‌برداری (exploitability)، تفاوت کلیدی بین بازتاب و stored XSS این است که یک آسیب‌پذیری stored XSS به مهاجم این امکان را می‌دهد که حملات خود را به طور مستقل در داخل خود برنامه انجام دهد. مهاجم نیازی به یافتن راه خارجی برای تحریک کاربران دیگر به انجام درخواست خاصی که شامل exploit او باشد ندارد. بلکه، مهاجم exploit خود را در داخل خود برنامه قرار می‌دهد و به سادگی منتظر می‌ماند تا کاربران با آن مواجه شوند.

       ماهیت مستقل cross-site scripting exploits  ذخیره‌شده به خصوص در مواردی که یک آسیب‌پذیری XSS فقط بر کاربرانی که در حال حاضر به برنامه وارد شده‌اند تأثیر می‌گذارد، اهمیت دارد. اگر XSS بازتابی باشد، حمله باید به طور اتفاقی زمان‌بندی شود: کاربری که به انجام درخواست مهاجم تحریک شده است، در زمانی که وارد نشده است، به خطر نمی‌افتد. در مقابل، اگر XSS ذخیره‌شده باشد، کاربر به طور قطع در زمانی که با exploit مواجه می‌شود وارد شده است.

Read more

Exploiting cross-site scripting vulnerabilities

Stored XSS in different contexts

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

علاوه بر این، اگر برنامه هر گونه اعتبارسنجی یا پردازش دیگری بر روی داده‌ها قبل از ذخیره‌سازی یا در نقطه‌ای که داده‌های ذخیره‌شده به پاسخ‌ها وارد می‌شوند انجام دهد، این امر به طور کلی بر نوع XSS payload که مورد نیاز است تأثیر می‌گذارد.

Read more

Cross-site scripting contexts

How to find and test for stored XSS vulnerabilities

بسیاری از آسیب‌پذیری‌های stored XSS را می‌توان با استفاده Burp Suite's web vulnerability scanner یافت.

آزمایش دستی برای آسیب‌پذیری‌های stored XSS می‌تواند چالش‌برانگیز باشد. شما باید تمامی "entry points"  مربوطه که از طریق آن‌ها داده‌های قابل کنترل توسط مهاجم می‌توانند به پردازش برنامه وارد شوند و تمامی "exit points" که در آن‌ها این داده‌ها ممکن است در پاسخ‌های برنامه ظاهر شوند را آزمایش کنید.

نقاط ورودی به پردازش برنامه شامل:

·        پارامترها یا داده‌های دیگر در query string و message body URL.

·        مسیر فایل URL.

·        HTTP request headers که ممکن است در ارتباط با reflected XSS قابل بهره‌برداری نباشند.

·        هر مسیر خارج از باند (out-of-band routes)که از طریق آن مهاجم می‌تواند داده‌ها را به برنامه وارد کند. مسیرهایی که وجود دارند کاملاً به عملکردی که توسط برنامه پیاده‌سازی شده است بستگی دارند: یک برنامه webmail داده‌های دریافت شده در ایمیل‌ها را پردازش می‌کند؛ یک برنامه که یک Twitter feed نمایش می‌دهد ممکن است داده‌های موجود در توییت‌های شخص ثالث را پردازش کند؛ و یک جمع‌آوری کننده اخبار داده‌های منشاء گرفته از سایر وب‌سایت‌ها را شامل خواهد شد.

نقاط خروجی برای حملات stored XSS تمامی پاسخ‌های HTTP هستند که به هر نوع کاربر برنامه در هر موقعیتی بازگردانده می‌شوند.

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

·        داده‌های ارسال شده به هر نقطه ورودی می‌توانند به صورت اصولی از هر نقطه خروجی منتشر شوند. به عنوان مثال، نام‌های نمایشی ارائه شده توسط کاربر می‌توانند در یک log بررسی نامشخص که فقط برای برخی کاربران برنامه قابل مشاهده است ظاهر شوند.

·        داده‌هایی که در حال حاضر توسط برنامه ذخیره شده‌اند اغلب در معرض خطر بازنویسی شدن به دلیل اقدامات دیگر انجام شده در برنامه هستند. به عنوان مثال، یک تابع جستجو ممکن است لیستی از جستجوهای اخیر را نمایش دهد، که به سرعت با انجام جستجوهای دیگر توسط کاربران جایگزین می‌شوند.

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

       در عوض، یک روش واقعی‌تر این است که به صورت سیستماتیک از طریق نقاط ورودی داده‌ها کار کنید، یک مقدار خاص را به هر یک از آن‌ها ارسال کنید و پاسخ‌های برنامه را برای تشخیص مواردی که مقدار ارسال شده ظاهر می‌شود نظارت کنید. توجه خاصی به عملکردهای مربوط به برنامه مانند نظرات در پست‌های وبلاگ می‌شود. هنگامی که مقدار ارسال شده در یک پاسخ مشاهده می‌شود، باید تعیین کنید که آیا داده‌ها واقعاً در بین درخواست‌های مختلف ذخیره می‌شوند، در مقابل اینکه به سادگی در پاسخ فوری بازتاب می‌شوند.

       هنگامی که پیوندهای بین نقاط ورودی و خروجی در پردازش برنامه شناسایی شد، هر پیوند باید به طور خاص برای تشخیص وجود آسیب‌پذیری stored XSS آزمایش شود. این شامل تعیین زمینه‌ای است که داده‌های ذخیره‌شده در آن ظاهر می‌شوند و آزمایش payloadهای XSS مناسب که برای آن زمینه قابل اجرا هستند. در این مرحله، روش آزمایش به طور کلی مشابه یافتن آسیب‌پذیری‌های reflected XSS است.