در این بخش از دوره آموزشی SEC542 از موسسه SANS به آشنایی با آسیب پذیری Cross Site Scripting و یا همان XSS آن می پردازیم.
Cross Site Scripting
Cross-Site Scripting یا XSS حمله‌ای است که در آن مهاجم کدهای اسکریپت را در یک وب‌اپلیکیشن تزریق کرده و مرورگر نیز با این باور که که کدها از سایتی مطمئن دریافت شده‌اند، آن‌ها را اجرا می‌کند. به عنوان مثال، کد تزریق شده می‌تواند یک پارامتر URL باشد که خوانده شده و به عنوان بخشی از اپلیکیشن به کاربر نمایش داده می‌شود.
حمله Cross-Site Scripting بارها در طول تاریخ دچار بدفهمی شده و به عنوان یک آسیب‌پذیری، دست کم گرفته شده است. بسیاری افراد عواقب و اثرات این آسیب‌پذیری را درک نکرده‌اند. قضیه این است که ما در این حمله می‌توانیم از آسیب‌پذیری وب‌سرور یا وب‌اپلیکیشن استفاده کرده و به کلاینت‌های آن سرور حمله کنیم. به عبارتی دیگر هدف اصلی در این حمله، مرورگر کاربران است نه سرور.
تصور کنید در حساب بانکی آنلاین خود لاگین نموده‌اید و سایت بانک اطلاعات مفیدی از session شما را برای مدتی در مرورگر نگه می‌دارد. شاید این اطلاعات فقط شامل یک کوکی باشد و شاید اطلاعاتی از شناسه کاربری یا شماره حساب بانکی شما باشد. این اطلاعات در محفظه اختصاصی خود در مرورگر ذخیره می‌شوند طوری که تنها توسط همان سایت قابل دسترسی باشند.
آشنایی با آسیب پذیری SQL Injection
حال تصور کنید که یک مهاجم می‌تواند به این اطلاعات دست یابد. یا بدتر از آن، مهاجم می‌تواند به جای شما بر روی مرورگر و در سایت بانکی، کد اجرا کند. این حمله را که Cross-Site Request Forgery نامیده می‌شود، در قسمت‌های بعد پوشش خواهیم داد.
اجزاء یک حمله XSS
چهار بخش اصلی که یک حمله XSS را می سازند، عبارتند از:
Application : اپلیکیشن آسیب‌پذیر که کد مخرب را به کلاینت ارسال می کند.
Browser : کلاینت (مرورگر) که فریب می خورد کد مخرب را اجرا کند.
Attacker : مهاجمی که با تزریق کدهای مخرب، کاربران اپلیکیشن را مورد هدف قرار داده است.
Code : درنهایت، کدی (معمولا JavaScript) که مهاجم امیدوار است بر روی کلاینت اجرا شود.
Same Origin Policy
بر اساس قانون Same Origin Policy که توسط مرورگرها اجرا می‌شود، کد کلاینت از یک سرور نباید به محتوای یک سرور دیگر دسترسی داشته باشد. درواقع این قانون برای جلوگیری از دستکاری محتوا توسط کدهای client-side در مرورگرها به کار گرفته می‌شود. طبق این قانون تنها محتواهایی که از یک سرور (same origin) باشند، از طریق کدها قابل دسترسی هستند در غیراینصورت دسترسی به منابع توسط مرورگر بلاک می‌شود . same origin بودن از روی hostname، پورت و پروتکل مشخص می‌گردد.
استفاده از hostname بجای آدرس IP به دلیل وجود سایت‌هایی است که بین سرورهای مختلف load balancing ایجاد کرده‌اند.
Why Same Origin Policy
جهت تامین امنیت محتوای اپلیکیشن‌ها، وجود قانون Same Origin Policy ضرورت داشت. تصور کنید می‌توانستید کدی بنویسید که به محتوای هر سایت دسترسی داشته باشد. آنگاه حملات Cross-Site Scripting فاجعه بار بودند. شما وارد یک سایت مخرب می‌شدید و مهاجم اسکریپتی در مرورگر شما اجرا می‌کرد که به واسطه آن می‌توانست کنترل کامل مرورگر را در اختیار گرفته و دیتاهای حساس بانکی شما را بدزدد.
همچنین امکان deface کردن هر سایت داخل مرورگر کاربر وجود داشت. یا کوکی‌ها به راحتی دزدیده می‌شدند و فرم‌ها اطلاعات خود را به سرورهای دلخواه مهاجم ارسال می‌نمودند. اما قانون Same Origin Policy با اعمال محدودیت بر روی اسکریپت‌ها، اجرای این حملات را تا حد زیادی دشوار نموده است.
بعدا خواهید دید که به کمک XSS خیلی از حملات قابل پیاده‌سازی هستند اما بدون وجود قانون Same Origin Policy، اجرای این حملات به راحتی و تنها با فرستادن یک ایمیل حاوی کد JavaScript، ممکن می‌شد.
اجرای قانون Same Origin Policy
فرض کنید شما به سایت sec542.org مراجعه نمودید و مرورگر شما اسکریپتی را از آدرس زیر دریافت می‌کند:
http://www.sec542.org/about/info.php
اجرای اسکریپت موجب می‌شود تا مرورگر درخواست‌های HTTP بیشتری ارسال کند. اما آیا این اسکریپت قادر خواهد بود به پاسخ‌ها نیز دسترسی داشته باشد؟ بستگی دارد!
جدول بالا rule های متعددی را نشان می‌دهد که بر قانون Same Origin Policy تاثیرگذار هستند. همانطور که مشاهده می‌کنید، Same Origin Policy بر مبنای سه دسته اطلاعات، دسترسی را محدود می‌کند. این اطلاعات عبارتند از: hostname، پروتکل و شماره پورت. این یعنی زمانی که یک کد JavaScript در مرورگر اجرا شده یا فایلی در مرورگر لود می‌شود، اجرای کد تنها بر محتوایی تاثیرگذار خواهد بود که از همان منشا (same origin) در حال سرویس‌دهی باشد.
در جدول بالا می‌بینید که با تغییر پورت یا host، دسترسی توسطsame origin بلاک می‌شود. تغییر پروتکل نیز موجب نقض این قانون می‌شود. به همین دلیل است که بسیاری از سایت‌ها هر دو پروتکل http و https را برای سرویس‌دهی پشتیبانی می‌کنند.
مطالب این بخش توسط سرکار خانم فهیمه رضایی تهیه شده است.
