قبل از اینکه بریم سراغ حملات xss اول با چندتا مفهوم آشنا بشیم:
cyber security: عمل دفاع از رایانهها،سرورها،دستگاههای تلفن همراه،سیستمهای الکترونیکی،شبکهها و دادهها در برابر حملات مخرب است.همچنین بعنوان امنیت فناوری اطلاعات یا امنیت اطلاعات الکترونیکی شناخته میشود.این اصطلاع در زمینههای مختلف،از تجارت گرفته تا محاسبات تلفن همراه کاربرد دارد.
به چند دسته مختلف تقسیم میشود:
- Network security
- Application security
- Information security
- Operational security
- Disaster recovery and business continuity
- End-user education
attack vector: در cyber security یک attack vector روش یا مسیری است که توسط یک هکر برای دسترسی یا نفوذ به سیستم مورد نظر استفاده میشود.هکرها با بررسی attack vector شناخته شده و تلاش برای سوءاستفاده از آسیبپذیریها برای دسترسی به سیستم موردنظرشان اطلاعات،دادهها و پول افراد و سازمانها رو سرقت میکنند.زمانی که هکر به زیرساخت فناوری اطلاعات یه سازمان دسترسی پیدا کرد،میتواند کد مخرب خودشو نصب کند تا زیرساختهای فناوری اطلاعات رو از راه دور کنترل کند،از سازمان جاسوسی کند و دادهها و منابع مورد نیازشو سرقت کند.
تاریخچه
تاریخچه حفرههای امنیتی در معرض حملههای xss به سال ۱۹۹۶ و سالهای اولیه صفحات وب برمیگردد.هکرها در آن زمان که پروتکل http جا افتاده بود و طراحان وبها از زبان پردازه نویسی یا اسکریپت نویسی (scripting language) مثل جاوااسکریپت استفاده میکردند فهمیدند وقتی کاربران معمولی وارد سایتی میشوند میتوانند به کمک کدنویسی در حفرههای امنیتی سایت،صفحه دیگری را در همان صفحه بازگزاری کنند، سپس با استفاده از جاوااسکریپت، داده های کاربر مانند نام کاربری، گذرواژه و یا کوکی (cookie)ها را بدزدند.
cross-site scripting، که به اختصار به اون xss میگن، نوعی حمله است که در اون اسکریپتهای مخرب به منظور اجرا برروی دستگاه کاربر به وب سایتها و برنامههای وب تزریق میشود.در طی این فرایند از ورودیهای نامعتبر(دادههای وارد شده توسط کاربر)برای تغییر خروجیها استفاده می شود.
برخی از این حملات xss هدف خاصی ندارند.مهاجم(attacker) به سادگی از یک آسیب پذیری در برنامه یا سایت سوءاستفاده میکند و هرکسی که به اندازه کافی بدشانس باشد قربانی میشود.
یک مهاجم میتواند با استفاده از xss اسکریپت مخربی را برای کاربر بیخبر ارسال میکند.مرورگر کاربر راهی ندارد که به این اسکریپت نباید اعتماد کرد و این اسکریپت را اجرا میکند.از آنجاییکه فکر میکند این اسکریپت از یک منبع معتبر آمده، اسکریپت مخرب میتواند به هر کوکی، session tokens یا سایر اطلاعات حساس که توسط مرورگر نگهداری میشود و در آن سایت استفاده میشود، دسترسی پیدا کند.این اسکریپتها حتی میتوانند صفحه HTML را دوباره بنویسند.اما در بسیاری از موارد، xss به روش مستقیمتری انجام میشود، مانند یک پیام ایمیل.
حمله xss میتواند یک برنامه وب یا وبسایت را به یک vector برای ارسال اسکریپتهای مخرب به مرورگرهای وب قربانیان ناشناس تبدیل کند.
حملات xss میتواند از آسیبپذیریها در طیف وسیعی از محیطهای برنامهنویسی از جمله، Flash، VBScript، ActiveX و Javascript استفاده کنند.بیشتر اوقات، xss جاوااسکریپت را هدف قرار میدهد زیرا با زبان اکثر مرورگرها یکپارچه است.
xss چطور کار میکند
تصور کنید فردی پشت کامپیوتر نشسته است.یک مرورگر اینترنت با دهها زبانه، بهطور همزمان باز شده است.
همه این سایتها یک ویژگی مشترک دارند;بدون جاوااسکریپت به سختی امکان پذیر است.
سپس یک کلیک ساده روی بنر تبلیغاتی باعث ایجاد صفحه دیگری میشود.این صفحه حاوی اسکریپتی است که به یک سایت بانکی آنلاین متصل میشود و بی سروصدا پول را از حساب کاربر به کارت مهاجم منتقل میکند.
خوشبختانه مرورگرها بهدلیل SOP(same-origin policy) این امکان را حذف میکنند.این SOP اطمینان میدهد که اسکریپتهای اجرا شده در یک صفحه وب به دادههای اشتباه دسترسی ندارند.اگر اسکریپتها از دامنه دیگری بارگیری شده باشند، مرورگر نمیتواند آنها را اجرا کند.
اما مجرمان سایبری از روشهای مختلفی برای دور زدن SOP و سوءاستفاده از آسیب پذیریهای برنامه استفاده میکنند.در صورت موفقیت آنها باعث میشود مرورگر کاربر یک اسکریپت دلخواه را در یک صفحه مشخص اجرا کند.
حمله به یک وبسایت آلوده
قراراست same-origin policy(SOP) به اسکریپتها اجازه دهد فقط زمانی که اسکریپتی از همان دامنه صفحهای که کاربر در حال مشاهده آن است بارگذاری شود.و در حقیقت، مهاجمان دسترسی مستقیم به سرور مسئولیت صفحه نمایش (server responsible) داده شده توسط مرورگر ندارند.بنابراین مهاجمان چگونه این کار را انجام میدهند<بعنوان مثال، یک موتور جستجوی معمولی هنگام نمایش نتایج جستجو، درخواست(request) کاربر را تکرار میکند.اگر کاربر سعی کند رشته
را وارد کندآیا محتویات صفحه نمایش جستجو منجر به اجرای این اسکریپت میشود و alert با پیام Hi ظاهر میشود؟
این بستگی به آن دارد که توسعهدهندگان برنامه وب چگونه ورودی کاربر را تایید کرده و آن را به یک قالب ایمن
(safe format) تبدیل کند.
مشکل اصلی در این واقعیت نهفته است که کاربران طیف گستردهای از نسخههای مرورگر را اجرا میکنند، از آخرین pre-alpha تا نسخههایی که دیگر پشتیبانی نمیشوند.
هر مرورگر صفحات وب را به شیوهای متفاوت مدیریت میکند.در برخی موارد، حمله xss میتواند زمانی موفقیت آمیز باشد که ورودیها به اندازه کافی فیلتر نشده باشند.بنابراین اولین قدم در حمله xss تعیین نحوه جاسازی دادههای کاربر در یک صفحه وب است.
مرحله دوم این است که مهاجم کاربر را متقاعد کند تا از صفحه خالی بازدید کند.مهاجم باید attack vector را به صفحه منتقل کند.باردیگر، هیچ چیز در اینجا مانع جدی ایجاد نمیکند.وبسایتها اغلب دادهها را بعنوان بخشی از URL میپذیرند.برای پیادهسازی attack vector مهاجمان میتوانند از روشهای مختلف social engineer یا فیشینگ استفاده کنند.
مثال زیر دقیقا چنین رشتهای (که توسط کاربر در درخواست (request) HTTP ارسال شده است) را در پاسخ سرور نمایش میدهد.
protected void doGet(HttpServletRequest request, HttpServletResponse Resp) { String firstName =request.getParameter("firstName"); resp.getWriter.append("<div>"); resp.getWriter.append("Search for " + firstName); resp.getWriter.append("</div>"); }
که مقدار اولین پارامتر URL را که درخواست (request) کاربر ارسال شده است، پردازش میکند.سپس پارامتر را در صفحه وب حاصله نمایش میدهد.
ظاهرا توسعه دهنده انتظار ندارد که چیزی غیر از متن ساده و بدون تگ HTML در پارامتر firstName مشاهده کند.
اگر مهاجم درخواست (request) "http://very.good.site/search?firstName= alert ( Hi) " را ارسال کند صفحه نهایی به این شکل است:
به راحتی میتوانید بررسی کنید که وقتی این قطعه HTML در یک صفحه وب در مرورگر بارگذاری میشود، اسکریپت ارسال شده در پارامتر URL firstName اجرا شود.
در این مورد، جاوااسکریپت مخرب در زمینه سرور آسیبپذیر اجرا میشود.بنابراین اسکریپت میتواند،دامنههای کوکی دامنه، API آن و موارد دیگر دسترسی داشته باشد.البته، مهاجم actual vector را بهگونهای توسعه میدهد که حضور آنها را در صفحه مشاهده شده توسط کاربران مخفی کند.
انواع xss attack
اکثر حملات xss را میتوان به سه دسته تقسیم کرد:
-Stored (persistent).
-Reflected (non-persistent).
-DOM-based XSS (Document Object Model).
در اوایل، دو نوع اصلی xss شناسایی شد:Reflected xss و Stored xss .در سال ۲۰۰۵ آمیت کلاین (Amit klein) نوع سوم xss را تعریف کرد، که آمیت DOM-based xss را ایجاد کرد.این سه نوع xss به شرح زیر تعریف میشوند:
Stored (non-persistent)
xss ذخیره شده معمولا هنگامی رخ میدهد که ورودی در سرور هدف مانند یک پایگاه داده، در یک دیتابیس، در یک message form، visitor log، قسمت نظر کاربران Comment field و ... ذخیره شود.
و سپس یک قربانی میتواند دادههای ذخیره شده را از برنامه وب بازیابی کند بدون اینکه دادههای ارائه شده توسط کاربر ممکن است هرگز حتی از مرورگرها خارج نشود.
Reflected (non-persistent)
Reflected xss زمانی اتفاق میافتد که ورودی کاربر بلافاصله توسط یک برنامه وب در یک پیام خطا نتیجه جستجو یا هر پاسخ دیگری که شامل برخی یا کل ورودیهای ارائه شده توسط کاربر بعنوان بخشی از درخواست (request) است،برگردانده شود،بدون اینکه دادهها برای آنها ایمن باشد در مرورگر رندر شود، و بدون ذخیره دائمی دادههای ارائه شده توسط کاربر، در برخی موارد دادههای ارائه شده توسط کاربر ممکن است هرگز حتی از مرورگر خارج نشود.
DOM-based XSS
همانطور که توسط آمیت کلاین، که اولین مقاله را در مورد این مسئله منتشر کرده است تعریف شده است Dom Based xss شکلی از xss است که در آن کل جریان دادههای آلوده در مرورگر اتفاق میافتد.یعنی منبع داده در Dom است(the source of the data in dom) و جریان داده هرگز از مرورگر خارج نمیشود.
برای سالها، بیشتر مردم این موارد (Stored,Reflected,Dom) را بعنوان سه نوع مختلف xss تصور میکردند، اما در واقع،همپوشانی دارند.شما میتوانید Stored,ReflectedوDom را داشته باشید.
همچنین میتوانید xss مبتنی بر Reflected را نیز داشته باشید، اما این مسئله گیج کننده است، بنابراین برای کمک به روشن شدن موارد، از اواسط سال 2012، جامع تحقیقاتی دو اصطلاح جدید را برای کمک به سازماندهی انواع xss که ممکن است ایجاد کند، پیشنهاد و شروع به استفاده کرد:
-Server XSS
-Client XSS
Server XSS
سرور xss رخ میدهد که دادههای ارائه شده توسط کاربر غیرقابل اعتماد در پاسخ HTTP تولید شده توسط سرور گنجانده شده باشد.منبع این دادهها میتواند از طریق درخواست (request) یا از یک مکان ذخیره شده باشد.به همین ترتیب شما میتوانید Reflected server xss و Stored server xss را داشته باشید.
در این حالت تمام آسیب پذیری در کد سمت سرور است و مرورگر به سادگی پاسخ میدهد و هر اسکریپت معتبری را که در آن تعبیه شده است، اجرا میکند.
Client XSS
client xss زمانی اتفاق میافتد که از دادههای نامعتبر ارائه شده برای بروزرسانی DOM با یک تماس جاوااسکریپت ناامن استفاده میشود.اگر بتوان از جاوااسکریپت برای معرفی جاوااسکریپت معتبر در DOM استفاده کرد، ناامن است.این منبع ایندادهها میتواند از DOM باشد، یا میتواند توسط سرور (از طریق کال کردن AJAX یا لود شدن page) ارسال شده باشد.
منبع نهایی دادهها میتواند از یک درخواست (request) یا از یک مکان ذخیره شده در کلاینت یا سرور باشد.به این ترتیب، شما میتوانید Reflected server xss و Stored server xss را داشته باشیم.
با این تعاریف جدید، تعریف DOM Based xss تغییر نمیکند.xss مبتنی بر Dom به سادگی به زیرمجموعهای از Client xss است،جایی که داده به جای سرور در جایی از DOM قرار دارد.
نحوه جلوگیری از حملات xss
-نرمافزار را بهروز نگهدارید:نرمافزارها باید به دلایل زیادی از جمله رفع اشکالات، بهبود عملکرد، نصب ویژگیهای جدید و patching security vulnerabilities همیشه بروز باشد.بروزرسانی منظم نرمافزار، آسیب پذیریهایی را که سایت یا برنامهای را برای آسیبپذیری xss باز میگذارند،تا حد زیادی کاهش میدهد.
-فیلدهای ورودی را ضدعفونی و معتبر کنید:فیلدهای ورودی رایجترین نقطه ورود اسکریپتهای حمله xss هستند.بنابراین،شما همیشه باید هرگونه اطلاعات ورودی را در فیلدهای داده بررسی و اعتبارسنجی کنید.اگر دادهها بعنوان خروجی HTML برای محافظت در برابر حملات Reflected xss گنجانده شوند،این امر بسیار مهم است.اعتبارسنجی باید هم در سمت کلاینت و هم در سمت سرور بعنوان احتیاط اضافی انجام شود.تایید دادهها قبل از ارسال به سرورها، در برابر persistent xss scripts نیز محافظت میکند.این را میتوان با استفاده از javascript انجام داد.
-Web Application Firewall:یک Web Application Firewall(WAF) میتواند یک ابزار قدرتمند برای محافظت در برابر حملات xss باشد.WAPها میتوانند رباتها و سایر فعالیتهای مخرب را که ممکن است نشان دهنده حمله باشد، فیلتر کنند.سپس حملات میتوانند قبل از اجرای هرگونه اسکریپتی مسدود شوند.
-Content Security Policy:یک (CSP)Content Security Policy میتواند کارکردهایی را که یه وبسایت مجاز به انجام است،تعریف کند.میتوان از آنها برای جلوگیری از پذیرش هرگونه in-line script توسط یک وبسایت استفاده کرد.این ممکن است قویترین روش در اختیار شما باشد زیرا میتواند حملات xss را بهطور کامل مسدود کرده یا حداقل احتمال وقوع آنها را تا حد زیادی کاهش دهد.