دوره SEC542 – بخش سی و هفتم

در این بخش از دوره آموزشی SEC542 از موسسه SANS به آشنایی با فیلترینگ مربوط به آسیب پذیری XSS می پردازیم.

تست‌های فیلتر

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

مثلا اگر انتظار فیلترینگ در اپلیکیشن نداشته باشیم، منطقی است که مستقیما سراغ تست یک XSS PoC برویم. با این حال، روش جامع، رایج و تخصصی این است که ابتدا وجود فیلترها را در اپلیکیشن تست کنیم. با پیشرفت‌های امنیتی در وب‌اپلیکیشن‌ها، بیش از پیش شاهد فیلتر ورودی‌ها (input filtering) و انکدینگ خروجی‌ها (output encoding) می‌باشیم. با این حال فیلترینگ هنوز راه زیادی در پیش دارد.

فیلترهایی که در حال حاضر وجود دارند عمدتا فیلترهای blacklist هستند نه whitelist. به بیان ساده‌تر، فیلتر blacklist با ارائه لیستی از تمام کاراکترهای خطرناک، سعی در مقابله با حملات دارد. نمونه آن فیلترهای ساده‌ای است که اغلب برای کوتیشن (‘) یا براکت‌ها (<>) به کار گرفته می‌شود. وجود انواع مختلف انکدینگ و نیازمندی‌های منطقی اپلیکیشن، پیاده‌سازی درست فیلترهای blacklist را دشوار می‌سازد.

Filter Bypass/Evasion

هدف ما در این مرحله از XSS fuzzing، بدست آوردن درک بیشتر از Input filtering و output encoding اجرا شده توسط اپلیکیشن است. با فهمیدن اینکه چه چیزهایی فیلتر می‌شود و چه چیزهایی فیلتر نمی‌شود، می‌توانیم شانس بیشتری برای بایپس موفق فیلتر یا انکد پیلود داشته باشیم. به این ترتیب با کسب دانش درباره راهکارهای دفاعی اپلیکیشن، پیلود نهایی خود را می‌سازیم.

شاید رایج‌ترین نوع فیلترینگ در تارگت‌های XSS، blacklist کردن کاراکترهای < و > باشد. این فیلتر در اپلیکیشن‌هایی که صاحبان آن نگران وجود آسیب پذیری XSS هستند، رایج می‌باشد. فیلترهای دیگری نیز معمولا مورد استفاده قرار می‌گیرند. متاسفانه، تنها بلاک کردن “>” یا “<” برای جلوگیری از کشف و اکسپلویت XSS کفایت نمی‌کند. ما به عنوان مهاجم می‌توانیم از پیلودهایی استفاده کنیم که به این کاراکترها نیاز نداشته باشند و یا می‌توانیم با انکد کردن دیتا یا روش‌هایی دیگر، فیلترهای blacklist را دور بزنیم.

False Negative های مرورگر

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

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

Write-up های آسیب پذیری XSS

ما باید مراقب باشیم که ناخواسته باعث فیلتر شدن پیلود خود توسط مرورگر نشویم. در نظر گرفتن این احتمال اهمیت زیادی دارد زیرا امکان دارد پیلود ما توسط مرورگر فیلتر شود و ما متوجه وجود آسیب‌پذیری در اپلیکیشن نشویم. در این حالت به یک false negative برخورد می‌کنیم.

اما چطور باید این چالش را حل کنیم؟ چند گزینه وجود دارد. اولین و رایج‌ترین راه، استفاده از مرورگر Firefox است. فیلتر XSS در Firefox هنوز در حال توسعه است (یا شاید هم نه). برای کسب اطلاعات بیشتر در این زمینه می‌توانید به لینک‌های زیر مراجعه کنید:

https://wiki.mozilla.org/Security/Features/XSS_Filter
https://bugzilla.mozilla.org/show_bug.cgi?id=528661

اگرچه Firefox فیلتر XSS ندارد اما از هدر Content-Security-Policy پشتیبانی کرده و به آن احترام می‌گذارد. این هدر می‌تواند حملات XSS را ناپایدار کرده و پیاده‌سازی آن‌ها را با شکست مواجه کند. اما استفاده از این هدر اختیاری بوده و هنوز رایج نشده است.

همچنین استفاده از CSP برای حفاظت در برابر XSS، نیازمند اعمال تغییرات قابل توجهی بر روی معماری اپلیکیشن است. بنابراین کمتر پیش می‌آید که این هدر برای ما مزاحمتی ایجاد کند. جهت کسب اطلاعات بیشتر در این زمینه، به لینک زیر مراجعه کنید:

https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Introducing_Content_Security_Policy

علاوه بر Firefox، ما باز هم گزینه‌های بیشتری در دست داریم. می‌توانیم از یک مرورگر قدیمی که قابلیت فیلتر XSS ندارد استفاده کنیم. البته توجه داشته باشید که این کار در اپلیکیشن‌هایی که از قابلیت‌های جدید استفاده می‌کنند، مشکل‌ساز می‌باشد. نمونه‌هایی از این قابلیت‌ها استفاده از HTML5 یا روش‌های غیر eval() برای پردازش داده‌های JSON می‌باشد.

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

بایپس فیلترهای مرورگر

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

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

خیلی‌ها ممکن است بگویند همانطور که گاهی از ما خواسته می‌شود یک WAF را بایپس کنیم، ممکن است از ما بخواهند مکانیزم‌های حفاظتی مرورگر را نیز بایپس کنیم. اما این دو موضوع با هم متفاوت هستند. WAF مشخصا برای حفاظت از اپلیکیشن به کار گرفته می‌شود، در حالی که مکانیزم‌های امنیتی مرورگر اینگونه نیستند.

فیلترهای XSS مرورگرها اغلب بایپس شده‌اند و اگرچه این کار می‌تواند سرگرمی جالبی باشد اما این هدف اصلی تست نفوذ یک وب‌اپلیکیشن نیست.

مطالب این بخش توسط سرکار خانم فهیمه رضایی تهیه شده است.