CSP: سپر نامرئی که سایت شما را از هک نجات می‌دهد!

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

Content-Security-Policy (CSP) یک هدر HTTP است که به مرورگر می‌گوید فقط از کدام منبع مجاز است اسکریپت، استایل، فونت یا تصویر بارگذاری شود. با این‌حال، بدون آن، مرورگر به هر کدی که در HTML صفحه ظاهر شود اعتماد می‌کند؛ فارغ از این‌که آن کد از سرور خودتان آمده یا از یک حمله تزریقی.

چرا حمله تزریق اسکریپت هنوز رایج‌ترین راه نفوذ به سایت‌هاست؟

در واقع، حمله XSS (Cross-Site Scripting) به این معنی است که مهاجم کدی را از طریق یک ورودی ناامن (فرم، پارامتر URL، کامنت) وارد صفحه می‌کند. مرورگر قربانی، این کد را همان‌قدر اجرا می‌کند که کد اصلی سایت را. در نتیجه، این کد می‌تواند کوکی جلسه کاربر را بدزدد، فرم پرداخت را دستکاری کند یا کاربر را به یک صفحه فیشینگ هدایت کند.

در واقع، مشکل اصلی این نیست که تیم‌های توسعه تنبل‌اند؛ مشکل این است که پاک‌سازی ورودی (Sanitization) به‌تنهایی هرگز ۱۰۰٪ کامل نیست. همیشه یک مسیر فراموش‌شده، یک افزونه شخص‌ثالث، یا یک کتابخانه قدیمی وجود دارد که یک روزنه باز می‌گذارد.

چرا فقط اعتماد به کد پاک‌سازی‌شده کافی نیست؟

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

پیش از تعریف سیاست نهایی، باید تفاوت دو حالت اصلی CSP را دقیق فهمید. راهنمای رسمی OWASP صراحتاً توصیه می‌کند این دو حالت هم‌زمان و کنار هم اجرا شوند، نه یکی به‌جای دیگری.

راهکاری که برای اکثر سایت‌های پویا (فروشگاه اینترنتی، پنل مدیریتی، وبلاگ با کامنت) بهترین تعادل امنیت و نگهداری را دارد، سیاست سخت‌گیرانه مبتنی بر نانس (Nonce-based Strict CSP) است. این رویکرد بسیار بهتر از صرفاً لیست‌کردن دامنه‌های مجاز عمل می‌کند.

در واقع، تیم سنتیوا در پروژه‌های پیاده‌سازی CSP این مراحل را عملی می‌کند:

• ممیزی کامل منابع فعلی سایت (اسکریپت، فونت، تصویر، آیفریم) برای ساخت لیست دقیق مبدأهای واقعاً مجاز
• طراحی و اجرای مرحله Report-Only، همراه با پایش روزانه گزارش‌های نقض پیش از هر تصمیم نهایی
• پیاده‌سازی نانس سمت سرور و بازنویسی اسکریپت‌های inline باقی‌مانده
• نگهداری و به‌روزرسانی مستمر سیاست، هم‌زمان با هر ابزار یا اسکریپت شخص‌ثالث جدیدی که به سایت اضافه می‌شود

سناریوی این راهنما: یک فروشگاه اینترنتی فرضی به آدرس shop-example.ir در نظر می‌گیریم. این سایت فایل‌های استاتیک را از CDN اختصاصی cdn.shop-example.ir، فونت را از Google Fonts، و ابزار تحلیل ترافیک را از Google Tag Manager بارگذاری می‌کند. گزارش‌های نقض هم در آدرس shop-example.ir/csp-reports جمع‌آوری می‌شوند. دقیقاً همین نام‌ها در تمام مراحل زیر تکرار می‌شوند تا کل راهنما یک واحد یکپارچه و قابل‌تطبیق باشد.

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' cdn.shop-example.ir www.googletagmanager.com; style-src 'self' fonts.googleapis.com; font-src fonts.gstatic.com; img-src 'self' cdn.shop-example.ir data:; connect-src 'self' www.google-analytics.com; report-to csp-endpoint

این مرحله چه کاری انجام می‌دهد؟

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

Reporting-Endpoints: csp-endpoint="https://shop-example.ir/csp-reports"

نقطه دریافت گزارش چه نقشی دارد؟

این هدر مشخص می‌کند مرورگر گزارش‌های نقض را دقیقاً به کجا بفرستد. با این‌حال، بدون این هدر (یا معادل قدیمی‌ترش، report-uri)، حالت Report-Only عملاً کور است؛ چون داده‌ای برای تحلیل جمع نمی‌شود.

Content-Security-Policy: default-src 'self'; script-src 'nonce-{RANDOM}' 'strict-dynamic'; style-src 'self' fonts.googleapis.com; font-src fonts.gstatic.com; object-src 'none'; base-uri 'none'; frame-ancestors 'none'; report-to csp-endpoint

چرا این سیاست نهایی متفاوت است؟

در این مرحله، دیگر لیست دامنه در script-src نیست؛ فقط اسکریپت‌هایی با نانس صحیح اجرا می‌شوند. بنابراین، مقدار {RANDOM} باید یک رشته تصادفی و یکتا باشد که Backend در هر درخواست، از نو تولید می‌کند؛ هرگز یک نانس ثابت را در چند درخواست تکرار نکنید.

<script nonce="{RANDOM}" src="/assets/checkout.js"></script>

مقدار {RANDOM} در تگ HTML باید دقیقاً همان مقداری باشد که در هدر همان درخواست فرستاده شده است. به همین دلیل، بعد از فعال‌سازی، نتیجه را حتماً در کنسول توسعه‌دهنده مرورگر بررسی کنید تا هیچ اسکریپت مجازی به‌اشتباه مسدود نشده باشد.

یک نمونه معمول: فروشگاه اینترنتی متوسط

«وقتی حالت Report-Only را فعال کردیم، بعد از چند روز متوجه شدیم یکی از اسکریپت‌های تبلیغاتی شخص‌ثالث ما، بدون اطلاع تیم فنی، از یک دامنه ناشناخته بارگذاری می‌شد. اگر مستقیم حالت اجرایی را فعال کرده بودیم، یا سایت خراب می‌شد یا اصلاً متوجه این ریسک نمی‌شدیم.»

در واقع، این تجربه، الگویی معمول در پیاده‌سازی CSP روی فروشگاه‌های اینترنتی با چند ابزار شخص‌ثالث است. جمع‌بندی نتیجه معمول این مسیر:

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

فوری (همین هفته)

• فعال‌سازی CSP در حالت Report-Only با default-src 'self'
• راه‌اندازی نقطه دریافت گزارش با هدر Reporting-Endpoints

کوتاه‌مدت (این ماه)

• بررسی روزانه گزارش‌های نقض و افزودن منابع مجاز واقعی به سیاست
• بازنویسی اسکریپت‌های inline باقی‌مانده با نانس سمت سرور

بلندمدت (مستمر)

• فعال‌سازی نهایی حالت اجرایی و حذف کامل حالت Report-Only
• بازبینی فصلی سیاست هم‌زمان با اضافه‌شدن هر ابزار یا اسکریپت شخص‌ثالث جدید

سوالات متداول تخصصی

• پیاده‌سازی CSP، یک هدر HTTP است که تعیین می‌کند مرورگر فقط از کدام منابع مجاز است اسکریپت و استایل اجرا کند.
• شروع همیشه باید از حالت Report-Only باشد؛ نه مستقیم حالت اجرایی.
• سیاست مبتنی بر نانس (نه لیست طولانی دامنه) در برابر بیشتر روش‌های دور زدن CSP مقاوم‌تر است.
• پیاده‌سازی CSP یک اقدام یک‌باره نیست؛ با هر ابزار شخص‌ثالث جدید باید بازبینی شود.
• بدون این هدر، هر روزنه کوچک در پاک‌سازی ورودی می‌تواند به یک حمله کامل XSS تبدیل شود.

پیاده‌سازی CSP، سرمایه‌گذاری روی نامرئی‌ترین اما مؤثرترین لایه دفاعی وب‌سایت شماست.