Defaults.Exposed › رفع اشکال‌ها › Content-Security-Policy (CSP)

چطور Content-Security-Policy (CSP) را رفع کنید

یک Content Security Policy یک قانون امنیتی است که وب‌سایت شما به مرورگر هر بازدیدکننده می‌دهد و به آن می‌گوید دقیقاً کدام کدها مجاز هستند اجرا شوند. بدون آن، اگر چیز مخربی روی یک صفحه قرار گیرد — از طریق یک کادر نظر، یک پلاگین هک شده، یا یک اسکریپت شخص ثالث — مرورگر آن را آزادانه اجرا می‌کند، از جمله کدی که به‌آرامی شماره‌های کارت و رمزهای عبور مشتریان شما را هنگام تایپ می‌کشد، در حالی که قفل همچنان نمایش می‌دهد.

نتیجه نهایی برای کسب‌وکار شما: اگر سایت شما دستکاری شود، کد مخرب می‌تواند اطلاعات کارت پرداخت و ورود به سیستم مشتریان شما را مستقیماً از صفحه‌ی پرداخت شما بخواند در حالی که همه چیز کاملاً عادی به نظر می‌رسد — که برای شما chargebacks، ادعاهای تقلب، یک نقض داده‌ی قابل گزارش، و یک شکست بررسی که تیم‌های امنیتی مشتریان بزرگ‌تر برای توقف یا از دست دادن معامله استفاده می‌کنند به همراه می‌آورد.

هزینه این برای شما

• کد پنهانی از طریق یک پلاگین آسیب‌پذیر یا یک اسکریپت شخص ثالث به خطر افتاده به یکی از صفحات شما می‌لغزد و به‌آرامی هر شماره‌ی کارت، نام و CVV را که مشتریان تایپ می‌کنند در زمان واقعی کپی می‌کند. سایت شما به خوبی کار می‌کند؛ قفل وجود دارد.
• یک کلاهبردار یک کادر 'پرداخت اینجا' قانع‌کننده در وب‌سایت واقعی شما وارد می‌کند که پرداخت‌ها را به حساب خودش هدایت می‌کند.
• تیم امنیتی یک مشتری بزرگ‌تر سایت شما را اسکن می‌کند، می‌بیند این محافظت پایه روشن نیست، و آن را علامت‌گذاری می‌کند — معامله را متوقف یا از دست می‌دهید.
• یک نقض که به یک محافظت رایگان استاندارد گمشده رهگیری می‌شود به یک رویداد قابل گزارش تبدیل می‌شود: سؤالات مقامی، اعلان‌های مشتری، و آسیب اعتباری.

چرا اهمیت دارد. قفل اثبات می‌کند اتصال به سایت شما خصوصی است، اما هیچ‌کاری برای کنترل اینکه چه کدی پس از اینکه بازدیدکننده روی صفحه است اجرا می‌شود انجام نمی‌دهد. یک Content Security Policy محافظتی است که این کار را می‌کند — به مرورگرها می‌گوید هر اسکریپتی را که از منبعی که اعتماد دارید نیامده نادیده بگیرند، پس یک فیلد دستکاری شده تنها، تبلیغ، یا پلاگین نمی‌تواند به ابزاری برای دزدیدن پول و داده‌های مشتریان شما تبدیل شود.

این چیست، به زبان ساده

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

یک Content Security Policy (که اغلب به CSP کوتاه می‌شود) یک لیست کوتاه از قوانین است که وب‌سایت شما به هر صفحه ضمیمه می‌کند و به مرورگر می‌گوید: «فقط کدی از این منابعی که تأیید کرده‌ام اجرا کن و همه چیز دیگر را رد کن.»

دلیل اینکه این اینقدر مهم است: وب‌سایت‌ها مداوم دستکاری می‌شوند — نه همیشه با هک کردن سرور شما، بلکه از طریق درهای پشتی که بیشتر سایت‌ها باز می‌گذارند: یک کادر نظر، یک جعبه‌ی جستجو، یک پلاگین قدیمی، یک اسکریپت شخص ثالث برای تبلیغات یا analytics، یا یک ویجت چت.

این چقدر ممکن است برای شما هزینه داشته باشد

این انتزاعی نیست. حمله‌ای که یک Content Security Policy پیشگیری می‌کند — کد تزریق شده به صفحه که داده را از مشتریان خودتان می‌دزدد — پشت برخی از بزرگ‌ترین نقض‌های card-skimming ثبت شده است:

• Skimmer پنهان در صفحه‌ی خروج. مهاجم چند خط کد از طریق یک پلاگین آسیب‌پذیر یا اسکریپت شخص ثالث به خطر افتاده به صفحه‌ی خروج شما می‌لغزاند. هر شماره‌ی کارت، نام و CVV کپی و ارسال می‌شود. سایت شما عالی کار می‌کند؛ قفل وجود دارد.
• فرم پرداخت جعلی. کلاهبردار یک کادر ‘پرداخت اینجا’ قانع‌کننده وارد می‌کند. مشتریان با اعتماد به برند شما جزئیات وارد می‌کنند.
• قرارداد از دست رفته. تیم امنیتی یک مشتری بزرگ‌تر اسکن خودکار از سایت شما اجرا می‌کند. Content Security Policy گمشده فوراً به عنوان یک شکاف با شدت بالا ظاهر می‌شود.
• نقض قابل گزارش. وقتی یک نقض داده به یک محافظت رایگان استاندارد گمشده رهگیری می‌شود، دیگر بدشانسی نیست — شبیه به غفلت به نظر می‌رسد.

در واقع چیست (جزئیات)

یک Content Security Policy به عنوان یک HTTP response header تنها ارسال می‌شود. مقدار آن مجموعه‌ای از دستورالعمل‌ها است. مثلاً:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'

به زبان ساده: به طور پیش‌فرض فقط چیزهایی از سایت خودم را بارگذاری کن؛ فقط اسکریپت‌های سایت خودم را اجرا کن؛ هیچ پلاگین قدیمی را اجازه نده.

«خوب» چه شکلی است. بررسی ما فقط به دنبال حضور header نیست — سیاست را دستورالعمل به دستورالعمل می‌خواند و امتیاز می‌دهد. یک سیاست قوی:

• یک baseline محدودکننده تنظیم می‌کند و فقط برای شخص ثالث‌های مورد اعتماد خاصی که واقعاً استفاده می‌کنید آن را گسترش می‌دهد.
• از حفره‌ها پرهیز می‌کند. از 'unsafe-inline' یا 'unsafe-eval' برای اسکریپت‌ها استفاده نمی‌کند، و از منابع wildcard (*) یا طرح‌های bare (مثل https:) برای اسکریپت‌ها استفاده نمی‌کند.
• framing را با frame-ancestors 'self' قفل می‌کند و پلاگین‌های legacy را با object-src 'none' غیرفعال می‌کند.
• Enforcing است، نه report-only.

چگونه آن را رفع کنیم (رایگان، ~۱–۲ ساعت)

این را به IT یا هر کسی که وب‌سایت شما را اجرا می‌کند بدهید — خود اصلاح کاملاً رایگان است.

1. در حالت report-only شروع کنید — هنوز اجرا نکنید. یک Content-Security-Policy-Report-Only response header اضافه کنید. این تماشا و ثبت می‌کند چه چیزی بلاک می‌شد بدون اینکه چیزی را واقعاً بلاک کند.

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

3. از حفره‌هایی که کل هدف را شکست می‌دهند پرهیز کنید. از 'unsafe-inline' و 'unsafe-eval' برای اسکریپت‌ها و از منابع wildcard مثل * دور بمانید.

4. framing و پلاگین‌ها را قفل کنید. frame-ancestors 'self' و object-src 'none' اضافه کنید.

5. از report-only به enforcing تبدیل کنید. نام header را از Content-Security-Policy-Report-Only به Content-Security-Policy تغییر دهید. این مرحله‌ای است که واقعاً محافظت ارائه می‌دهد.

   کجا header را تنظیم کنید، بسته به پلتفرم:

   • Cloudflare: Rules → Transform Rules → Modify Response Header
   • Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
   • Apache: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"

6. دامنه‌ی خود را مجدداً بررسی کنید تا تأیید کنید سیاست روشن و enforcing است.

اشتباهات رایج

• توقف در report-only. رایج‌ترین خطا: یک سیاست در حالت report-only اضافه می‌شود و سایت هرگز واقعاً محافظت نمی‌شود.
• رسیدن برای 'unsafe-inline' تا آن را ‘فقط کار کند’.» وقتی سیاست یک اسکریپت inline مشروع را بلاک می‌کند، اصلاح سریع اجازه دادن به همه اسکریپت‌های inline است — اما این دقیقاً همان سوراخی که سیاست باید می‌بست را دوباره باز می‌کند.
• استفاده از wildcard. یک bare * در script-src اسکریپت‌های از هر جایی را اجازه می‌دهد.
• فراموش کردن منابع شخص ثالث. اجرای یک سیاست سختگیرانه بدون ابتدا فهرست کردن سرویس‌های خارجی مشروعی که استفاده می‌کنید می‌تواند بخش‌هایی از سایت شما را بشکند.
• تنظیم فقط روی صفحه‌ی اصلی. سیاست باید هر صفحه را پوشش دهد، خصوصاً checkout، ورود به سیستم و صفحات حساب.

پرسش‌های متداول