WSTG-INPV-02

بررسی Stored Cross Site Scripting

در این بخش از دوره آموزشی OWASP-WSTG به هفتمین بخش از استاندارد WSTG با شناسه WSTG-INPV-02 می پردازیم که مربوط به بررسی Stored Cross Site Scripting می باشد.

خلاصه

آسیب پذیری XSS از نوع ذخیره شده یا Stored Cross Site Scripting خطرناک‌ترین نوع از آسیب پذیری XSS است. برنامه‌های کاربردی وب که به کاربران اجازه ذخیره داده‌ها را می‌دهند، به طور بالقوه در معرض این نوع حمله قرار دارند. در این بخش نمونه‌هایی از XSS ذخیره‌شده و سناریوهای بهره‌برداری مربوطه را نشان می‌دهیم.

XSS ذخیره‌شده زمانی رخ می‌دهد که یک برنامه کاربردی وب، ورودی را از یک کاربر جمع‌آوری می‌کند که ممکن است مخرب باشد و سپس آن ورودی را در یک Data Store برای استفاده بعدی ذخیره می‌کند. در اغلب موارد، ورودی‌هایی که ذخیره می‌شوند به درستی فیلتر نمی‌شوند. در نتیجه، به نظر می‌رسد که داده‌های مخرب، بخشی از وب سایت باشند و در مرورگر کاربر تحت امتیازات برنامه کاربردی وب اجرا شوند.

از آنجا که این آسیب‌پذیری معمولا شامل حداقل دو درخواست برای برنامه کاربردی است، این ممکن است second-order XSS نیز نامیده شود.

از این آسیب‌پذیری می‌توان برای اجرای تعدادی از حملات مبتنی بر مرورگر استفاده کرد از جمله:

• Hijacking مرورگر کاربر دیگر
• ثبت اطلاعات حساس مشاهده شده توسط کاربران برنامه
• اسکن پورت میزبان‌های داخلی (‏”داخلی” در ارتباط با کاربران برنامه کاربردی وب)‏
• تحویل مستقیم اکسپلویت های مبتنی بر مرورگر
• دیگر فعالیت‌های مخرب

XSS ذخیره‌شده یا Stored XSS نیازی به یک لینک مخرب برای بهره‌برداری ندارد. بهره‌برداری موفق زمانی رخ می‌دهد که کاربر از صفحه‌ای با XSS ذخیره‌شده بازدید کند.

فازهای زیر مربوط به یک سناریوی حمله XSS ذخیره‌شده معمول هستند:

• مهاجم کد مخرب را در صفحه آسیب‌پذیر ذخیره می‌کند.
• کاربر در برنامه احراز هویت می‌کند.
• کاربر از صفحه آسیب‌پذیر بازدید می‌کند.
• کد مخرب توسط مرورگر کاربر اجرا می‌شود.

این نوع حمله را می‌توان با چارچوب‌های بهره‌برداری تحت مرورگر مانند BeEF و XSS Proxy نیز مورد بهره‌برداری قرار داد. این چارچوب‌ها امکان توسعه اکسپلویت‌های پیچیده مبتنی بر JavaScript را فراهم می‌کنند.

دوره آموزشی تست نفوذ وب SEC542

XSS ذخیره‌شده یا Stored XSS در سطح برنامه‌هایی که کاربران با امتیازات بالا به آن دسترسی دارند، بسیار خطرناک است. هنگامی که مدیر از صفحه آسیب‌پذیر بازدید می‌کند، حمله به صورت خودکار توسط مرورگر وی اجرا می‌شود. این ممکن است اطلاعات حساسی مانند Session Authorization Tokens را در معرض قرار دهد.

اهداف تست

• شناسایی ورودی ذخیره‌شده که در سمت کلاینت منعکس شده‌است.
• ارزیابی ورودی های پذیرفته شده و Encoding اعمال شده در بازگشت (‏در صورت وجود)‏.

چگونه تست را انجام دهیم

آزمایش جعبه سیاه

فرآیند شناسایی آسیب‌پذیری‌های XSS ذخیره‌شده یا Stored XSS مشابه فرآیند شرح‌داده‌شده در طول تست برای XSS منعکس‌شده یا Reflected XSS می‌باشد.

Input Forms

مرحله اول شناسایی تمام نقاطی ورودی کاربر است که در Back-End ذخیره شده و سپس توسط برنامه نمایش داده می‌شوند. نمونه‌های معمول ورودی کاربر که امکان ذخیره سازی را فراهم می‌کند، شامل موارد زیر است:
User/Profiles page: برنامه به کاربر اجازه می‌دهد تا جزئیات پروفایل مانند نام، نام خانوادگی، نام مستعار، آواتار، تصویر، آدرس و غیره را ویرایش یا تغییر دهد.

Shopping cart: برنامه به کاربر اجازه می‌دهد تا اقلام را در کارت خرید ذخیره کند که بعدا قابل بررسی است.
File Manager: برنامه‌ اجازه بارگذاری فایل‌ها را می‌دهد
Application settings/preferences: برنامه‌ به کاربر اجازه می‌دهد تا مجموعه ای از ترجیحات (preferences) را تنظیم کند.
Forum/Message board: برنامه‌ تبادل پست را بین کاربران فراهم می‌کند.
Blog: اگر برنامه وبلاگ به کاربران اجازه ارسال نظرات را بدهد.
Log: اگر برنامه ورودی برخی از کاربران را در لاگ‌ها ذخیره کند.

Analyze HTML Code

ورودی ذخیره‌شده توسط برنامه به طور معمول در تگ‌های HTML استفاده می‌شود، اما می‌توان آن را به عنوان بخشی از محتوای JavaScript نیز یافت. در این مرحله، درک این که آیا ورودی ذخیره می‌شود و چگونه در متن صفحه قرار می‌گیرد، بسیار مهم است. به طور متفاوت از XSS منعکس‌شده یا Reflected XSS، تست نفوذگر باید هر کانال خارج از باند (out-of-band Channels) را بررسی کند که برنامه از طریق آن ورودی کاربر را دریافت و ذخیره می‌کند.

توجه: تمام حوزه‌های برنامه قابل‌دسترس توسط مدیران باید برای شناسایی حضور هر گونه داده ارسال‌شده توسط کاربران مورد آزمایش قرار گیرند.

مثال: پست الکترونیکی داده‌ها را در index2.phpذخیره می‌کند.

کد HTML مربوط به index2.php که در آن مقدار ایمیل قرار دارد:

در این مورد، تست نفوذگر نیاز به یافتن راهی برای تزریق کد خارج از تگ input به صورت زیر دارد:

Testing for Stored XSS

این امر شامل تست اعتبارسنجی ورودی و کنترل‌های فیلترینگ برنامه است. مثال‌های تزریق پایه در این مورد است:

اطمینان حاصل کنید که ورودی از طریق برنامه ارسال شده‌باشد. این معمولاً شامل غیرفعال کردن جاوا اسکریپت در صورتی که کنترل‌های امنیتی سمت کلاینت اجرا شود یا درخواست HTTP را با یک پروکسی وب تغییر می‌دهد. همچنین مهم است که همان تزریق را با هر دو درخواست HTTP GET و POST آزمایش کنید. تزریق بالا منجر به نمایش یک پنجره popup حاوی مقادیر کوکی می‌شود.

کد HTML پس از تزریق:

ورودی ذخیره می‌شود و پیلود XSS توسط مرورگر در هنگام بارگذاری مجدد صفحه اجرا می‌شود. اگر ورودی توسط برنامه حذف شود، تست نفودگر باید برنامه را برای فیلترهای XSS آزمایش کند. برای مثال، اگر رشته “SCRIPT” با یک Space یا با یک کاراکتر NULL جایگزین شود، آنگاه این می‌تواند نشانه بالقوه فیلترینگ XSS باشد.

رایت آپ های فارسی باگ بانتی

تکنیک‌های مختلفی به منظور گریز از فیلترهای ورودی وجود دارند که می توان از آن ها به منظور عبور از فیلترینگ اعمال شده، استفاده نمود. به شدت توصیه می‌شود که به صفحه زیر که لیست گسترده‌ای از حملات XSS و صفحات فیلترینگ را فراهم می‌کند، مراجعه شود:

owasp.org/www-community/xss-filter-evasion-cheatsheet

Leverage Stored XSS with BeEF

XSS ذخیره‌شده یا Stored XSS را می‌توان با چارچوب‌های اکسپلویت پیشرفته JavaScript مانندBeEF و XSS Proxy مورد بهره‌برداری قرار داد.

یک سناریوی بهره‌برداری معمول از BeEF شامل موارد زیر است:

• تزریق یک JavaScript hook که با چارچوب اکسپلویت مرورگر مهاجم ارتباط برقرار می‌کند (BeEF)
• انتظار برای مشاهده صفحه آسیب‌پذیری توسط کاربر برنامه
• کنترل مرورگر کاربر برنامه از طریق کنسول BeEF

JavaScript hook می‌تواند با استفاده از آسیب‌پذیری XSS در برنامه کاربردی وب تزریق شود.

مثال: تزریق BeEF در index2.php:

هنگامی که کاربر صفحه index2.php را Load می‌کند، اسکریپت hook.js توسط مرورگر اجرا می‌شود. سپس امکان دسترسی به کوکی‌ها، screenshot کاربر، clipboard کاربر و راه‌اندازی حملات پیچیده XSS وجود دارد.

این حمله به ویژه در صفحات آسیب‌پذیر که توسط بسیاری از کاربران با امتیازات مختلف مشاهده می‌شوند، موثر است.

File Upload

اگر برنامه کاربردی وب اجازه آپلود فایل را می‌دهد، مهم است که بررسی کنیم آیا امکان آپلود محتوای HTML وجود دارد یا خیر. برای مثال، اگر فایل‌های HTML یا TXT مجاز باشند، پیلود XSS می‌تواند در فایل آپلود شده تزریق شود. تست نفوذگر همچنین باید بررسی کند که آیا فایل آپلود شده اجازه تنظیم MIME Type دلخواه را می‌دهد یا خیر.

درخواست HTTP POST زیر برای آپلود فایل را در نظر بگیرید:

این نقص طراحی می‌تواند در حملات مرتبط با مدیریت نامناسب MIME مرورگر مورد بهره‌برداری قرار گیرد. برای مثال، فایل‌های بی‌ضرر مانند JPG و GIF می‌توانند حاوی پیلودXSS باشند و زمانی که توسط مرورگر بارگذاری می‌شوند، اجرا شوند. این امر زمانی امکان پذیر است که MIME Type مربوط به تصویر مانند image/gifرا بتوان بر روی text/html تنظیم کرد. در این مورد، فایل توسط مرورگر کلاینت به عنوان HTML شناخته خواهد شد.

درخواست HTTP POST جعل شده:

همچنین در نظر بگیرید که اینترنت اکسپلورر MIME Type ها را به همان روشی که موزیلا فایرفاکس یا دیگر مرورگرها انجام می‌دهند، اداره نمی‌کند. برای مثال، اینترنت اکسپلورر فایل‌های TXTرا با محتوای HTML به عنوان محتوای HTML کنترل می‌کند.

آزمایش جعبه خاکستری

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

بسته به اطلاعات موجود، به طور معمول توصیه می‌شود که تست نفوذگر بررسی کند که چگونه ورودی کاربر توسط برنامه پردازش می‌شود و سپس در سیستم Back-End ذخیره می‌شود. در این خصوص گام‌های زیر توصیه می‌شوند:

• استفاده از Front-End برنامه و وارد کردن ورودی با کاراکترهای خاص/ نامعتبر
• تجزیه و تحلیل پاسخ های برنامه
• شناسایی حضور کنترل‌های اعتبارسنجی ورودی
• دسترسی به سیستم Back-End و بررسی چگونگی ذخیره سازی ورودی
• تجزیه و تحلیل سورس کد و درک چگونگی ذخیره‌ سازی ورودی‌ها توسط برنامه

اگر سورس کد در دسترس باشد (‏مانند آزمایش جعبه سفید)‏، تمام متغیرهای مورد استفاده در فرم‌های ورودی باید آنالیز شوند. به طور خاص، زبان‌های برنامه‌نویسی مانند PHP،ASP و JSP از متغیرها/توابع از پیش تعریف‌شده برای ذخیره ورودی از درخواست‌های HTTP GET و POST استفاده می‌کنند.

جدول زیر برخی از متغیرها و توابع خاص را برای بررسی در هنگام تجزیه و تحلیل سورس کد نمایش می دهد:

نکته: جدول بالا تنها خلاصه‌ای از مهم‌ترین پارامترها بوده و البته تمام پارامترهای ورودی کاربر باید بررسی شوند.

Tools

• PHP Charset Encoder(PCE)
• Hackvertor
• BeEF
• XSS-Proxy
• Burp Proxy
• XSS Assistant
• OWASP Zed Attack Proxy (ZAP)