حملات XSS (Cross-Site Scripting) یکی از رایجترین تهدیدهای امنیتی در برنامههای وب هستند که در آن مهاجم تلاش میکند کد مخرب خود را به صفحات یک وبسایت تزریق کند. نتیجه این حملات میتواند سرقت اطلاعات کاربران، دسترسی به نشستهای فعال یا تغییر محتوای سایت باشد.
برای کاهش این خطر، استانداردی به نام Content Security Policy (CSP) ایجاد شد. CSP به مرورگر اعلام میکند که چه منابعی مجاز به اجرا یا بارگذاری هستند و با محدود کردن اجرای اسکریپتهای ناشناس، یک لایه امنیتی مهم در برابر حملات XSS ایجاد میکند.
در این مطلب با مفهوم CSP، نحوه عملکرد آن، دستورات مهم این سیاست امنیتی و نقش آن در محافظت از برنامههای وب در برابر حملات XSS آشنا میشویم.
Content Security Policy (CSP) چیست؟
Content Security Policy یا به اختصار CSP یک استاندارد امنیتی در وب است که به مرورگر اعلام میکند یک صفحه وب اجازه دارد چه منابعی را بارگذاری و اجرا کند. این منابع میتوانند شامل فایلهای جاوااسکریپت، CSS، تصاویر، فونتها، ویدئوها یا اتصال به سرویسهای خارجی باشند.
CSP از طریق یک HTTP Header با نام Content-Security-Policy به مرورگر ارسال میشود. مرورگر پس از دریافت این سیاست، هنگام بارگذاری صفحه بررسی میکند که هر منبع با قوانین تعریفشده مطابقت دارد یا خیر. اگر منبعی خارج از قوانین CSP باشد، مرورگر میتواند آن را مسدود کند.
برای مثال، یک سیاست ساده مانند:
Content-Security-Policy: default-src 'self';
به مرورگر میگوید که منابع صفحه فقط باید از همان دامنه اصلی بارگذاری شوند و منابع خارجی ناشناس اجازه اجرا ندارند.
CSP چه مشکلی را حل میکند؟
در یک وبسایت معمولی، مرورگر نمیداند کدام اسکریپتها قابل اعتماد هستند. اگر مهاجم بتواند کدی مانند JavaScript مخرب را وارد صفحه کند، مرورگر ممکن است آن را مانند بخشی از کد اصلی سایت اجرا کند.
CSP با ایجاد یک فهرست از منابع مجاز، این اعتماد را محدود میکند. بهعنوان مثال، میتوان مشخص کرد:
- فقط فایلهای JavaScript از دامنه اصلی سایت اجرا شوند.
- تصاویر فقط از چند منبع مشخص دریافت شوند.
- اجرای Scriptهای داخل HTML ممنوع باشد.
- اتصالهای API فقط به سرورهای مشخص محدود شوند.
CSP چگونه کار میکند؟
فرآیند کار CSP به این شکل است:
- کاربر درخواست یک صفحه وب را ارسال میکند.
- سرور علاوه بر محتوای HTML، هدر امنیتی CSP را نیز ارسال میکند.
- مرورگر قوانین CSP را دریافت و ذخیره میکند.
- هنگام بارگذاری منابع مختلف، آنها را با قوانین بررسی میکند.
- منابع غیرمجاز مسدود میشوند.
برای مثال، اگر سایت چنین قانونی داشته باشد:
Content-Security-Policy: script-src 'self';
و یک مهاجم تلاش کند یک فایل JavaScript را از دامنه دیگری اجرا کند، مرورگر آن Script را متوقف خواهد کرد.
CSP یک راهحل کامل برای امنیت نیست
اگرچه CSP یکی از ابزارهای قدرتمند امنیت وب است، اما نباید آن را جایگزین سایر روشهای امنیتی دانست. یک سیاست CSP مناسب باید در کنار روشهایی مانند:
- اعتبارسنجی ورودیها (Input Validation)
- رمزگذاری خروجیها (Output Encoding)
- استفاده صحیح از Cookieها
- رعایت اصول Secure Coding
استفاده شود.
CSP در حقیقت یک لایه دفاعی اضافه است که حتی اگر بخشی از کنترلهای امنیتی دیگر دچار مشکل شوند، میتواند از اجرای بسیاری از کدهای مخرب جلوگیری کند.
حمله XSS چیست و چرا خطرناک است؟
برای درک اهمیت CSP، ابتدا باید با یکی از مهمترین تهدیدهای امنیتی در برنامههای وب یعنی XSS (Cross-Site Scripting) آشنا شویم.
XSS نوعی حمله است که در آن مهاجم تلاش میکند کد مخرب، که معمولا JavaScript است، را در یک صفحه وب قرار دهد تا این کد در مرورگر کاربران دیگر اجرا شود. مشکل اصلی اینجاست که مرورگر تصور میکند این کد بخشی از محتوای معتبر همان وبسایت است و آن را اجرا میکند.
برای مثال، فرض کنید یک وبسایت بخش نظرات کاربران را دارد. اگر برنامه بدون بررسی مناسب، متن واردشده توسط کاربران را مستقیما در صفحه نمایش دهد، مهاجم ممکن است بهجای یک نظر معمولی، کدی مانند زیر وارد کند:
<script>
alert("Your account has been hacked!");
</script>
اگر این کد بدون فیلتر اجرا شود، مرورگر آن را بهعنوان یک Script واقعی پردازش میکند.
انواع حملات XSS
حملات XSS به سه دسته اصلی تقسیم میشوند:
۱. Stored XSS (ذخیرهشده)
در این نوع حمله، کد مخرب ابتدا در سرور ذخیره میشود و سپس هر بار که کاربران صفحه مربوطه را باز میکنند، اجرا میشود.
برای مثال:
- بخش نظرات یک وبسایت
- پروفایل کاربران
- پیامهای انجمنها
فرض کنید مهاجم یک اسکریپت مخرب را در قسمت نام کاربری ذخیره کند. از آن به بعد، هر کاربری که صفحه پروفایل او را مشاهده کند، ممکن است آن اسکریپت را اجرا کند.
این نوع XSS خطرناکترین نوع محسوب میشود، زیرا تعداد زیادی از کاربران را تحت تاثیر قرار میدهد.
۲. Reflected XSS (بازتابی)
در این روش، کد مخرب داخل یک درخواست ارسال میشود و سرور همان مقدار را بدون پردازش مناسب در پاسخ نمایش میدهد.
یک نمونه رایج، لینکهایی هستند که شامل کد مخرب هستند:
example.com/search?q=<script>alert(1)</script>
اگر صفحه جستجو مقدار پارامتر q را بدون ایمنسازی نمایش دهد، اسکریپت در مرورگر اجرا خواهد شد.
این نوع حمله نیازمند فریب کاربر برای باز کردن یک لینک خاص است.
۳. DOM-based XSS
در این نوع حمله، مشکل در کدهای جاوا اسکریپت سمت کاربر (Client-Side) وجود دارد. داده مخرب بدون ارسال به سرور، مستقیما توسط اسکریپتهای صفحه پردازش و وارد DOM میشود.
برای مثال، اگر یک اسکریپت مقدار URL را دریافت کند و بدون بررسی داخل صفحه قرار دهد، مهاجم میتواند از آن برای اجرای کد استفاده کند.
چرا XSS خطرناک است؟
اجرای موفق یک حمله XSS میتواند پیامدهای مختلفی داشته باشد:
- سرقت Cookieهای نشست کاربر
- انجام عملیات از طرف کاربر بدون اجازه او
- تغییر محتوای صفحات سایت
- نمایش فرمهای جعلی برای سرقت اطلاعات
- هدایت کاربران به صفحات مخرب
- دسترسی به اطلاعات حساس موجود در صفحه
به همین دلیل، XSS سالها یکی از مهمترین آسیبپذیریهای امنیتی وب بوده است و در استانداردهایی مانند OWASP Top 10 نیز جایگاه مهمی دارد.
در چنین شرایطی، CSP بهعنوان یک لایه دفاعی اضافی وارد عمل میشود و حتی اگر مهاجم بتواند کد مخرب خود را وارد صفحه کند، میتواند از اجرای آن جلوگیری کند.
CSP چگونه از حملات XSS جلوگیری میکند؟
هدف اصلی CSP این است که دامنه و نوع کدهایی که مرورگر اجازه اجرای آنها را دارد محدود کند. به زبان ساده، CSP به مرورگر میگوید: «فقط منابعی را اجرا کن که از قبل مشخص کردهام و به آنها اعتماد دارم.»
محدود کردن منابع JavaScript
یکی از مهمترین قابلیتهای CSP، کنترل منبع فایلهای JavaScript است.
برای مثال:
Content-Security-Policy: script-src 'self';
این قانون به مرورگر میگوید که فقط Scriptهایی که از همان دامنه اصلی سایت بارگذاری میشوند مجاز هستند.
اگر مهاجم تلاش کند کدی مانند زیر را از یک دامنه خارجی اجرا کند:
<script src="https://malicious-site.com/script.js"></script>
مرورگر آن را مسدود خواهد کرد.
جلوگیری از اجرای Inline Scriptها
یکی از روشهای رایج در حملات XSS، تزریق مستقیم JavaScript داخل HTML است:
<script>
alert("XSS");
</script>
CSP میتواند اجرای چنین Scriptهایی را محدود کند.
برای مثال:
Content-Security-Policy: script-src 'self';
بهصورت پیشفرض اجازه اجرای Scriptهای Inline را نمیدهد.
این ویژگی اهمیت زیادی دارد، زیرا بسیاری از حملات XSS از همین روش استفاده میکنند.
استفاده از Nonce برای Scriptهای مجاز
گاهی یک وبسایت واقعا نیاز دارد برخی Scriptهای Inline را اجرا کند. در این شرایط استفاده از nonce روش امنتری نسبت به فعال کردن کامل Inline Scriptها است.
در این روش، سرور یک مقدار تصادفی تولید میکند و فقط Scriptهایی که همان مقدار را دارند اجازه اجرا خواهند داشت.
مثال:
هدر CSP:
Content-Security-Policy: script-src 'nonce-abc123';
کد HTML:
<script nonce="abc123">
// Trusted script
</script>
اگر مهاجم Script دیگری بدون nonce معتبر تزریق کند، مرورگر آن را اجرا نخواهد کرد.
استفاده از Hash برای تایید Scriptها
روش دیگر، استفاده از Hash است. در این روش، مرورگر مقدار Hash یک Script مشخص را بررسی میکند و فقط در صورتی آن را اجرا میکند که با مقدار تعریفشده در CSP مطابقت داشته باشد.
این روش برای Scriptهایی که محتوای ثابت دارند مناسب است.
محدود کردن منابع خارجی
CSP فقط JavaScript را کنترل نمیکند، بلکه میتواند منابع مختلف صفحه را نیز محدود کند.
برای مثال:
Content-Security-Policy:
img-src 'self';
connect-src 'self' api.example.com;
با این تنظیمات:
- تصاویر فقط از منابع مشخص بارگذاری میشوند.
- درخواستهای API فقط به سرورهای تعیینشده ارسال میشوند.
- این محدودیتها سطح حمله را کاهش میدهند.
CSP چه زمانی جلوی XSS را نمیگیرد؟
CSP یک راهحل جادویی نیست و در همه شرایط نمیتواند جلوی XSS را بگیرد. برای مثال:
- اگر سیاست CSP بسیار باز باشد.
- اگر از
unsafe-inlineاستفاده شود. - اگر منابع مخرب در لیست منابع مجاز قرار گرفته باشند.
- اگر آسیبپذیری در منطق برنامه وجود داشته باشد.
به همین دلیل، CSP باید در کنار روشهایی مانند فیلتر کردن خروجیها، اعتبارسنجی ورودیها و رعایت اصول Secure Coding استفاده شود.
در مجموع، CSP با کاهش آزادی مرورگر در اجرای کدها، یکی از مهمترین لایههای دفاعی در برابر حملات XSS محسوب میشود و میتواند بسیاری از سناریوهای حمله را حتی پس از ورود کد مخرب به صفحه خنثی کند.
آشنایی با Content-Security-Policy Header
برای فعال کردن CSP، قوانین امنیتی از طریق یک HTTP Response Header به مرورگر ارسال میشوند. این Header به مرورگر میگوید که چه منابعی برای صفحه مجاز هستند و چه مواردی باید مسدود شوند.
ساختار کلی این Header به شکل زیر است:
Content-Security-Policy: directive source
در این ساختار:
- Directive مشخص میکند چه نوع منبعی کنترل میشود.
- Source مشخص میکند منابع مجاز از کجا میتوانند بارگذاری شوند.
برای مثال:
Content-Security-Policy: script-src 'self';
این قانون فقط اجازه اجرای فایلهای JavaScript از همان دامنه سایت را میدهد.
مهمترین Directiveهای CSP
CSP از دستورهای مختلفی تشکیل شده است که هرکدام نوع خاصی از منابع را کنترل میکنند.
default-src
این دستور بهعنوان قانون پیشفرض برای تمام منابع استفاده میشود. اگر برای یک نوع منبع قانون جداگانهای تعریف نشده باشد، مرورگر از این مقدار استفاده میکند.
مثال:
Content-Security-Policy: default-src 'self';
یعنی تمام منابع باید از همان دامنه اصلی بارگذاری شوند.
script-src
این دستور مشخص میکند چه فایلهای JavaScript اجازه اجرا دارند.
مثال:
Content-Security-Policy: script-src 'self' https://cdn.example.com;
در این حالت:
- Scriptهای داخل سایت مجاز هستند.
- Scriptهای موجود در CDN مشخصشده نیز اجازه اجرا دارند.
- سایر منابع JavaScript مسدود میشوند.
style-src
برای کنترل فایلهای CSS استفاده میشود.
مثال:
Content-Security-Policy: style-src 'self';
با این قانون، فقط فایلهای CSS موجود در همان دامنه قابل بارگذاری هستند.
img-src
منابع تصاویر را کنترل میکند.
مثال:
Content-Security-Policy: img-src 'self' https://images.example.com;
در این حالت تصاویر فقط از سایت اصلی و دامنه مشخصشده بارگذاری میشوند.
connect-src
اتصالهای ایجادشده توسط JavaScript را کنترل میکند، مانند درخواستهای:
- AJAX
- Fetch API
- WebSocket
مثال:
Content-Security-Policy: connect-src 'self' https://api.example.com;
این قانون باعث میشود برنامه فقط بتواند به APIهای مشخصشده درخواست ارسال کند.
font-src
منابع مربوط به فونتها را محدود میکند.
مثال:
Content-Security-Policy: font-src 'self' https://fonts.example.com;
frame-src
مشخص میکند صفحه اجازه دارد چه محتوایی را داخل iframe بارگذاری کند.
مثال:
Content-Security-Policy: frame-src https://trusted.example.com;
مقادیر رایج در CSP
علاوه بر نام منابع، CSP از چند مقدار ویژه نیز استفاده میکند:
'self'
به معنای همان دامنهای است که صفحه از آن بارگذاری شده است.
مثال:
script-src 'self';
'none'
تمام منابع را مسدود میکند.
مثال:
object-src 'none';
*
به معنی اجازه دادن به همه منابع است.
مثال:
img-src *;
استفاده بیش از حد از این مقدار میتواند امنیت CSP را کاهش دهد.
'unsafe-inline'
اجازه اجرای Script و Styleهای Inline را میدهد.
مثال:
script-src 'unsafe-inline';
این گزینه معمولا توصیه نمیشود، زیرا بسیاری از مزایای امنیتی CSP را از بین میبرد.
یک CSP مناسب با سیاستی محدود شروع میشود و سپس بر اساس نیازهای واقعی سایت توسعه پیدا میکند. هرچه منابع مجاز محدودتر باشند، احتمال موفقیت حملات XSS نیز کمتر خواهد شد.
تفاوت CSP با سایر روشهای مقابله با XSS
اگرچه CSP یکی از ابزارهای قدرتمند برای کاهش خطر حملات XSS است، اما نباید آن را تنها راهکار امنیتی در نظر گرفت. امنیت یک برنامه وب با استفاده از چندین لایه دفاعی مختلف ایجاد میشود و هر روش، مشکل خاصی را هدف قرار میدهد.
Input Validation (اعتبارسنجی ورودیها)
در این روش، دادههایی که از کاربران دریافت میشوند قبل از پردازش بررسی میشوند.
برای مثال:
- محدود کردن طول ورودیها
- بررسی نوع داده
- جلوگیری از دریافت کاراکترهای غیرمجاز
اعتبارسنجی ورودیها میتواند بسیاری از دادههای مخرب را قبل از ورود به سیستم متوقف کند، اما بهتنهایی برای جلوگیری از XSS کافی نیست، زیرا بسیاری از حملات به نحوه نمایش دادهها در صفحه نیز وابسته هستند.
Output Encoding (رمزگذاری خروجیها)
یکی از مهمترین روشهای جلوگیری از XSS، تبدیل کاراکترهای خاص به شکل امن هنگام نمایش خروجی است.
برای مثال، کاراکترهایی مانند:
< > " '
میتوانند توسط مرورگر بهعنوان بخشی از کد HTML یا JavaScript تفسیر شوند. با Encoding کردن آنها، مرورگر آنها را بهعنوان متن معمولی نمایش میدهد.
این روش اولین خط دفاعی در برابر XSS محسوب میشود.
استفاده از فریمورکهای امن
بسیاری از فریمورکهای مدرن وب مانند React، انگولار و جنگو مکانیزمهایی برای کاهش خطر XSS دارند.
برای مثال:
- Escape کردن خودکار خروجیها
- جلوگیری از قرار دادن مستقیم HTML
- ارائه APIهای امنتر برای نمایش دادهها
البته این قابلیتها زمانی موثر هستند که توسعهدهنده آنها را بهدرستی استفاده کند. استفاده نادرست از امکاناتی مانند dangerouslySetInnerHTML در React میتواند دوباره آسیبپذیری ایجاد کند.
HttpOnly Cookie
یکی از اهداف رایج حملات XSS، سرقت Cookieهای نشست کاربر است. با فعال کردن ویژگی HttpOnly برای Cookieها، جاوااسکریپت سمت مرورگر نمیتواند به این Cookieها دسترسی داشته باشد.
مثال:
Set-Cookie: sessionId=abc123; HttpOnly
در این حالت، حتی اگر مهاجم بتواند JavaScript اجرا کند، دسترسی مستقیم به Cookie نشست محدود میشود.
CSP چه تفاوتی با این روشها دارد؟
تفاوت اصلی CSP این است که برخلاف روشهای بالا، در سطح مرورگر عمل میکند.
برای مثال:
- Input Validation تلاش میکند داده مخرب وارد سیستم نشود.
- Output Encoding تلاش میکند داده هنگام نمایش خطرناک نباشد.
- HttpOnly Cookie از اطلاعات حساس نشست محافظت میکند.
- CSP تلاش میکند حتی در صورت وجود یک Script غیرمجاز، مرورگر اجازه اجرای آن را ندهد.
به همین دلیل، CSP بهعنوان یک لایه دفاعی تکمیلی (Defense in Depth) استفاده میشود، نه جایگزین سایر روشهای امنیتی.
جمعبندی
Content Security Policy (CSP) یکی از مهمترین لایههای امنیتی در برنامههای وب است که با محدود کردن منابع قابل اجرا در مرورگر، نقش مهمی در کاهش خطر حملات XSS دارد.
در این مطلب دیدیم که CSP چگونه با کنترل Scriptها، منابع خارجی و اتصالهای برنامه، از اجرای کدهای ناشناس جلوگیری میکند. همچنین با Directiveهای مهم، روشهای پیادهسازی و اشتباهات رایج هنگام تنظیم آن آشنا شدیم.
با این حال، CSP جایگزین سایر روشهای امنیتی نیست و باید در کنار تکنیکهایی مانند اعتبارسنجی ورودیها، رمزگذاری خروجیها و توسعه امن نرمافزار استفاده شود. یک Policy مناسب میتواند امنیت وبسایت را افزایش دهد و در برابر بسیاری از سناریوهای حمله یک لایه دفاعی مؤثر ایجاد کند.
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید