حمله‌ی XSS چیست؟

"اپلیکیشن ما می‌تواند به کاربران و اطلاعاتی که آنها ارائه می‌دهند اعتماد داشته باشد"

در مورد جمله‌ی بالا چه فکر می‌کنید؟ این جمله از چه کسی می‌تواند باشد؟ درمورد چه اپلیکیشنی این جمله گفته شده است؟ مارک زاکربرگ و اپلیکیشن فیسبوک؟ آیا این جمله از تیم کوک و اپلیکیشن‌های تولیدی کمپانی وی است؟

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

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

در سال 2014 حمله Cross Site Scripting یا به شکل مختصر XSS، در تست‌های امنیتی اپلیکیشن‌های تحت وب، به عنوان بیشترین مورد آسیب پذیری در این اپلیکیشن ها شناخته شد. همچنین OWASP بزرگترین اجتماع آزاد آنلاین امنیت اپلیکیشن‌های تحت وب، لیستی شامل ده نقص و مشکل که گریبان گیر اپلیکیشن های تحت وب است، بر اساس میزان شیوع و تأثیر آنها در تجارت و کسب و کار معرفی کرده است که رتبه سوم این لیست متعلق به XSS است.

موارد بالا اهمیت XSS را نشان می‌دهند که تقریبا تمام اپلیکیشن‌های تحت وب باید برای برخورد با این حمله آمادگی داشته باشند چون کاملا در معرض آن قرار دارند.

به شکل خلاصه آسیب پذیری XSS میتواند در هر جایی از اپلیکیشن رخ دهد که در آن، اطلاعات از یک منبع خارجی مانند ورودی کاربر به اپلیکیشن داده شوند و آن اطلاعات پتانسیل حمل کد اجرایی مانند جاوا اسکریپت را دارا باشند که ذاتا میتوانند خطرناک عمل کنند.

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

به طور کلی حمله‌ی XSS به دو دسته ی اصلی تقسیم میشود:

Non-Persistant XSS یا Reflected XSS
Persistant XSS یا Stored XSS

نوع اول از حمله‌ی XSS یا همان Reflected XSS بیشتر در صفحاتی اتفاق می افتد که اطلاعات بدون بررسی از فرم های Html گرفته می شوند و در صفحه به نمایش درمی آیند. فرض کنید در یک صفحه‌ی جستجو، یک Input قرار داده شده است که وظیفه‌ی گرفتن کلمات کلیدی برای جستجوی پایگاه داده را برعهده دارد. اگر صفحات جستجوی معمول را در نظر بگیریم پس از فشار دادن دکمه‌ی جستجو، متن جستجو شده، در یک Label در بالای نتایج جستجو به نمایش درخواهد آمد. اگر داده ورودی را که کاربر در جعبه‌ی متن قرار داده است را با اعتماد کامل بخواهیم در صفحه‌ی html خود به نمایش دربیاوریم، کاربر به راحتی میتواند کوکی‌های ذخیره شده را مشاهده کند. این یک نمونه‌ی ساده از حملات Reflected XSS است. این نوع حمله معمولا از طریق ایمیل یا یک وبسایت بی طرف دیگر مثل یک وبلاگ می‌تواند انجام شود به گونه ای که ایمیل یا صفحه‌ی وب مربوطه حاوی یک URL به وب سایت آسیب پذیر خواهد بود ولی این URL شامل کد مخرب است و کلیک بر روی این لینک، مرورگر کاربر را به اجرای کد مخرب وادار خواهد کرد.

reflectedXSS

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

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

persistantXSS

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

در سال 2005 نوع دیگری از حمله XSS به نام DOM Based XSS معرفی شد. حملات گفته شده در ابتدا زمانی به وجود آمدند که پردازش داده معمولا در سطح سرور انجام میشد به شکلی که اطلاعات (که میتوانست شامل کدهای مخرب نیز باشد) به سمت سرور ارسال می‌شد و سپس به کلاینت به عنوان صفحه درخواست شده برگردانده می‌گشت. بعدها به دلیل اینکه نیاز به راحتی و بهبود تجربه کاری کاربر با وب اپلیکیشن مطرح شد و محبوبیت چنین اپلیکیشن هایی بالا رفت، استفاده از آژاکس برای دریافت اطلاعات در زمان نیاز، نوع دیگری از حمله را مطرح کرد. در اصل این نوع حمله به این دلیل ایجاد شد که کد جاوا اسکریپت نیز توانایی پردازش اطلاعات و رندر کردن صفحات وب را داشت و در اصل راه مقابله با آن نیز جاوااسکریپتی خواهد بود. در سال 2011 حجم بسیاری از پلاگین های JQuery که در قبال این نوع حمله آسیب پذیر بودند، به عنوان یک باگ بزرگ نرم افزاری مطرح شدند. در این حمله از آبجکت هایی که در اختیار جاوا اسکریپت قرار دارند و به آنها DOM گفته میشود، استفاده می شود.

خطرات حمله XSS می‌تواند از در اختیار قرار گرفتن کوکی و Session، دریافت اکانت کاربران تا تغییر محتوای سایت و نصب تروجان متغیر باشد.

راه‌های مقابله با XSS در کل به سه دسته‌ی اصلی تقسیم می‌شوند: