یک خط‌مشی امنیت محتوا (CSP) کمک می‌کند تا اطمینان حاصل شود که هر محتوای بارگذاری شده در صفحه مورد اعتماد مالک سایت است. CSP ها حملات اسکریپت بین سایتی (XSS) را کاهش می دهند زیرا می توانند اسکریپت های ناامن تزریق شده توسط مهاجمان را مسدود کنند. با این حال، اگر CSP به اندازه کافی سختگیرانه نباشد، به راحتی قابل دور زدن است. برای اطلاعات بیشتر ، اسکریپت بین سایتی Mitigate (XSS) را با یک خط مشی امنیتی سختگیرانه محتوا (CSP) بررسی کنید. Lighthouse CSP های اعمال شده در سند اصلی را جمع آوری می کند و در صورت دور زدن مشکلات از CSP Evaluator گزارش می دهد.
روش های مورد نیاز برای یک CSP غیر قابل عبور
برای اطمینان از اینکه CSP شما قابل دور زدن نیست، اقدامات زیر را اجرا کنید. اگر بتوان CSP را دور زد، Lighthouse یک هشدار با شدت بالا منتشر می کند.
CSP XSS را هدف قرار می دهد
برای هدف قرار دادن XSS، یک CSP باید شامل دستورات script-src ، object-src و base-uri باشد. CSP همچنین باید عاری از خطاهای نحوی باشد.
script-src و object-src به ترتیب صفحه را از اسکریپت های ناامن و افزونه های ناامن ایمن می کنند. از طرف دیگر، default-src می تواند برای پیکربندی یک خط مشی گسترده به جای بسیاری از دستورالعمل ها از جمله script-src و object-src استفاده شود.
base-uri از تزریق تگ‌های <base> غیرمجاز که می‌توانند برای هدایت همه URLهای نسبی (مانند اسکریپت‌ها) به یک دامنه تحت کنترل مهاجم استفاده شوند، جلوگیری می‌کند.
CSP از nonces یا هش برای جلوگیری از دور زدن لیست مجاز استفاده می کند
یک CSP که یک لیست مجاز را برای script-src پیکربندی می‌کند، بر این فرض تکیه می‌کند که همه پاسخ‌هایی که از یک دامنه قابل اعتماد می‌آیند، ایمن هستند و می‌توانند به صورت اسکریپت اجرا شوند. با این حال، این فرض برای کاربردهای مدرن صادق نیست. برخی از الگوهای معمول و خوش خیم مانند افشای رابط های JSONP و میزبانی کپی های کتابخانه AngularJS به مهاجمان اجازه می دهد تا از محدودیت های CSP فرار کنند.
در عمل، اگرچه ممکن است برای نویسندگان برنامه واضح نباشد، اکثر لیست های مجاز script-src می توان توسط مهاجمی با یک اشکال XSS دور زد و محافظت کمی در برابر تزریق اسکریپت ایجاد کرد. در مقابل، رویکردهای غیرمبتنی و مبتنی بر هش از این مشکلات رنج نمی‌برند و اتخاذ و حفظ یک سیاست امن‌تر را آسان‌تر می‌کنند.
به عنوان مثال، این کد از یک نقطه پایانی JSONP که در یک دامنه قابل اعتماد میزبانی شده است برای تزریق یک اسکریپت کنترل شده توسط مهاجم استفاده می کند:
CSP:
script-src https://trusted.example.com
HTML:
<script src="https://trusted.example.com/path/jsonp?callback=alert(document.domain)//"></script>
برای جلوگیری از دور زدن، یک CSP باید اسکریپت‌ها را به‌صورت جداگانه با استفاده از nonces یا هش‌ها اجازه دهد و به‌جای فهرست مجاز از «strict-dynamic» استفاده کند.
توصیه های اضافی برای CSP ایمن
برای امنیت و سازگاری بیشتر، روش های زیر را اجرا کنید. اگر CSP از یکی از توصیه‌ها پیروی نکند، Lighthouse یک هشدار با شدت متوسط منتشر می‌کند.
پیکربندی گزارش CSP
پیکربندی یک مقصد گزارش‌دهی به نظارت بر هرگونه خرابی کمک می‌کند. می‌توانید مقصد گزارش را با استفاده از دستورالعمل‌های report-uri یا report-to تنظیم کنید. report-to در حال حاضر توسط همه مرورگرهای مدرن پشتیبانی نمی شود، بنابراین توصیه می شود از هر دو یا فقط report-uri استفاده کنید.
اگر هر محتوایی CSP را نقض کند، مرورگر گزارشی را به مقصد پیکربندی شده ارسال می کند. مطمئن شوید که یک برنامه کاربردی در این مقصد پیکربندی شده است که این گزارش ها را مدیریت می کند.
CSP را در هدر HTTP تعریف کنید
یک CSP را می توان در یک متا تگ به صورت زیر تعریف کرد:
<meta http-equiv="Content-Security-Policy" content="script-src 'none'">
با این حال، اگر می توانید، باید یک CSP را در یک هدر پاسخ HTTP تعریف کنید. تزریق قبل از متا تگ CSP را دور می زند. علاوه بر این، frame-ancestors ، sandbox و گزارش در CSPهای متا تگ پشتیبانی نمی شوند.
اطمینان حاصل کنید که CSP سازگار با عقب است
همه مرورگرها از nonces/hash های CSP پشتیبانی نمی کنند، بنابراین افزودن unsafe-inline به عنوان جایگزین برای مرورگرهای غیر سازگار توصیه می شود. اگر مرورگر از nonces/hash پشتیبانی کند، unsafe-inline نادیده گرفته می شود.
به طور مشابه، strict-dynamic توسط همه مرورگرها پشتیبانی نمی شود. توصیه می شود برای هر مرورگر غیرمنطبق، یک لیست مجاز را به عنوان یک نسخه بازگشتی تنظیم کنید. لیست مجاز در مرورگرهایی که strict-dynamic پشتیبانی می کنند نادیده گرفته می شود.
چگونه یک CSP سختگیرانه ایجاد کنیم
در زیر نمونه ای از استفاده از یک CSP سختگیرانه با یک خط مشی غیرمبتنی است.
CSP:
script-src 'nonce-random123' 'strict-dynamic' 'unsafe-inline' https:;
object-src 'none';
base-uri 'none';
report-uri https://reporting.example.com;
HTML:
<script nonce="random123" src="https://trusted.example.com/trusted_script.js"></script>
random123 هر رشته ای است که هر بار که صفحه بارگیری می شود در سمت سرور ایجاد می شود. unsafe-inline و https: در مرورگرهای مدرن به دلیل غیرمستقیم بودن و strict-dynamic نادیده گرفته می شوند. برای اطلاعات بیشتر در مورد اتخاذ یک CSP سختگیرانه، راهنمای Strict CSP را بررسی کنید.
می توانید با استفاده از Lighthouse و CSP Evaluator یک CSP را برای بای پس های احتمالی بررسی کنید. اگر می‌خواهید یک CSP جدید را بدون خطر شکستن صفحات موجود آزمایش کنید، CSP را در حالت گزارش فقط با استفاده از Content-Security-Policy-Report-Only به عنوان نام سرصفحه تعریف کنید. این موارد نقض CSP را به هر مقصد گزارشی که با report-to و report-uri پیکربندی کرده‌اید ارسال می‌کند، اما در واقع CSP را اجرا نمی‌کند.