حمله Cross-Site Scripting یا آسیب پذیری XSS چیست؟

زمان مطالعه: 27 دقیقه

هنر تزریق کد در برنامه کاربردی ( Application ) از جذاب‌ترین روش‌های حمله نفوذگران است که بیشترین نشت‌ اطلاعاتی از طریق همین حملات صورت می گیرد. هدف این نوشتار، معرفی یکی از پر استفاده ترین حملات تزریق کد در بین هکر‌ها، یعنی Cross-site scripting می باشد .

در ساده ترین تعریف آسیب پذیری و یا باگ Cross-site scripting را که به اختصار XSS نام می‌برند، تزریق کد‌های مخرب جاوا اسکریپت به یک برنامه کاربردی وب ( Web Application ) گویند . رخنه ای که طبق آمار snyk.io با عنوان ” مشکل در حال رشد ” یاد شده است.
در این نوشتار سعی بر این است که به موارد زیر بپردازیم:

• مروری بر چیستی این آسیب پذیری
• روش‌های کاهش ریسک در مقابل آسیب پذیری XSS
• انواع سناریو‌های نفوذ
• برخی موارد پیرامون آسیب پذیری XSS

توضیحی کوتاه بر JavaScript

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

با توجه به محبوبیت و گسترش این زبان، به سادگی می‌توان گفت که javascript در بیشتر از 90 درصد وب‌سایت‌ها مورد استفاده قرار می‌گیرد.

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

• جاوا اسکریپت به باقی اشیاء صفحه وب دسترسی دارد. این شامل دسترسی به کوکی‌های کاربر می‌باشد که اغلب برای ذخیره توکن‌های نشست مورد استفاده قرار می‌گیرند . این به معنای توانایی نفوذگر برای جعل هویت کاربران است.
• جاوا اسکریپتبا توجه به دسترسی به شی XMLHttpRequest توانایی ارسال درخواست HTTP با محتوا و مقصد دلخواه را دارد.
• جاوا اسکرپیت در برخی از مرورگر‌ها توانایی دسترسی به API‌ های HTML5 را دارد. به عنوان مثال می تواند به موقعیت جغرافیایی کاربر، وب‌کم، میکروفون و حتی پرونده‌های خاصی از سیستم کاربر دسترسی پیدا کند. البته اکثر این دسترسی‌ها نیاز به صدور اجازه به صورت مستقیم توسط کاربر دارد.
• جاوا اسکریپت توانایی دسترسی به DOM مرورگر را دارد. DOM مدلی شی‌گرا با ساختاری درختی از اشیاء موجود در صفحه می‌باشد.

نتیجتا این توانایی‌ها می‌تواند برای نفوذگر مزایای زیادی داشته باشد. مواردی از آن‌ها عبارت است از :

• بدست آوردن اطلاعات احراز هویت
• بدست آوردن اطلاعات خصوصی کاربر
• ارسال درخواست‌های جعلی به واسطه سطح دسترسی کاربر
• ایجاد فرم‌ها و استایل‌ها در وب‌سایت مورد اعتماد کاربر، به منظور فریب

آسیب پذیری XSS چیست؟

XSS مختصر Cross-site scripting که به دلیل متشابه بودن شکل کوته‌نوشت آن با زبان استایل‌دهی CSS آن را XSS می نامند . آسیب پذیری XSS نوعی از حملات تزریق کد است که در آن اسکریپت‌هایی مخرب در برنامه مورد اعتماد کاربر تزریق می شود.

یکی از اصلی‌ترین تفاوت‌های این نوع حمله با باقی حملات تزریق کد، این است که هدف حمله، مستقیما وب‌سایت آسیب پذیر نیست، بلکه کاربران وب‌سایت در معرض تهدید قرار می‌گیرند.

 انواع XSS

آسیب پذیری XSS در ابتدا به دو نوع مجزا Stored و Reflected ( مداوم و غیرمداوم ) تقسیم بندی می شد. ولی در سال 2005 آقای Amit Klein نوع سوم XSS یعنی DOM based را تعریف کرد. در این بخش هدف معرفی انواع XSS است بنابراین تا به اینجا به نام این سه نوع، اکتفا می کنیم و در ادامه نوشتار به صورت جزئی به تعریف این سه نوع می‌پردازیم.

تا سال‌ها اکثر متخصصین انواع XSS را بدین شکل تقسیم بندی می‌کردند. ولی در واقع این سه نوع با هم همپوشانی دارند. به این معنی که شما می‌توانید به هر سه شکل XSS یعنی Stored، Reflected و  Dom based آسیب‌پذیر باشید و همچنین شما می‌توانید فقط به دو نوع از انواع XSS آسیب‌پذیر باشید.
برای فهم بهتر و روشن سازی مسائل در اواسط سال 2012، جامعه تحقیقاتی شروع به استفاده از دو نوع اصطلاح جدید برای سازماندهی انواع آسیب پذیری XSS کرد. این دو اصطلاح عبارت اند از Server XSS و Client XSS.

Server XSS

Server XSS زمانی رخ می‌دهد که کاربر نامعتبر موفق شود وب‌سایت را به تولید داده در پاسخ HTTP وادار کند. منبع این داده‌ها می تواند از یک درخواست و یا مکانی ذخیره شده باشد. بنابراین Server XSS می‌تواند از دو نوع Stored Server XSS و Reflected Server XSS باشد.
در این نوع از XSS کد مخرب از سوی سرور ارائه می‌شود و مرورگر به سادگی کد را اجرا می نماید این یعنی هر اسکریپتی از نظر مرورگر، معتبر است.

Client XSS

Client XSS زمانی رخ می‌دهد که داده کاربر نامعتبر، تلاشی بر بروزرسانی DOM، با یک تماس (call) جاوا اسکریپتی به صورت ناامن داشته باشد.
یک تماس جاوا اسکریپتی زمانی ناامن در نظر گرفته می‌شود که بتواند یک کد جاوا اسکریپت معتبر را به DOM ارائه نماید.
دریافت کد مخرب می‌تواند از DOM مرورگر باشد و یا می‌تواند از سوی سرور ارسال شده باشد ( توسط یک AJAX call و یا بارگذاری صفحه ). همچنین منبع داده می‌تواند از یک درخواست و یا از یک مکان ذخیره شده روی سیستم Client یا Server باشد. بنابراین شما می‌توانید Reflected Client XSS و Stored Client XSS را داشته باشید.
همچنین از آنجایی که DOM Based XSS فقط در سمت Client اجرا می‌شود، در تعریف آن تغییر ایجاد نمی‌شود و به سادگی این آسیب پذیری زیرمجموعه ای از Client XSS می‌باشد.

با این تعاریف Reflected بودن و یا Stored بودن XSS فقط در احتمال وقوع حمله تاثیرگذار است و در طبیعت حمله تغییری ایجاد نمی‌کند.

تا به اینجا با توضیح مختصری به جاوا اسکریپت ، تعریف آسیب پذیری XSS و انواع آن از نظر محل اجرا، توضیحات کلی پیرامون این آسیب پذیری ارائه شد. در ادامه به تعریف جزئی سه نوع Stored، Reflected و Dom Based پرداخته می‌شود.

Stored XSS چیست؟

آسیب پذیری Stored XSS ( Stored در فارسی به معنای ذخیره شده )  که با عناوین ” نوع دوم  XSS” و یا “XSS  مدوام ” هم شناخته می‌شود، هنگامی رخ می‌دهد که برنامه کاربردی اقدام به دریافت اطلاعات و ارسال آن در پاسخ‌های HTTP از طریق یک منبع غیر قابل اعتماد نماید.  برای اجرای یک Stored XSS، کاربر مخرب باید آسیب پذیری را در نقطه ای از برنامه پیدا کرده و در سرور تزریق کند. این نقطه آسیب پذیر حتما باید نقطه‌ای از برنامه باشد که در حال ذخیره سازی اطلاعات است برای مثال فیلد نظرات، تاپیک‌های انجمن‌ها، بخش تماس با ما در وب‌سایت‌ها و …

برای تکمیل مثال‌های ذکر شده، فرض کنید در یک وب‌سایت، کاربر اجازه ثبت نظر خود را در زیر پست‌ها دارد. زمانی که ما به عنوان کاربر اقدام به ثبت یک نظر می نماییم، درخواستی مانند بدنه ( Body ) زیر ارسال می‌شود:

ID=1&Comment=A+Simple+Comment.

با ثبت این نظر، در دفعات بعد هر کاربری که از این پست وب‌سایت بازدید نماید، در پاسخ وب‌سایت قطعه کد زیر را همراه باقی محتویات صفحه دریافت می‌نماید:

<p>A Simple Comment.</p>

با فرض بر عدم پردازش صحیح برنامه، بر داده ارسالی، مهاجم می‌تواند اقدام به ارسال نظراتی مشابه نظر زیر نماید:

<p><script> /* Malicious codes  */ </script></p>

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

• نوشتن کد‌های جاوا اسکریپت
• استفاده از یک منبع، شامل کد‌های جاوا اسکریپت

بنابراین در صورتی که هیچ گونه پردازشی ( sanitize یا escaping ) روی این نوع داده‌ها انجام نشود نفوذگر قادر به تزریق کدهای جاوا اسکریپت یا اجرای حملات Stored XSS می‌باشد.

کشف آسیب پذیری و یا باگ Stored XSS

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

• Burp Suite
• Acunetix
• Netsparker
• Nessus

البته تعداد این ابزار‌ها بسیار بیشتر از تعداد ابزار‌های معرفی شده است ولی تلاش شد که پراستفاده ترین و قابل دسترس ترین ابزارها ذکر گردد. همچنین در مورد ابزار Burp Suite قابل ذکر است که این ابزار صرفا یک ابزار ارزیابی آسیب پذیری نمی‌باشد ولی توانایی این کار را هم دارد.

در کنار این ابزارها، پیشنهاد می‌شود که ارزیابی به صورت دستی هم انجام شود. این بدلیل عدم توانایی ابزار‌های کشف آسیب پذیری در بررسی دقیق برنامه و همچنین ارائه گزارش‌های کاذب ( False Positive ) در بعضی از موارد، می‌باشد.

آزمایش دستی آسیب پذیری Stored XSS می‌تواند چالش برانگیز باشد. شما باید بتوانید تمام نقاط ورود برنامه که مهاجم قابلیت کنترل و تغییر را در آن دارد و ممکن است در برنامه پردازش شود و همچنین تمام نقاط خروج برنامه که ممکن است در پاسخ‌های HTTP ظاهر شود را بررسی نمایید.

نقاط ورودی برنامه که روی آن پردازش انجام خواهد شد عبارت است از:

• پارامتر‌ها و سایر داده‌هایی که در Query ‌های URL یا بدنه درخواست موجود است.
• مسیر فایل‌های URL.
• هدر‌های HTTP که در XSS Reflected قابل استفاده نیستند.
• هر مسیر خارج از برنامه ( Out-of-band ) که از طریق آن مهاجم قابلیت تحویل داده را به برنامه دارد. این مسیر‌ها بسته به نوع کارکرد برنامه، کاملا متفاوت اند و فقط به عملکرد برنامه بستگی دارند. برای مثال: یک برنامه کاربردی ایمیل، داده‌های دریافتی در ایمیل‌ها را پردازش خواهد کرد؛ برنامه‌ای که فید‌هایی را از وب‌سایت‌های دیگر در خود نمایش می‌دهد؛ وب‌سایت‌هایی که امکان جمع آوری اخبار را از وب‌سایت‌های دیگر دارند.

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

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

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

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

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

همچنین باید این موضوع را در نظر بگیرید که آیا مقادیر ارسال شده در حال ذخیره شدن در مکانی خاص می‌باشند و یا فقط انعکاسی ( Reflect ) از مقدار ارسالی اند.

مرحله بعد زمانی می‌باشد که شما تمامی پیوند‌های مربوط به نقاط ورودی و خروجی را در دست دارید. حال باید اقدام به بررسی جداگانه این پیوندها، نسبت به آسیب پذیری XSS نمایید که آیا آسیب پذیری Stored XSS، در این پیوند رخ داده است یا که خیر.
این نیازمند تعیین اینکه دقیقا در چه نقطه‌ای ( Context ) مقدار ارسالی نمایش داده شده است، می باشد. معرفی انواع Context ها، در انتهای نوشتار بررسی خواهد شد.

مثال‌های از آسیب پذیری Stored XSS

داشتن نگاهی درست و درکی کامل از آسیب پذیری‌های XSS  مستلزم مشاهده نمونه‌هایی از این آسیب پذیری در دنیای Bug Hunting می‌باشد. در این بخش برای دید بهتر بر موضوع نمونه‌هایی از سرویس‌های قدرتمند خارجی را نام می‌بریم که به این آسیب پذیری دچار بودند.

آسیب پذیری  Stored XSS در سرویس Google Tag Manager

بهترین روش‌ Sanitize بر روی ورودی‌های کاربر این است در زمان render شدن اطلاعات انجام شود. در بعضی موارد مشاهده می‌شود که برنامه کاربردی، sanitize را زمان ذخیره سازی اطلاعات انجام می‌دهد. دلیل نادرست بودن آن، این می‌باشد که معمولا کاربران مخرب قادر هستند که یک راه جدید، که sanitize روی آن صورت نمی‌گیرد را برای ذخیره‌سازی اطلاعات کشف کنند ( مانند اپلود یک فایل ).

سرویس Google tag maneger یک ابزار SEO می‌باشد که بازاریابان، با هدف افزودن و یا بروزرسانی تگ‌های وب‌سایت خود استفاده می‌نمایند. در سال 2014 آقای پاتریک فارنباخ ( Patrik Fehrenbach ) از شرکت HackerOne آزمایشاتی با هدف کشف آسیب پذیری XSS، بر روی این سرویس انجام داد.
در این سرویس فرم‌های تحت وبی موجود است که کاربر قادر به تعامل با آن می‌باشد. در ابتدا آقای فارنباخ با ایجاد Payload‌های ( در اینجا به معنی کد‌های مخرب ) XSS اقدام به بررسی این آسیب پذیری نمود. Payload‌هایی مانند:

#”><img src=/ onerror=alert(3)

در صورت اجرا شدن این قطعه کد، Payload قادر خواهد بود که در ابتدا تگ HTML فعلی، که مقدار ارسالی کاربر در آن نمایش داده می‌شود را بسته و در مرحله بعد اقدام به تلاش، برای بارگذاری یک تصویر که وجود ندارد، می‌نماید. بدلیل عدم وجود این تصویر، وب‌سایت تلاش می‌کند تا رویداد Onerror را که مقدار آن اسکریپت alert ( یک دستور ساده جاوا اسکریپت ) است، اجرا نماید. بنابراین آقای فارنباخ قادر خواهد بود هر نوع کد جاوا اسکریپت را در وب‌سایت تزریق کند. ولی payload آقای فارنباخ اجرا نشد.

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

در ادامه فایل اپلود شده توسط آقای فارنباخ را مشاهده می‌نماید.

“data”: {
“name”: “#”><img src=/ onerror=alert(3)>”,
“type”: “AUTO_EVENT_VAR”,
“autoEventVarMacro”: {
“varType”: “HISTORY_NEW_URL_FRAGMENT”
}
}

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

آسیب پذیری Stored XSS در سرویس ایمیل Yahoo

Sanitize ورودی‌های کاربران از طریق ویرایش آن‌ها در صورت پیاده سازی غلط، خود می‌تواند مشکل ساز باشد. در این مثال، که از سرویس ایمیل yahoo می‌باشد به همین مشکل پرداخته می‌شود.

ویرایشگر ایمیل Yahoo به کاربران خود اجازه افزودن تصویر از طریق تگ <img> را می‌داد و بر روی داده‌های کاربر sanitize صورت می‌گرفت و این بدین صورت انجام می‌شد که ویرایشگر، داده را توسط حذف ویژگی‌های (attributes) جاوا اسکریپتی، مانند onload و onerror امن سازی می‌نمود. ولی در صورتی که کاربری عمدا تگ‌های <img> ناقض ارسال می‌کرد این روش امن سازی شکست می‌خورد.

اکثر تگ‌های HTML قابلیت دریافت attribute یا صفت را درون تگ دارا هستند که به کاربر اجازه افزودن اطلاعات بیشتری در مورد تگ می‌دهد. برای مثال تگ <img> می‌تواند صفت src را که برای تعیین آدرس تصویر می‌باشد، قبول کند. همچنین این تگ اجازه استفاده از صفات width و height را به کاربر می‌دهد. این صفات برای تعیین طول و عرض تصویر مورد استفاده قرار می‌گیرند.
بعضی از صفاتی که کاربر می‌تواند درون تگ از آن بهره بگیرد از نوع Boolean هستند و نحوه استفاده از آن‌ها بدین شکل است که: در صورت وجود این صفات در تگ، مرورگر مقدار آن‌ها را “True”، و در صورت عدم استفاده، مرورگر مقدار این صفات را “false” در نظر می‌گیرد.

با دانش به این موضوع، آقای جوکو پینن ( Jouko Pynnonen ) دریافت که، در صورت اضافه کردن یک صفت از نوع Boolean و ست کردن یک مقدار، Yahoo مقدار ست شده را حذف، ولی نام صفت و کارکتر مساوی ( = ) را به همان شکل که ارسال شده است باقی می‌گذارد. مثالی از این مورد در زیر ذکر شده است:

<INPUT TYPE=“checkbox” CHECKED=“hello” NAME=“check box”>

در اینجا، تگ INPUT نشان دهنده یک چک باکس می باشد که وضعیت “علامت خورده” و یا “علامت نخورده” آن توسط صفت CHECKED قابل تنظیم است. بر اساس سیاست‌های Sanitize یاهو که در بالا ذکر شد، این خط کد به شکل زیر در می‌آید.

<INPUT TYPE=“checkbox” CHECKED= NAME=“check box”>

این شاید به نظر مضر نیاید. ولی HTML به ما اجازه می‌دهد که در اطراف علامت مساوی، جایی که مقدار صفت‌ها به صورت نقل قول ( ” )  شده نباشد، به هر تعدادی فاصله ( space ) استفاده نماییم. بنابراین بدلیل اینکه این صفت در تگ استفاده شده است و مقداری ندارد مرورگر مقدار آن را True درنظر می‌گیرد.
در مرحله بعد آقای پینن برای Exploit این آسیب پذیری از قطعه کد زیر استفاده نمود.

<img ismap=‘xxx’ itemtype=‘yyy style=width:100%;height:100%;position:fixed;left:0px;top:0px;
 onmouseover=alert(/XSS/)//’>

با توجه به نوع sanitize ای که ایشان از یاهو کشف کرده بود انتظار می‌رود که مقدار ‘xxx’ پس از پردازش حذف گردد. کد ارسالی آقای پینن پس از پردازش به شکل زیر تغییر کرد.

<img ismap= itemtype=‘yyy’style=width:100%;height:100%;position:fixed;left:0px;top:0px;
 onmouseover=alert(/XSS/)//>

با توجه به پیشبینی انجام شده مقدار ‘xxx’ حذف گردید. ولی مشاهده می‌شود در کنار آن، علامت نقل قول انتهایی صفت iteamtype به انتهای عبارت yyy تغییر مکان داد.

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

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

پس از اجرای این کد به دلیل طول و عرض ست شده 100 درصدی روی تگ img، یک تصویر، تمامی صفحه را اشغال می‌نماید و همچنین زمانی که یک کاربر ماوس خود را در صفحه حرکت می‌دهد کد جاوا اسکریپت ( onmouseover=alert(/XSS/) ) اجرا می‌شود.

 

Reflected XSS چیست؟

آسیب پذیری یا باگ Reflected XSS ( در فارسی به معنای منعکس شده ) که با عناوین ” نوع اول XSS ” و یا ” XSS نامداوم ” هم نیز شناخته می‌شود. هنگامی رخ می‌دهد که یک برنامه کاربردی وب، به روشی ناامن اقدام به استفاده و پردازش برروی داده‌های دریافتی از درخواست HTTP نماید.

فرض نمایید که یک وب‌سایت از یک تابع جستجو بهره می‌برد که عبارت جستجو شده توسط کاربر را از طریق URL دریافت می‌نماید :

http://example.com/search?s=Words

و برنامه کاربردی در پاسخ این درخواست صفحه ای با محتوای زیر را نمایش می‌دهد :

<p>نمایش جستجو برای عبارت: Word </p>

با فرض بر عدم پردازش صحیح برنامه، بر داده ارسالی، مهاجم می‌تواند اقدام به ارسال درخواست مانند زیر نماید :

http://example.com/search?s=<script>+/*+Malicious codes +*/+</script>

و در نتیجه برنامه کاربردی پاسخی حاوی محتوای زیر را نمایش خواهد داد :

<p><script> /* Malicious codes  */ </script> نمایش جستجو برای عبارت: </p>

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

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

کشف آسیب پذیری و یا باگ Reflected XSS

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

برای بررسی و کشف آسیب پذیری Reflected XSS به صورت دستی مراحل زیر پشنهاد می‌شود.

• تمامی نقاط ورودی را بررسی نمایید: به صورت جداگانه هر نقطه ورود از طریق درخواست HTTP را مورد آزمایش قرار دهید. این شامل پارامتر‌ها و دیگر داده‌های درون رشته‌های کوئری ( Query String ) URL، بدنه درخواست‌ها، و مسیر فایل URL می‌باشد. همچنین این شامل هدر‌های HTTP می‌باشد. البته، رفتار‌های XSS مانند، فقط در برخی از هدر‌ها ایجاد می‌شوند و ممکن است در عمل قابل پیاده‌سازی نباشند.
• ارسال مقادیر حروفی/عددی تصادفی برای هر نقطه ورود: برای هر نقطه ورود اقدام به ارسال مقادیری تصادفی نمایید و مطمئن شوید که این مقادیر خلاف سیاست‌های Input validation شما نباشد. پس باید نسبتا کوتاه، به اندازه کافی بلند و شامل حروف و اعداد باشد. یک رشته تصادفی شامل اعداد و حروف به طول 8 حرف بنظر ایده‌آل می‌آید. برای آسان سازی این مرحله شما می‌توانید از Intruder ابزار Burp، برای ارسال درخواست‌هایی با مقادیر تصادفی نمایید. و همچنین شما می‌توانید از امکان فیلتر گذاری ( Grep ) در intruder استفاده نمایید تا پاسخ‌هایی که مقادیر ارسالی را منعکس می‌نمایند جداسازی کنید.
• محل انعکاس مقادیر ( Context ) را تعیین کنید: انواع محل‌هایی که ممکن است مقادیر ارسالی در آن انعکاس یابند را همانطور که در پیش گفته شد، می توانید در انتهای نوشتار مطالعه فرمایید. در این مرحله تعیین نمایید هر انعکاس از چه نوعی می‌باشد.
• پیلود‌های اولیه را آزمایش کنید: بسته به محل انعکاس ( context )، پیلود‌هایی را آماده و ارسال نمایید. شما می‌توانید لیستی از این پیلود‌ها را از گیت‌هاب دریافت نماید. همچنین شما می‌توانید با استفاده از Repeater در ابزار Burp روند این کار را تسریع کنید. ایتدا درخواست را آماده و پیلود خود را در ورودی مورد نظر قرار دهید و سپس پس از ارسال با بررسی پاسخ برنامه کاربردی می‌توانید مشاهده کنید که پیلود ارسالی موفق بود یا که خیر. همچنین برای تشخیص موفقیت درخواست ارسالی می‌توانید فیلتری بر اساس پیلود ارسالی بر روی پاسخ‌های برنامه در Burp تنظیم کنید.
• پیلود‌های جایگزین را آزمایش کنید: در صورتی که مشاهده می‌کنید، برنامه در حال حذف یا تغییر و یا مسدود سازی است، تغییراتی را بر اساس Context و مشاهدات خود انجام و دوباره تلاش کنید.
• حمله را در مرورگر بررسی نمایید: در نهایت اگر پیلودی مشاهده شد که در repeater بنظر موفق می‌آید آن را بر روی مرورگری واقعی آزمایش کنید و بررسی کنید که آیا قطعه کد جاوا اسکریپت اجرا می‌شود یا که خیر. پیشنهاد می‌شود که از پیلود‌های ساده مانند Alert بهره بگیرید.

مثال هایی از آسیب پذیری Reflected XSS

• آسیب پذیری Reflected XSS در وب‌سایت خرید عمده ( Wholesale ) Shopify

نیازی نیست که پیلود‌های XSS خیلی پیچیده باشند. اما نیاز است که آن را براساس محل ( Context ) رندر شدن آن‌ها تنظیم کنید. همچنین قرار گرفتن پیلود‌های شما در تگ‌های HTML و یا javascript هم بر این موضوع تاثیر گذارند.

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

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

در این مورد ارسال قطعه کد زیر موفق به اجرای پیلود alert(‘XX’) نشد :

“><script>alert(‘XSS’)</script>

و دلیل آن HTML Encoding، بر روی کارکتر‌های خاص، مانند > و < در این وب‌سایت بود. و این کارکتر‌ها به اشکال &lt; و &gt; نمی‌توانند برای وب‌سایت مشکل ساز شوند.

یک نفوذگر کشف کرد که این ورودی در حال رندر شدن در صفحه، به طریقی ناامن درون دو تگ <script></script> می‌باشد. نفوذگر، احتمالا با خواندن منبع ( source ) صفحه، حاوی کد‌های HTML و javascript مربوط به آن، به این نتیجه رسیده است. شما می‌توانید با وارد کرد view-source:URL در آدرس‌بار مرورگرتان و جایگزین کردن URl مورد نظر با عبارت URL، منبع صفحه را مشاهده نمایید.

پس از اینکه نفوذگر کشف کرد که این ورودی به طریقی ناامن در حال اجرا شدن است از قطعه کد زیر در باکس جستجو Shopify بهره گرفت:

Test’;alert(‘XSS’);’

پیلود موجود در این قطعه کد منجر به ساخت یک alert با محتوای عبارت XSS می‌شود.

اگرچه در گزارش این موضوع مبهم است ولی به احتمال زیاد shopify عبارت جستجو شده را در یک عبارت جاوا اسکریپت، مانند کد زیر استفاده نموده است:

var search_term = ‘<User input>’

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

var search_term = ‘test’;alert(‘xss’); ‘’;

بنابراین نفوذگر موفق به اجرای یک پیلود XSS، روی باکس جستجوی صفحه عمده فروشی shopify شد.

• آسیب پذیری Reflected XSS در ساب دامین‌های MyShopify

یکی از روش‌های نفوذگران برای اجرای حملات Reflected XSS ایجاد یک فرم در وب‌سایت خود می‌باشد. یکی از ویژگی‌های این سناریو امکان اضافه کردن پارامتر در بدنه درخواست HTTP می‌باشد.

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

لازمه موفیقت این نوع حمله این باشد که وب‌سایت آسیب پذیر، در فرم مورد بحث، از توکن‌های CSRF استفاده ننماید.

در این مثال نفوذگری با نام مستعار ishahriyar، آسیب پذیری Reflected XSS را در بخش ثبت نام مشتری کشف کرد. هنگامی که یک مشتری اطلاعات ثبت نام خود، اعم از رمزعبور، نام و نام خانوادگی را با عباراتی کوتاه ثبت کند Myshopify کاربر را به صفحه ای با آدرس *.myshopify.com/account/register منتقل می‌کند که در این صفحه کاربر با خطای مربوطه و داده‌های ارسال شده مواجه می‌شود.

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

ln”><script>alert(1)</script>

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

سپس با خواندن request مربوطه کشف کرد که این صفحه خطا، دارای هیچگونه توکن CSRF نمی‌باشد. بنابراین نفوذگر قادر است با ایجاد یک فرم کاربر را مجاب به اجرای کد مخرب جاوا اسکریپت خود نماید. نمونه ای از صفحه طراحی شده توسط این نفوذگر را در زیر مشاهده می‌نماید:

<html>
<form enctype=’application/x-www-form-urlencoded’ method=’POST’ action=’https://ontoshopper.myshopify.com/account’>
<table>
<tr><td>Form_type<td><td><input type=’text’ value=’create_customer’ name=’form_type’></td></tr>
<tr><td>utf8<td><td><input type=’text’ value=’YES’ name=’utf8’></td></tr>
<tr><td>customer%5Bfirst_name%5D<td><td><input type=’text’ value=’fn"><script>alert(1)</script>’ name=’customer[first_name]’></td></tr>
<tr><td>customer%5Blast_name%5D<td><td><input type=’text’ value=’ln"><script>alert(2)</script>’ name=’customer[last_name]’></td></tr>
<tr><td>customer%5Bemail%5D<td><td><input type=’text’ value=’hackeronehunter@gmail.com’ name=’customer[email]’></td></tr>
<tr><td>customer%5Bpassword%5D<td><td><input type=’text’ value=’’ name=’customer[password]’></td></tr>
</table><input type='submit' value='click'></form>
</html>

این فرم در ابتدا پارامتر‌هایی را که از قبل مقداری مشخص دارند، ایجاد و سپس به صفحه ثبت نام وب‌سایت myshopify ارسال می‌نماید و از آنجایی که در این صفحه از CSRF token استفاده نشده است، کاربر قربانی با ارسال این فرم کد مخرب جاوا اسکریپت را روی سیستم خود اجرا می‌کند.

 

Dom based XSS چیست

همانطور که در قبل ذکر شد، DOM مدلی شی‌گرا با ساختاری درختی از اجزای موجود در صفحه می‌باشد. DOM تقریبا، ظاهری مانند تصویر زیر دارد:

آسیب پذیری Dom based XSS یا نوع سوم XSS معمولا زمانی رخ می‌دهد جاوا اسکریپت داده ای را از منبعی قابل کنترل توسط نفوذگر ( مانند URL ) بگیرد و آن را به یک تابع خطرناک که با عنوان sink شناخته می‌شود منتقل نماید. توابع خطرناک توابعی می‌باشند که از اجرای کد پویا پشتیبانی می‌کند. لیستی از  sink‌های اصلی که می‌تواند منجر به ایجاد آسیب پذیر Dom Based XSS شود را در زیر مشاهده می‌نماید:

• document.write()
• document.writeln()
• document.domain
• element.innerHTML
• element.outerHTML
• element.insertAdjacentHTML
• element.onevent

همچنین توابع Jquery زیر هم می‌توانند منجر به رخ دادن این آسیب پذیری شوند.

• add()
• after()
• append()
• animate()
• insertAfter()
• insertBefore()
• before()
• html()
• prepend()
• replaceAll()
• replaceWith()
• wrap()
• wrapInner()
• wrapAll()
• has()
• constructor()
• init()
• index()
• jQuery.parseHTML()
• $.parseHTML()

این امر نفوذگر را قادر به اجرای کد‌های مخرب جاوا اسکریپت می‌نماید و به آنان اجازه ربودن ( hijack ) حساب سایر کاربران را می‌دهد.

برای ارائه یک حمله Dom based XSS شما باید داده را در یک منبع ذخیره کنید تا در sink پخش و باعث اجرای کد دلخواه شود. رایج ترین منبع برای اجرای Dom based XSS، URL می‌باشد که معمولا به شی window.location دسترسی دارد. نفوذگر می‌تواند پیوندی را برای قربانی ارسال نماید و قربانی را به یک صفحه آسیب پذیر همراه یک پیلود در query string هدایت کند.

کشف آسیب پذیری و یا باگ Dom based XSS

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

ارزیابی HTML sinks

برای ارزیابی Dom XSS در سینک‌های HTML، رشته‌های حروفی/عددی تصادفی را در منبع ( مانند location.search ) قرار دهید. سپس از ابزار Developer مرورگر، برای مشاهده کد‌های HTML استفاده کنید و بررسی کنید که در کدام مکان رشته‌های شما ظاهر شده اند.
شما نیاز دارید، برای هر نقطه ای که رشته شما ظاهر می‌شود تعیین کنید، که محل ( Context ) دقیق آن از چه نوع است و شما باید ورودی خود را براساس محل ظهور آن اصلاح کنید. برای مثال اگر رشته شما در بین دو علامت “ ظاهر گردید با استفاده از یک ” تلاش کنید که از attribute خارج شوید.

توجه داشته باشید که مرورگر‌ها در مورد رمزگذاری این منابع رفتاری متفاوت دارند. برای مثال chrome، firefox و safari، منابع location.search و location.hash را URL-encode خواهند کرد ولی IE و Microsoft edge این رفتار را ندارند. همچنین قابل ذکر است اگر داده شما قبل از پردازش URL-encode شود، احتملا حمله Dom based XSS موفیقت آمیز نخواهد بود.

ارزیابی برای sink‌های اجرای javascript

ارزیابی برای sink ‌های اجرای javascript کمی دشوار تر خواهد بود. در این sink‌ ها، ورودی‌های شما لزوما در DOM ظاهر نخواهد شد. بنابراین شما قادر به جستجوی آن‌ها نیستید. در این روش شما باید از javascript debugger استفاده نمایید تا کشف کنید که ورودی شما، چگونه به sink ارسال می‌شود.

شما باید برای هر منبع احتمالی ( مانند location )، جستجو کنید و کشف کنید که در چه مکانی از صفحه‌های جاوا اسکریپت از آن منبع استفاده شده است.

زمانی که یک منبع مورد استفاده قرار گرفته را یافتید، از javascript debugger برای افزودن break point استفاده نمایید تا دریابید که برنامه از مقدار این منبع چگونه استفاده می‌کند.

گاهی ممکن است کشف کنید که برنامه در حال نسبت دادن ( برابری به زبان ساده تر ) این منبع به یک متغیر است. در این زمان شما باید دوباره با استفاده از تابع جستجو اقدام به تعقیب این متغییر نمایید تا کشف کنید که آیا متغییر به یک sink انتقال داده می‌شود یا خیر.

زمانی که شما کشف می‌کنید که یک sink، داده ای را از این منبع گرفته، می‌توانید با استفاده از javascript debugger مقدار این متغیر را قبل و بعد از ارسال آن به Sink، بررسی کنید.

در انتها به مانند ارزیابی HTML sink با اصلاح ورودی تلاش کنید که یک حمله XSS را پیاده سازی کنید.

نحوه پیشگیری و یا کاهش ریسک در مقابل باگ یا آسیب پذیری‌ XSS

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

عدم پشتیبانی از HTTP TRACE

مهاجم قادر خواهد بود تا داده‌های کوکی را از طریق جاوا اسکریپت حتی در صورت غیرفعال بودن و یا عدم پشتیبانی Client از cookie، بدزدد. این نوع از حمله زمانی رخ می‌دهد که یک کاربر، اسکریپتی مخرب را در مکانی مانند انجمن انتشار دهد و یک کاربر قربانی، روی آن کلیک نماید.
در این زمان یک تماس ناهمزمان HTTP TRACE ایجاد می‌شود و توسط این تماس مهاجم قادر به جمع آوری اطلاعات کوکی کاربر، از طریق دریافت اطلاعات بر روی سروری مخرب خواهد بود. این اطلاعات به نفوذگر اجازه ربودن نشست ( Session HiJack ) کاربر را می‌دهد که با عدم پشتیبانی از HTTP TRACE این خطر تا حد زیادی کاهش می‌یابد.

اعتبار سنجی ورودی ( Validation Input )

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

فرار از کارکتر‌های مشکوک ( Escaping )

Escaping یا به فارسی فرارکردن، به معنی سانسور بعضی از کارکتر‌های مشکوک به حمله، می‌باشد. برای مثال در حملات XSS دو کارکتر > و < بسیار پراستفاده اند.
برای Escape این کارکتر‌ها چند روش می توان پیاده سازی کرد:

• • حذف و عدم نمایش کارکتر‌های مشکوک هنگام پردازش و پاسخ
  • استفاده از HTML Encoding قبل از درج داده در صفحه HTML

Sanitize ورودی‌ها هنگام رندر آن‌ها

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

عدم وارد کردن داده‌های غیرقابل اعتماد در مکان‌های مجاز

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

• • داخل تگ Script : <script> Untrusted Data </script>
  • داخل Comment ‌ها : <!– Untrusted Data –>
  • داخل نام attribute ‌ها : <div Untrusted Data=test>
  • داخل تگ Style : <style> Untrusted Data </style>

محل‌های وقوع و یا Context ‌های Cross-site Scripting

برای کشف و اکسپلویت کردن آسیب پذیری XSS یکی از مهم ترین موراد شناخت Context‌ ها است:

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

بر اساس این جزئیات، شما قادر خواهید بود که چند پیلود XSS منتخب را برگزینید و بررسی کنید که آیا پیلود موثر بوده یا که خیر.

1) XSS در بین تگ‌های HTML

زمانی که XSS Context، در بین تگ‌های HTML می‌باشد، شما باید از تگ‌های HTML ای که برای اجرای جاوا اسکریپت طراحی شده اند بهره بگیرد.

برخی از روش‌های بهره‌گیری از تگ‌های HTML عبارت اند از :

<script> alert(something) </script>

<img src=/ onerror=alert(Something)>

<svg onload=alert(Something)>

<input autofocus onfocus=alert(Something)>

<video src=_ onloadstart="alert(Something)">

<audio src onloadstart=alert(Something)>

2) XSS در attribute‌ های تگ‌های HTML

زمانی که XSS Context در صفات تگ‌های HTML است، ممکن است بتوانید با بستن صفت و شروع یک عبارت جدید، یک حمله موفق XSS را داشته باشید. برای مثال :

"><script>alert(Something)</script>

ولی معمولا در این شرایط عبارت‌های > و <، encode خواهند شد. بنابراین ورودی شما ممکن است قادر به بستن تگ نباشد.
در این زمان، به شرطی که شما بتوانید مقدار attribute را خاتمه دهید، با اضافه کردن یک attribute دیگر قادر خواهید بود یک context اسکریپت نویسی، مانند یک event handler ایجاد کنید. برای مثال:

" autofocus onfocus=alert(something) x="

ویژگی onfocus باعث می‌شود که این عنصر ( تگ مربوطه ) در صورت دریافت متد Focus، مقدار خود را اجرا نماید که در اینجا، در مقدار این صفت، پیلود XSS قرار گرفته است. همچنین صفت autofocus برای ایجاد یک Focus به صورت خودکار استفاده می‌شود و در نهایت صفت x، که در اخر قطعه کد مشاهده می‌کنید، برای کامل کردن قطعه کد پس از قرار گرفتن آن در مقدار attribute، استفاده می‌شود.

در برخی از موارد شما مشاهده می‌کنید XSS Context در نوعی از attribue قرار گرفته که خود می‌تواند زمینه ای برای ایجاد اسکریپت باشد. در این زمان شما قادر خواهید بود که کد جاوا اسکریپت را بدون نیاز به خاتمه دادن مقدار صفت، اجرا کنید. برای مثال اگر XSS Context در صفت href یک تگ پیوندی ( برای مثال تگ a ) قرار گرفته باشد شما می‌توانید از پروتکل شبه جاوا اسکریپت برای اجرا کد بهره بگیرید. برای مثال:

<a href="javascript:alert(Something)">

شما ممکن است با وب‌سایت‌هایی روبرو شوید که عبارات > و < را encode می‌کنند ولی همواره به شما اجازه تزریق در attribute را می‌دهند. گاهی تزریق کد در تگ‌هایی که قابلیت رویداد خودکار را در خود ندارند هم اتفاق می‌افتد. مانند تگ‌های canonical. شما در این تگ‌ها با استفاده از access keys و تعامل کاربر در مرورگر، می توانید آسیب پذیری XSS را اکسپولیت نماید. صفت accesskeys به شما این امکان را می‌دهد که حرفی را تعریف کنید و زمانی که کاربر آن حرف را با کلید‌های دیگر ( در پلیتفرم‌های مختلف این کلید‌ها متفاوت است ) فشار داد، باعث شروع رویداد شود.

3) XSS در javascript

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

4) در بین تگ script پایان دار

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

<script>

...

var input = 'controllable data here';

...

</script>

در این زمان شما می‌توانید با قطعه کد زیر از تگ  script خارج و یک تگ دیگر را باز نمایید.

</script><img src=1 onerror=alert(document.domain)>

دلیل اصلی موفق بودن این قطعه کد این می‌باشد که مرورگر در ابتدا کد‌های HTML شناسایی شده در صفحه را مشاهده می‌کند و سپس به تجزیهو تحلیل کد‌های javascript می‌پردازد.

5) خروج از یک رشته جاوا اسکریپت

در این مورد XSS context درون یک رشته نقل قول شده ( درون “” ) قرار دارد و نفوذگر می‌تواند با بستن این نقل قول بصورت مستقیم اقدام به اجرای جاوا اسکریپت نماید. ولی باید به این نکته توجه شود که پس از پایان پیلود حتما باید کد‌های بعدی جاوا اسکریپت را تعمیر نمود. دلیل آن این می‌باشد که هرگونه خطا ممکن است مانع اجرای جاوا اسکریپت شود.

مثالی از خروج از یک رشته :

';alert(document.domain)//

برخی از برنامه‌ها با ایجاد و متصل کردن کارکتر‌هایی، تلاش می‌کنند که از خروج از نقل قول جلوگیری نمایند. بک اسلش قبل از یک کارکتر، به تجزیه کننده جاوا اسکریپت میگوید که عبارت مورد نظر باید عینا تجزیه شود و این عبارت یک کارکتر خاص ( special character ) برای بستن رشته نمی‌باشد. در این زمان برنامه‌های کاربردی اغلب اشتباه می‌کنند و تفاوتی میان بک اسلش ایجاد شده توسط خود و یا کاربر نمی‌بینند این بدان معنا است که نفوذگر می‌تواند با اضافه کردن یک بک اسلش، کارکتر بک اسلش ایجاد شده توسط برنامه را خنثی نماید.

برای مثال فرض کنید که ورودی ارسالی ما کدی مانند زیر است:

';alert(document.domain)//

و پس از تجزیه و تحلیل به صورت زیر تبدیل می‌شود:

\';alert(document.domain)//

حال نفوذگر می‌تواند با رشته جایگزین زیر اقدام به حمله نماید:

\';alert(document.domain)//

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

\\';alert(document.domain)//

که در اینجا معنی بک اسلش اول این می‌باشد که بک اسلش دوم یک کارکتر است که باید عینا اجرا شود و باقی کد می‌تواند به صورت جاوا اسکریپت اجرا شود.

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

یکی از روش‌های اینکار استفاده از throw می‌باشد. Thoew این قابلیت را به شما می‌دهد که آرگومان‌ها را بدون استفاده از پرانتز به تابع منتقل کنید.

قطعه کد زیر تابع alert() را به exception handler سراسری ( global )، نسبت می‌دهد و دستور thorw عدد 1 را به exception handler صادر می‌کند. و نتیجه آن ارسال alert() و عدد 1 به عنوان آرگ.مان می‌باشد.

onerror=alert;throw 1

6) استفاده از HTML encoding

زمانی که XSS context درون کد جاوا اسکریپتی که نقل قول شده، مانند یک even handler قرار دارد، ممکن است شما بتوانید با استفاده از HTML encoding روی ورودی‌های فیلتر شده آزمایشاتی را انجام دهید.

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

برای مثال در صورتی که XSS context شما مانند زیر است:

<a href="#" onclick=" ...  var input='controllable data here';  ... ">

و برنامه از طریق فیلتر بر روی ورودی‌ها از عبارت ‘ فرار می‌کند ( escaping )، شما می‌توانید از پیلود زیر بهره بگیرید.

'-alert(something)-'

عبارت &apos یک عبارت encode شده توسط HTML می‌باشد که معادل کارکتر ‘ می‌باشد.

و بدلیل HTML-decode مقادیر صفت Onclick توسط مرورگر، رشته بسته شده و پیلود جاوا اسکریپت اجرا خواهد شد.

7) XSS در JavaScript template literals

JavaScript template literals روشی برای تعریف رشته‌ها در جاوا اسکریپت می‌باشد که در آن برنامه نویس می‌تواند به راحتی از رشته‌های چند خطی بهره ببرد. در این روش به جای استفاده از عبارات نقل قول از backticks ( ` ) استفاده می‌شود. همچنین عبارت تعبیه شده با استفاده از syntax زیر مشخص می‌گردد:

${...}

برای مثال خط زیر یک اسکریپت است که به کاربر پیامی برای خوش آمد گویی ارسال می‌کند.

document.getElementById('message').innerText = `Welcome, ${user.displayName}.`;

زمانی که XSS context در JavaScript template literals قرار دارد، دیگر نیازی به بستن عبارت تعریف شده وجود ندارد و نفوذگر به راحتی با استفاده از ${…} ، اقدام به اجرای جاوا اسکریپت می‌نماید.

برای مثال در صورتی که XSS context ما به صورت زیر باشد:

<script>

...

var input = `controllable data here`;

...

</script>

نفوذگر با استفاده از پیلود زیر می‌تواند کد جاوا اسکریپت دلخواه را اجرا نماید.

${alert(something)}

8) XSS در AngularJS sandbox Context

گاهی اوقات آسیب پذیری XSS در AngularJS sandbox Context رخ می‌دهد که برای نفوذگر موانع زیادی را به ارمغان می‌آورد. نحوه و روش اکسپلویت کردن از طریق این Context از اهداف این نوشتار نمی‌باشد.

تاثیر و عواقب عدم توجه به آسیب پذیری Cross site scripting یا XSS

تاثیرات آسیب پذیری XSS عموما به صورت مستقیم کاربران وب‌سایت را مورد هدف قرار می‌دهد ولی از تاثیرات منفی این آسیب پذیری برای مدیران یک وب‌سایت می توان به موارد زیر اشاره کرد:

• تاثیر روی شهرت یک تجارت
• تخریب وجه سازمانی
• عدم اعتماد دوباره کاربران پس از وقوع حمله
• امکان وقوع این حمله برای کاربران با سطح دسترسی بالا

در کنار این موارد لیستی از اقدامات احتمالی توسط نفوذگر پس از کشف آسیب پذیری XSS را در زیر مشاهده می‌نمایید:

• ربودن و یا hijack حساب کاربران
• بدست آوردن اطلاعات احراز هویتی
• افشای اطلاعات محرمانه
• نصب بدافزار‌ها روی کامپیوتر‌های مشتریان
• دسترسی به کامپیوتر‌های مشتریان
• حذف داده‌های کاربران
• انجام حملات فیشینگ ( phishing )
• کمک به پیاده سازی سایر حملات

چگونه خود در برابر این آسیب پذیری امن کنیم

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

سوالات متداول در مورد آسیب پذیری Cross site scripting و یا باگ XSS

جمع بندی نهایی :

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

به عنوان مشاوران امنیتی باید بگوییم که XSS در مورد ظاهر شدن یک Alert ساده نیست بلکه می‌تواند برای ما مشکلات بزرگ تری را رقم بزند.