فرض کنید وارد یک Web Application (برنامه وب) میشوید و در بخش Search، Comment یا حتی Profile یک مقدار ساده وارد میکنید. همهچیز عادی به نظر میرسد؛ اما اگر Application نتواند User Input (ورودی کاربر) را بهدرستی پردازش کند، همین ورودی ساده میتواند به نقطه شروع یک حمله تبدیل شود.
در Cross-Site Scripting (XSS)، مهاجم تلاش میکند Malicious Script (اسکریپت مخرب) را وارد جریان عادی Application کند؛ به شکلی که این کد در Browser (مرورگر) قربانی اجرا شود. از اینجا به بعد، بسته به شرایط Application و Privilege (سطح دسترسی) کاربر، مهاجم میتواند روی تعامل کاربر با سایت تأثیر بگذارد و به اطلاعات یا قابلیتهایی که در دسترس او هستند دسترسی پیدا کند.
اما XSS فقط یک () alert ساده نیست. برای اینکه واقعاً این آسیبپذیری را بشناسیم، باید ببینیم Payload (داده مخرب) از کجا وارد میشود، Application Web چطور آن را پردازش میکند، چه اتفاقی در Browser رخ میدهد و در نهایت این حمله چه Impact (پیامدی) برای کاربر و سازمان دارد. در این مقاله، XSS را قدمبهقدم بررسی میکنیم؛ از نحوه شکلگیری و اجرای حمله گرفته تا انواع XSS، Attack Flow (جریان حمله)، روشهای Detection (شناسایی)
XSS چیست و دقیقاً چه اتفاقی در Browser میافتد؟
Cross-Site Scripting (XSS) یکی از آسیبپذیریهای مهم در Web Security (امنیت وب) است. این آسیبپذیری زمانی شکل میگیرد که یک Web Application (برنامه وب) ورودی کاربر را بهدرستی پردازش نکند و مهاجم بتواند محتوایی را وارد صفحه کند که Browser (مرورگر) آن را بهعنوان کد قابل اجرا تفسیر کند.
برای مثال، کاربر ممکن است در یک بخش مثل Search یا Comment فقط یک متن ساده وارد کند. اما اگر Application این User Input (ورودی کاربر) را بدون Output Encoding (کدگذاری خروجی) مناسب در صفحه قرار دهد، مهاجم میتواند آن را به شکلی دستکاری کند که Malicious Script (اسکریپت مخرب) در Browser اجرا شود.
در این مرحله، نکته مهم این است که Script در Browser قربانی و در Context (بافت اجرایی) همان Web Application اجرا میشود. بنابراین بسته به شرایط، مهاجم میتواند از Session (نشست) و Privilege (سطح دسترسی) کاربر سوءاستفاده کند.
انواع XSS؛ سه مسیر مختلف برای اجرای کد
بهطور کلی، XSS را میتوان به سه نوع اصلی تقسیم کرد. تفاوت اصلی این سه نوع در این است که Payload (داده مخرب) از کجا وارد Application میشود و در کدام بخش پردازش میشود.
1. Reflected XSS — XSS بازتابی
در Reflected XSS، Payload از طریق یک HTTP Request (درخواست HTTP) به Application ارسال میشود و Application همان ورودی را در HTTP Response (پاسخ HTTP) برمیگرداند.
در صورتی که این ورودی به شکل امن پردازش نشده باشد، ممکن است JavaScript در Browser قربانی اجرا شود.
2. Stored XSS — XSS ذخیرهشده
در Stored XSS، Payload مستقیماً در Application ذخیره میشود؛ مثلاً در یک Database (پایگاه داده)، Comment یا Profile.
بعداً وقتی کاربر دیگری آن صفحه را مشاهده میکند، Application داده ذخیرهشده را برای او ارسال میکند و در صورت وجود آسیبپذیری، Payload در Browser قربانی اجرا میشود.
2. Stored XSS — XSS ذخیرهشده
در Stored XSS، Payload مستقیماً در Application ذخیره میشود؛ مثلاً در یک Database (پایگاه داده)، Comment یا Profile.
بعداً وقتی کاربر دیگری آن صفحه را مشاهده میکند، Application داده ذخیرهشده را برای او ارسال میکند و در صورت وجود آسیبپذیری، Payload در Browser قربانی اجرا میشود.
XSS چگونه کار میکند؟
برای درک بهتر XSS، بهتر است مسیر اتفاق را از ابتدا دنبال کنیم.
همهچیز معمولاً با یک User Input (ورودی کاربر) شروع میشود. مهاجم ورودیای را به Application ارسال میکند که حاوی محتوای مخرب است. اگر برنامه نتواند این داده را بهدرستی Validate (اعتبارسنجی) یا Encode (کدگذاری) کند، ممکن است همان داده را در HTTP Response (پاسخ HTTP) یا DOM (ساختار صفحه در مرورگر) قرار دهد.
حالا Browser این Response یا DOM را پردازش میکند. اگر ورودی در یک Context (بافت) قابل اجرا قرار گرفته باشد، ممکن است Browser آن را بهعنوان JavaScript تفسیر و اجرا کند.
بهصورت ساده، مسیر حمله را میتوان اینطور دید:
- Attacker (مهاجم)
- Malicious Input (ورودی مخرب)
- Vulnerable Web Application (برنامه وب آسیبپذیر)
- Unsafe Processing (پردازش ناامن)
- Victim Browser (مرورگر قربانی)
- JavaScript Execution (اجرای JavaScript)
- Impact (پیامد حمله)
بنابراین، اصل XSS این نیست که مهاجم صرفاً یک Script ارسال میکند؛ مسئله اصلی این است که Application به Browser اجازه میدهد داده تحت کنترل مهاجم را بهعنوان کد قابل اجرا تفسیر کند.
XSS چه کاری میتواند برای مهاجم انجام دهد؟
وقتی یک XSS Vulnerability (آسیبپذیری XSS) با موفقیت Exploit (بهرهبرداری) شود، کار مهاجم فقط به اجرای یک Script ساده محدود نمیشود. اینکه مهاجم دقیقاً چه کاری بتواند انجام دهد، به Web Application (برنامه وب)، اطلاعات موجود در آن و Privilege (سطح دسترسی) قربانی بستگی دارد.
مهاجم ممکن است بتواند:
- Impersonation (جعل هویت): خودش را در نقش کاربر قربانی قرار دهد و از User Context (محیط کاربری) او استفاده کند.
- Unauthorized Actions (اقدامات غیرمجاز): اقداماتی را انجام دهد که قربانی خودش مجاز به انجام آنهاست.
- Data Access (دسترسی به داده): اطلاعاتی را که برای قربانی قابل دسترسی است، مشاهده یا استخراج کند.
- Credential Capture (دریافت اطلاعات ورود): در برخی سناریوها اطلاعات Authentication (احراز هویت) کاربر را هدف قرار دهد.
- Virtual Defacement (تغییر ظاهری سایت): محتوای صفحه را تغییر دهد و چیزی متفاوت به کاربر نمایش دهد.
- Malicious Functionality Injection (تزریق قابلیت مخرب): قابلیت یا کد مخربی را به صفحات Application اضافه کند و کاربران دیگر را نیز تحت تأثیر قرار دهد.
بنابراین، Impact (پیامد) یک XSS به شرایط حمله وابسته است. یک XSS در یک سایت ساده ممکن است فقط باعث تغییر محتوای صفحه شود، اما همان آسیبپذیری در یک Application حساس و برای یک کاربر با Elevated Privileges (سطح دسترسی بالا) میتواند به یک Security Incident (رخداد امنیتی) جدی تبدیل شود.
بررسی Context در حملات XSS
وقتی در یک Web Application (برنامه وب) یک ورودی قابلکنترل توسط کاربر پیدا میکنیم، هنوز نمیتوانیم بگوییم که XSS وجود دارد. یک سؤال مهم باقی میماند:
این ورودی دقیقاً کجای صفحه قرار میگیرد؟
به این محل قرارگیری میگوییم Context (بافت).
مثلاً فرض کنید مقدار زیر را وارد کردهایم:
erfan
Application ممکن است آن را داخل HTML قرار دهد:
<p>erfan</p>
یا داخل یک HTML Attribute (ویژگی HTML):
<inputvalue="erfan">
یا حتی داخل JavaScript:
varusername='erfan';
در هر سه حالت، ورودی ما وارد صفحه شده، اما شرایط یکسان نیست. Browser (مرورگر) هرکدام را در Context متفاوتی تفسیر میکند و همین موضوع تعیین میکند که آیا امکان تبدیل این ورودی به یک Malicious Script (اسکریپت مخرب) وجود دارد یا نه.
به همین دلیل در تست XSS، بعد از پیدا کردن ورودی قابلکنترل، باید مسیر آن را دنبال کنیم:
User Input → Reflection → Context → Processing → JavaScript Execution
مثلاً اگر ورودی داخل HTML قرار گرفته باشد، باید بررسی کنیم Application چگونه آن را Encode (کدگذاری) میکند. اگر داخل JavaScript قرار گرفته باشد، شرایط کاملاً متفاوت خواهد بود.
پس Context در XSS یعنی اینکه بفهمیم ورودی مهاجم کجا قرار گرفته و Browser آن را چگونه تفسیر میکند.
این موضوع خیلی مهم است، چون یک Payload که در یک Context قابل اجراست، ممکن است در Context دیگری اصلاً کار نکند. بنابراین قبل از انتخاب Payload، اول باید Context را بشناسیم.
بیشتر بدانیم !
Encode یعنی کدگذاری کردن داده.
در بحث XSS، وقتی میگوییم Output Encoding (کدگذاری خروجی) یعنی برنامه قبل از اینکه ورودی کاربر را داخل صفحه قرار دهد، کاراکترهای خاص را به شکلی تبدیل میکند که Browser آنها را بهعنوان متن معمولی ببیند، نه اینکه آنها را بهعنوان HTML یا JavaScript تفسیر و اجرا کند.
پ
سخن پایانی
XSS در ظاهر ممکن است فقط یک آسیبپذیری مربوط به اجرای JavaScript به نظر برسد، اما وقتی مسیر حمله را دقیق بررسی کنیم، میبینیم که موضوع خیلی فراتر از یک alert() ساده است. نقطه شروع میتواند یک User Input (ورودی کاربر) ساده باشد، اما نحوه پردازش آن توسط Web Application و اجرای آن در Browser است که میتواند یک مشکل امنیتی واقعی ایجاد کند.
در این بخش با مفهوم XSS، نحوه شکلگیری آن، Attack Flow (جریان حمله)، Impact (پیامد) و اهمیت Context (بافت) آشنا شدیم. اما این تازه شروع ماجراست.
