برای درک بهتر این مطلب، توصیه می‌شود ابتدا مقاله XSS تزریق اسکریپت از طریق وبگاه چیست؟ را مطالعه نمایید.
نحوه‌ی شناسایی نقاط آسیب‌پذیر در برابر حملات XSS و بررسی آن‌ها
اکثریت‌قریب‌به‌اتفاق نقاط آسیب‌پذیر در برابر حملات XSS را می‌توان به‌سرعت و با اطمینان خاطر (به طور موثق) با استفاده از اسکنر نقاط آسیب‌پذیر وب تحت عنوان بِرب سوئیت شناسایی کرد.
معمولاً روش آزمودن دستی حملات XSS انعکاسی و ذخیره‌شده شامل ارسال یک ورودی منحصربه‌فرد ساده (مانند یک‌رشته حروف عددی کوتاه) به درون هر یک از نقاط ورودی برنامه، شناسایی هر یک از نقاطی که ورودی ارسالی در قالب پاسخ HTTP بازگردانده می‌شود و آزمودن جداگانه‌ی هر یک از نقاط به‌منظور تشخیص توانایی یا عدم توانایی ورودی خوش‌ساخت خود برای اجرای جاوا اسکریپت با نتایج مدنظر است. به‌این‌ترتیب می‌توان محیط رخداد حملات XSS را مشخص کرد و پیام‌بار مناسب و مؤثری برای بهره‌برداری از آن انتخاب نمود.
آزمودن دستی حمله‌ی XSS مبتنی بر DOM که از پارامترهای URL ناشی می‌شود، فرایند مشابهی دارد: استقرار یک ورودی منحصربه‌فرد ساده در پارامتر URL، استفاده از ابزارهای توسعه‌ی مرورگر جهت جستجوی DOM برای این ورودی و آزمودن تمامی نقاط آسیب‌پذیر به‌منظور تشخیص قابلیت یا عدم قابلیت بهره‌برداری از آن‌ها. با تمام این اوصاف، تشخیص انواع دیگر حملات DOM XSS دشوارتر است. جهت شناسایی آسیب‌پذیری‌های مبتنی بر DOM در ورودی‌های غیر مبتنی بر URL (مانند document.cookie) یا سینک‌های غیر مبتنی بر HTML (مانند setTimeout)، هیچ جایگزینی برای بررسی کد جاوا اسکریپت وجود ندارد که نتیجه‌ی این امر می‌تواند بسیار وقت‌گیر باشد. اسکنر نقاط آسیب‌پذیر وب بِرب سوئیت، با ترکیب تجزیه‌وتحلیل ایستا و پویای جاوا اسکریپت، به شکلی قابل‌اطمینان و موثق تشخیص آسیب‌پذیری‌های مبتنی بر DOM را به‌صورت خودکار درآورده است.
سیاست امنیتی محتوا
سیاست امنیتی محتوا مکانیزمی است که مرورگر از آن برای کاهش تأثیر حملات تزریق اسکریپت از طریق وبگاه و برخی آسیب‌پذیری‌های دیگر استفاده می‌کند. اگر برنامه‌ای از سیاست امنیتی محتوا استفاده کند و رفتاری شبیه به حملات تزریق اسکریپت از طریق وبگاه (XSS) در آن دیده شود، وجود این مکانیزم به طور بالقوه می‌تواند در فرایند بهره‌برداری از نقاط آسیب‌پذیر مزاحمت ایجاد کند یا حتی به‌طورکلی مانع از پیشروی آن شود. اغلب اوقات، این سیاست یا مکانیزم دفاعی را می‌توان دور زد تا قابلیت بهره‌برداری از نقاط ضعف زیرساختی (نقایص امنیتی اساسی) فراهم شود.
تزریق نشانه‌گذاری ناتمام
در مواقعی که به دلیل وجود فیلترهای ورودی یا سایر مکانیزم‌های دفاعی، بهره‌برداری کامل از تزریق اسکریپت از طریق وبگاه امکان‌پذیر نیست، برای ربودن داده‌های بین‌دامنه‌ای می‌توان از این تکنیک استفاده کرد. اغلب اوقات می‌توان از این تکنیک جهت ربودن اطلاعات حساس قابل‌مشاهده برای سایر کاربران از جمله توکن‌های CSRF بهره برد که می‌توانند برای انجام اقدامات غیرمجاز از طرف کاربر استفاده شوند.
نحوه‌ی پیشگیری از حملات XSS
جلوگیری از حملات تزریق اسکریپت از طریق وبگاه (XSS) در برخی موارد خاص نسبتاً آسان است، اما این کار بسته به میزان پیچیدگی برنامه و روش‌های آن برای مدیریت داده‌های قابل‌کنترل توسط کاربر می‌تواند بسیار دشوارتر شود.
به‌طورکلی، پیشگیری مؤثر در برابر حملات XSS را می‌توان در ترکیبی از اقدامات امنیتی زیر خلاصه کرد:
فیلتر ورودی به‌محض ورود:
در لحظه‌ای که ورودی کاربر (مانند پر کردن فرم) توسط برنامه دریافت می‌شود، این ورودی باید تاحدامکان بر اساس معیارهای مورد انتظار یا قالب معتبر ورودی بادقت تحت فرایند فیلترینگ (بررسی، اعتبارسنجی و مطابقت‌دهی) قرار گیرد.
رمزنگاری داده هنگام خروج:
در لحظه‌ای که داده‌ی قابل‌کنترل توسط کاربر در قالب پاسخ HTTP آماده‌ی خروج می‌شود، رمزنگاری محتوای خروجی از تفسیرشدن آن به‌عنوان «محتوای فعال یا اجرایی» جلوگیری می‌کند. بسته به زمینه‌ی خروجی، ممکن است اعمال ترکیبی از رمزنگاری HTML، URL، JavaScript و CSS ضرورت داشته باشد.
استفاده از هدرهای مناسب برای پاسخ:
به‌منظور جلوگیری از حملات XSS به محتوای پاسخ‌های HTTP که قرار نیست حاوی HTML یا JavaScript باشند، می‌توان از هدرهای Content-Type و X-Content-Type-Options استفاده کرد تا اطمینان حاصل شود که مرورگرها، پاسخ‌ها را به روش دلخواه ما تفسیر می‌کنند.
استفاده از سیاست امنیت محتوا (CSP):
به‌منظور کاهش شدت هرگونه آسیب‌پذیری در برابر حملات XSS که با وجود اجرای سایر اقدامات پیشگیرانه کماکان پابرجا هستند، می‌توان از سیاست امنیت محتوا به‌عنوان آخرین خط دفاعی استفاده کرد.
سؤالات متداول دررابطه‌با حملات تزریق اسکریپت از طریق وبگاه (XSS)
آسیب‌پذیری‌های XSS تا چه حد رایج هستند؟
آسیب‌پذیری‌های XSS بسیار رایج هستند و احتمالاً رایج‌ترین نوع آسیب‌پذیری امنیتی وب به‌حساب می‌آیند.
حملات XSS تا چه حد رایج هستند؟
کسب اطلاعات موثق در مورد حملات XSS در دنیای واقعی دشوار است، اما احتمالاً تعداد آن‌ها نسبت به سایر حملات کمتر باشد.
تفاوت حملات بین‌سایتی XSS و توکن‌های جعلی CSRF در چیست؟
حملات XSS با دست‌کاری باعث می‌شوند تا وبسایت کد مخرب جاوا را به کاربر قربانی بازگرداند، درحالی‌که توکن‌های CSRF کاربر قربانی را با فریب‌کاری متقاعد به انجام کاری می‌کنند که قصد انجام آن را ندارد.
تفاوت بین حمله‌ی XSS و تزریق SQL چیست؟
حمله‌ی XSS نوعی آسیب‌پذیری در طرف کلاینت است که هدف آن سایر کاربران برنامه‌ی تحت وب است، درحالی‌که SQL injection نوعی آسیب‌پذیری در طرف سرور است که پایگاه‌داده‌ی برنامه‌ی تحت وب را هدف قرار می‌دهد.
نحوه‌ی پیشگیری از حملات XSS در PHP چیست؟
با استفاده از لیست سفید کاراکترهای مجاز و همچنین درنظرگرفتن type hint یا type casting، ورودی‌های خود را فیلتر کنید. با استفاده از htmlentities و ENT_QUOTES برای محیط‌های HTML یا به‌کارگیری دنباله‌های جانشین JavaScript Unicode برای محیط‌های جاوا اسکریپت، خروجی‌های خود را جایگزین (اسکیپ) کنید.
نحوه‌ی پیشگیری از حملات XSS در Java چیست؟
با استفاده از لیست سفید کاراکترهای مجاز، ورودی‌های خود را فیلتر کنید. برای کدگذاری HTML خروجی خود در محیط‌های HTML از یک کتابخانه مانند Google Guava کمک بگیرید یا برای محیط‌های جاوا اسکریپت از دنباله‌های جانشین JavaScript Unicode استفاده کنید.
تفاوت XSS و CSRF در چیست؟
تزریق اسکریپت از طریق وبگاه (یا XSS) مهاجم را قادر می‌سازد تا کد دلخواه جاوا اسکریپت خود را در مرورگر کاربر قربانی اجرا کند.
جعل درخواست بین‌سایتی (یا CSRF) مهاجم را قادر می‌سازد تا کاربر قربانی را متقاعد به انجام اقداماتی کند که قصد انجام آن‌ها را ندارند.
پیامدهای آسیب‌پذیری‌های XSS عموماً جدی‌تر از آسیب‌پذیری‌های CSRF است:
- CSRF اغلب اوقات بر روی بخش خاصی از اقداماتی که کاربر قادر به انجام آن‌هاست، اعمال می‌شود. اکثر برنامه‌ها از مکانیزم دفاعی عمومی CSRF استفاده می‌کنند، اما یک یا دو اقدام که هنوز در معرض حمله قرار دارد را از یاد می‌برند. در مقابل، بهره‌برداری موفق XSSمعمولاً می‌تواند صرف‌نظر از عملکردی که آسیب‌پذیری از آن نشئت‌گرفته است، کاربر را متقاعد به انجام هر کاری که قادر به انجام آن است، بکند.
- CSRF را می‌توان به‌عنوان یک آسیب‌پذیری «یک‌طرفه» در نظر گرفت، زیرا با اینکه فرد مهاجم می‌تواند قربانی را متقاعد به صدور درخواست HTTP کند، نمی‌تواند پاسخ آن درخواست را بازیابی نماید. در مقابل، XSS «دوطرفه» است، ازاین‌جهت که کد مخرب تزریق‌شده‌ی فرد مهاجم می‌تواند درخواست‌های دلخواه به وبسایت صادر کند، پاسخ‌ها را بخواند و حتی داده‌های حساس را به طور مخفیانه به دامنه‌ای خارجی به انتخاب فرد مهاجم (تحت کنترل مهاجم) ارسال کند.
آیا توکن‌های CSRF می‌توانند از حملات XSS جلوگیری کنند؟
در واقع می‌توان با استفاده‌ی مؤثر از توکن‌های CSRF از برخی حملات XSS جلوگیری کرد.
یک آسیب‌پذیری ساده‌ی XSS انعکاسی مانند مورد زیر را در نظر بگیرید که به‌آسانی می‌تواند مورد بهره‌برداری قرار گیرد:
https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>
حال، فرض کنید که تابع آسیب‌پذیر شامل توکن CSRF است:
https://insecure-website.com/status?csrf-token=CIwNZNlR4XbisJF39I8yWnWX9wX4WFoz&message=<script>/*+Bad+stuff+here...+*/</script>
با فرض اینکه سرور به‌درستی اعتبارسنجی توکن CSRF را انجام دهد و درخواست‌هایی که بدون توکن معتبر هستند را رد کند، آنگاه توکن با بهره‌برداری از آسیب‌پذیری XSS مقابله خواهد کرد. نکته‌ی کلیدی در اینجا در نام حمله یعنی «cross-site scripting» نهفته است، حداقل در مدل انعکاسی آن که شامل درخواست «cross-site» است. با جلوگیری از امکان جعل درخواست «cross-site» توسط فرد مهاجم، برنامه از بهره‌برداری آسان از آسیب‌پذیری XSS جلوگیری می‌کند.
در اینجا، چند هشدار قابل‌توجه مطرح می‌شوند:
- اگر آسیب‌پذیری XSS انعکاسی در هر قسمت دیگری از وبسایت، درون تابعی که تحت حفاظت توکن CSRF نیست، وجود داشته باشد، آنگاه، این آسیب‌پذیری XSS به روش عادی قابل‌بهره‌برداری خواهد بود.
- اگر آسیب‌پذیری قابل‌بهره‌برداری XSS در یکی از قسمت‌های وبسایت باشد، آنگاه، این آسیب‌پذیری می‌تواند کاربر قربانی را متقاعد به انجام اقداماتی کند، حتی اگر خود این اقدامات تحت حفاظت توکن‌های CSRF باشند. در این شرایط، کد مخرب فرد مهاجم می‌تواند صفحه‌ی مربوطه را درخواست دهد تا توکن CSRF معتبری دریافت کند و سپس از این توکن برای انجام اقدام حفاظت‌شده استفاده نماید.
- توکن‌های CSRF در برابر آسیب‌پذیری‌های XSS ذخیره‌شده کارایی ندارند. اگر صفحه‌ای تحت حفاظت توکن CSRF، نقطه‌ی خروجی آسیب‌پذیری XSS ذخیره‌شده نیز باشد، آنگاه، این آسیب‌پذیری XSS می‌تواند به روش معمول بهره‌برداری شود که در این صورت پیام‌بار حمله‌ی XSS در هنگام بازدید کاربر از صفحه اجرا خواهد شد.
