هدرهای HTTP

مطلب مجله

این مطلب بر اساس مقاله ای از برندن هجز در مجله انجمن جوملا! در شماره مه 2022 نوشته شده است. اگرچه برای جوملا 4 نوشته شده، اما محتوای آن به همان اندازه برای جوملا 5 نیز کاربرد دارد.

برای کسانی که درک این موضوع برایشان دشوار است، مقاله روشنگری از اسکات هلم با عنوان Content Security Policy - An Introduction وجود دارد.

پلاگین جدید هدرهای HTTP جوملا برای J4

در ادامه مطلب ماه گذشته درباره امنیت، رمز عبور و پلاگین WebAuthn جوملا، در این ماه قصد داریم به یکی دیگر از ویژگی های امنیتی جوملا بپردازیم که با J4 عرضه شد. این همان پلاگین هدرهای HTTP است که اکنون بخشی از عملکردهای هسته ای جوملا محسوب می شود.

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

معرفی پلاگین هدرهای HTTP در هسته جوملا 4 گامی بزرگ به جلو در کمک به ایمن سازی سایت شما در برابر حملات و فعالیت های مخرب است.

این پلاگین امنیتی سیستم به مالکان سایت کمک می کند تا به راحتی هدرهای امنیتی HTTP را از پیشخوان آشنای جوملا پیکربندی کنند، به جای این که مجبور باشند در فایل htaccess یا سایر فایل های پیکربندی جستجو کنند. یا، حتی بدتر از آن، در Cpanel میزبانی وب خود.

نگاه کنید ببینید تنظیم این موضوع در Cpanel چقدر پیچیده است و بعد به من بگویید که اشتباه نخواهید کرد! و همه این ها با این فرض است که وقتی چارچوب در Apache نصب شده و دایرکتوری ها ساخته شده اند، فرمت صحیح برای افزودن هدرهای HTTP که می خواهید ادغام کنید را می دانید.

چند بار سعی کرده اید یک دستور htaccess را پیاده سازی کنید و تنها نتیجه آن بارگذاری مجدد سایت و روبرو شدن با خطای http500 بوده است؟

بزرگ ترین مشکل این است که اگر فرمت هدر HTTP خود را دقیق تنظیم نکنید، سایت خود را خراب خواهید کرد.

حتی در آن صورت هم، آنچه برای یک سایت کار می کند ممکن است برای سایت دیگری کار نکند. نمونه خوبی از این موضوع فایل htaccess من و روشی است که برای تنظیم مرورگر جهت بارگذاری نسخه https بدون www سایتم استفاده کرده ام:

##www to non www and http to https mixin
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://mywebsite.co.uk%{REQUEST_URI} [R=301,L,NE]
##End www to non www and http to https mixin

این روش برای شرکت میزبانی قبلی من عالی کار می کرد. اما وقتی به یک میزبان دیگر تغییر دادم، دیگر کار نکرد. عجیب است!

کد htaccess که اکنون باید برای رسیدن به همان نتیجه استفاده کنم به این شکل است:

##www to non www and http to https mixin
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
RewriteCond %{ENV:HTTPS} !on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
##End www to non www and http to https mixin

گیج کننده است، درست است؟ و اگر در قالب بندی فقط یک اشتباه کنید، بوم! سایت خود را خراب کرده اید! خب، حداقل تا زمانی که کد خود را اصلاح کنید.

به همین دلیل است که ساده نگه داشتن چیزها، به عنوان بخشی از هسته جوملا، به معنای ناامیدی کمتر، زمان کمتر برای جستجوی اشتباهات خود در گوگل، و زمان بیشتر برای جشن گرفتن در حالی که روی صندلی خود لم داده اید و از سایت جدید خود تحسین می کنید.

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

هدرهای HTTP چه هستند؟

هدرهای HTTP نباید با بخش <head> سند HTML شما اشتباه گرفته شوند. آنها کاملاً متفاوت هستند. هدرهای HTTP مقدمه ای بین وب سرور شما و مرورگر هستند. مجموعه ای از دستورالعمل ها که به مرورگر می گویند چه چیزی، یا مهم تر از آن، چه چیزی را به بازدیدکننده نمایش ندهد.

می توانید هدرهای HTTP و نحوه ارتباط آنها با اشیاء HTML جداگانه را در ابزارهای توسعه دهنده مرورگر خود مشاهده کنید. در گوگل کروم، ابزارهای DEV را باز کنید، سپس برگه Network را باز کنید. اکنون صفحه وب را تازه سازی کنید و روی یک آیتم HTML در پانل سمت چپ کلیک کنید. هدر HTTP آن آیتم را در پانل سمت راست نمایش می دهد.

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

اگر یکی از آیتم های HTML شما نمایش داده نشد، ممکن است در هدرهای HTTP هم سرنخی درباره دلیل آن بیابید. در این مثال، تصویر دوم نمایش داده نشده است و می توانید از اطلاعات نمایش داده شده در پانل سمت راست ببینید که هیچ اطلاعات هدر HTTP وجود ندارد.

به جز این پیغام مبهم:

Referrer Policy: 'strict-origin-when-cross-origin'

'Strict-origin-when-cross-origin' به سادگی به این معنی است که وقتی یک آیتم HTML (در این مورد یک تصویر) از منبع دیگری (نه سرور شما) ارائه می شود، باید سیاست هدر HTTP تعیین شده در آن زمان رعایت شود. در این مثال، هدرهای HTTP، همان طور که در پلاگین جوملا تنظیم شده اند، تمام تصاویری را که از این سایت یا سایت دیگری که به طور خاص در پارامترهای هدر HTTP تنظیم شده در پلاگین هدرهای HTTP جوملا 'گنجانده' شده باشد، نشأت نمی گیرند، رد می کنند.

بنابراین، وقتی تصویر از سند HTML فراخوانی می شود، مرورگر آن را رد می کند و بارگذاری نمی شود.

که با پیدا نشدن و بازگرداندن پیغام خطای HTTP با کد 404 متفاوت است. در این حالت، سرور میزبان هنوز به دنبال تصویر می گردد، اما مرورگر آن را پیدا نکرده است.

پلاگین هدرهای HTTP جوملا چه کاری انجام می دهد

جدا از اینکه به مرورگر می گوید چه چیزی را نمایش دهد و اطلاعات کلی درباره سند HTML را برمی گرداند، هدرهای HTTP به کاهش حملات و آسیب پذیری های امنیتی که ممکن است در سایت جوملای شما وجود داشته باشد کمک می کنند. اینجاست که پلاگین هدرهای HTTP جوملا وارد عمل می شود. این کار را با نمایش صریح محتوای HTML بر اساس تنظیمات شما در خود پلاگین هدرهای HTTP جوملا انجام می دهد.

با افزودن هدرهای HTTP امنیتی اضافی به سایت جوملای خود با استفاده از پلاگین هدر HTTP، یک لایه امنیتی دیگر برای سایت جوملای خود فراهم می کنید.

این موضوع مهم است، زیرا به طور پیش فرض یک صفحه وب HTML تمام محتوای خود را به بازدیدکننده نمایش می دهد، چه خوب چه بد. مگر اینکه صراحتاً در هدرهای HTTP صفحه وب به آن گفته نشده باشد که این کار را نکند. این پلاگین با اجازه دادن به شما برای پیکربندی گزینه های امنیتی پیشرفته موجود در Content-Security-Policy برای سایت شما، این کار را انجام می دهد. این پلاگین را می توان بسته به نیاز شما برای هر سایت به شکل متفاوتی پیکربندی کرد، بنابراین سلاحی واقعاً انعطاف پذیر در زرادخانه شما در برابر هکرها است.

چرا به این پلاگین نیاز دارم؟

در دنیایی ایده آل، نیازی نداشتید. اما در دنیایی که در آن زندگی می کنیم، افراد بی وجدان بسیار زیادی هستند که به دنبال راه هایی برای کسب درآمد از افراد بی گناه و بی احتیاط می گردند. در دنیای ما، به این افراد هکر می گوییم. هکرها از هر راهی برای سوءاستفاده از آسیب پذیری های نرم افزاری به منظور کسب درآمد استفاده می کنند، که اغلب به ضرر صاحب سایت تمام می شود.

با استفاده از پلاگین هدر HTTP جوملا برای کنترل محتوایی که به بازدیدکنندگان شما ارائه می شود، شانس هکرها برای ارائه محتوای مخرب سایت به بازدیدکنندگان شما از طریق پلاگین های قدیمی و آسیب پذیر را کاهش می دهید. که به جلوگیری از تزریق اسکریپت های مخرب در سایت شما کمک می کند.

پس بیایید یک لحظه به این موقعیت فرضی فکر کنیم.

شما یک سایت جوملا 3 خوب دارید. 5 سال پیش ساخته شده و هنوز هم عالی به نظر می رسد و کار می کند. تمام کامپوننت ها، پلاگین ها و ماژول های شما بروزرسانی شده اند. عالیه، درسته؟

خب، نه کاملاً، زیرا وقتی 5 سال پیش سایت خود را ساختید، پلاگین مد روز Foo Bar را برای چاپ "FOO BAR" در صفحه اصلی خود نصب کردید. در ابتدا باحال به نظر می رسید، اما بعد از مدتی نظرتان عوض شد و کد کوتاه پلاگین {foo}FOO - BAR{/bar} را از مطلب صفحه اصلی خود حذف کردید.

اما، مشکل اینجاست: شما خود پلاگین را از انتشار خارج یا حذف نکردید و استفاده از آن از خاطر رفت. این چیزی است که مطمئنم همه ما مرتکب آن شده ایم.

سریع به امروز برویم، 5 سال بعد، آن پلاگین هنوز همان جاست، منتشر شده و فعال روی سایت شما، اما 5 سال است که بروزرسانی نشده چون مدت هاست آن را فراموش کرده اید، یا نویسنده اش پشتیبانی از آن را متوقف کرده است. حالا، یک فرد شرور متوجه شده که این پلاگین یک آسیب پذیری امنیتی دارد که می تواند برای شروع یک حمله Cross Site Scripting (XSS) روی سایت شما مورد سوءاستفاده قرار گیرد، و بازدیدکنندگان بی خبر شما را قربانی کند.

Cross-site scripting، که با نام XSS نیز شناخته می شود، یک آسیب پذیری امنیتی در سایت شماست که به مهاجم اجازه می دهد تعاملات کاربرانتان را با سایت اکنون آسیب پذیر شما به خطر بیندازد.

مهاجم/هکر از XSS برای سوءاستفاده از سایت آسیب پذیر شما استفاده می کند تا یک اسکریپت مخرب را برای کاربر بی خبر شما ارسال کند. از آنجا که اسکریپت از سایت شما آمده، مرورگر کاربر شما نمی داند یا مشکوک نیست که اسکریپت نباید مورد اعتماد باشد و آن را هنگام بارگذاری و باز شدن صفحه وب اجرا می کند.

اسکریپت های مخربی که به این شکل اجرا می شوند می توانند مشکلات زیادی برای کاربر شما ایجاد کنند، از سرقت رمزهای عبور و نام های کاربری ذخیره شده در کوکی ها گرفته تا ارسال کاربر شما به سایت های فیشینگ جعلی. اسکریپت ها حتی می توانند ظاهر صفحه وبی را که سایت شما ارائه می دهد تغییر دهند و تبلیغات متفاوتی را نشان دهند.

استفاده از پلاگین هدرهای HTTP جوملا به جلوگیری از cross-site scripting کمک می کند با اطمینان از اینکه فقط اسکریپت ها و محتوایی که می خواهید به بازدیدکننده خود ارائه دهید، در واقع ارائه می شوند. هر چیز دیگری مسدود می شود.

بنابراین، در مثال بالا، می توانستید پلاگین هدرهای HTTP را طوری پیکربندی کنید که فقط فایل های جاوااسکریپت (اسکریپت) سایت شما را از یک پوشه مشخص شده، یا شاید یک CDN اگر از آن استفاده می کنید، ارائه دهد تا جلوی حمله گرفته شود.

همچنین می توانستید سایت را از اجرای جاوااسکریپت درون خطی که در HTML جاسازی شده متوقف کنید. اما، توجه داشته باشید که بسته به نحوه طراحی HTML سایت خود، این کار ممکن است در آینده مشکلاتی ایجاد کند.

این کار سپس به جلوگیری از اجرای کد جاوااسکریپت مخرب روی سایت شما کمک می کند. حتی اگر پلاگین Foo Bar آسیب پذیر شما مقصر این بود که یک هکر از ابتدا توانست کد مخرب را به سایت شما تزریق کند.

توجه:

نقاط ضعف رایج در سایت هایی که مستعد حملات XSS هستند، فرم های ورودی کاربر هستند (صفحات ورود کاربر، فرم های ثبت نام خبرنامه، فرم های تماس با ما، و غیره) که بدون اعتبارسنجی و رمزگذاری هستند.

پلاگین هدرهای HTTP کجاست؟

می توانید پلاگین هدرهای HTTP جوملا را همراه با سایر پلاگین های جوملا پیدا کنید و دقیقاً به همان روشی که به آن عادت کرده اید به آن دسترسی پیدا کنید.

استفاده از پلاگین هدرهای HTTP

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

برای مثال:

هنگام کار با تصاویر، اصطلاح 'img-src' را خواهید دید، که در آن 'img' به تصاویر و 'src' به منبع معتبر تصویر اشاره دارد. اینها اصطلاحاتی هستند که از قبل با HTML پایه با آنها آشنا هستیم.

در پایان این مقاله، فهرستی از سایت های مفید با اطلاعات اضافی برای کمک به استفاده از این پلاگین جوملا وجود دارد.

تنظیمات پلاگین هدرهای HTTP - برگه 1

وقتی پلاگین را باز می کنید، اولین برگه باز شده تنظیمات پایه پلاگین است. در اینجا می توانید تنظیمات X-Frame Options، Referrer-Policy، Cross-Origin-Opener-Policy و همچنین Force HTTP Headers را تغییر دهید. همچنین پیوندهایی برای اطلاعات بیشتر وجود دارد تا به شما کمک کند عملکرد دقیق تر این موارد را درک کنید.

بیایید هر یک از این موارد را به ترتیب بررسی کنیم.

X-Frame Options

اولین تنظیم مربوط به X-Frame Options است. این گزینه به طور پیش فرض فعال است.

این گزینه به شما اجازه می دهد تصمیم بگیرید که آیا محتوای سایت شما می تواند در سایت دیگری در یک <frame>، <iframe>، <embed> یا <object> نمایش داده شود یا خیر. اگر این گزینه را غیرفعال کنید، هر سایت دیگری می تواند سایت شما را در یک iframe نمایش دهد.

پس از فعال سازی، یک برچسب ‘x-frame-options: SAMEORIGIN’ به هدرهای سایت شما افزوده می شود. این برچسب همچنان به شما اجازه می دهد محتوای خودتان را در یک <frame>، <iframe>، <embed> یا <object>، در سایت خودتان نمایش دهید. اما هیچ کس دیگری نمی تواند محتوای شما را در یک <iframe> در سایت خودش نمایش دهد.

هدر X-Frame Options به محافظت از سایت و کاربران شما در برابر حملات ‘Click Jacking’ کمک می کند. این حمله زمانی رخ می دهد که مهاجمی یک <iframe> را در سایت خودش قرار می دهد و منبع آن <iframe> را سایت شما تنظیم می کند. سپس مهاجم از لایه های شفاف چندگانه متعلق به سایت خودش بر روی آن استفاده می کند.

این کار کاربر را فریب می دهد تا روی دکمه یا لینکی در لایه شفاف بالایی کلیک کند، زیرا کاربر تصور می کند روی لینکی در iframe زیرین کلیک می کند.

بنابراین، مهاجم کلیک هایی را که برای صفحه قاب بندی شده اصلی در نظر گرفته شده، «ربوده» و به یک صفحه وب دیگر ارسال می کند.

مهم تر اینکه، روش های مشابهی می توانند برای برداشت کلیدهای فشرده شده و دریافت اطلاعات رمز عبور و نام کاربری ورود از حساب های ایمیل، حساب های شبکه های اجتماعی و البته حساب بانکی شما استفاده شوند.

اکثر مرورگرهای مدرن از X-Frame Options پشتیبانی می کنند، که عالی است. بنابراین، توصیه من این است که این تنظیم را در پلاگین هدرهای HTTP فعال کنید تا به محافظت از کاربرانتان در برابر قربانی شدن در حملات 'Click Jacking' کمک کنید.

اکثر مرورگرهای مدرن از X-Frame Options پشتیبانی می کنند.

Referrer-Policy

مورد بعدی در لیست برگه اول، Referrer-Policy است. این گزینه، در صورت فعال بودن، به شما اجازه می دهد انتخاب کنید که در صورت کلیک شدن روی یک لینک یا شیء HTML دیگر در سایت شما، چه میزان از داده های بالقوه سایت شما به سایت دیگری منتقل شود.

معمولاً، این را به صورت یک ویژگی HTML روی برچسب های <a> می بینیم، جایی که ممکن است لینکی را به شکل <a href=”https://someplace.com” rel=”noreferrer”>Click Me</a> فرمت کنید. برچسب noreferrer جزئیات صفحه وب ارسال کننده را از صفحه وب دریافت کننده مخفی نگه می دارد. این کار با حذف اطلاعات ارجاع از هدر HTTP صفحه وب انجام می شود.

آگاهی از داده هایی که سایت شما ممکن است به سایت دیگری که به آن لینک می دهید ‘نشت’ دهد، بخش مهمی از ایمن سازی سایت و کاربران آن است.

این موضوع به ویژه در صورتی اهمیت دارد که به کاربران اجازه ثبت نام بدهید، سایت شما حاوی داده های حساس باشد، یا تراکنش های مالی را مدیریت کند. پلاگین هدرهای HTTP جوملا به کنترل این موضوع در سطح کلی، به جای سطح لینک های منفرد، کمک می کند.

به طور پیش فرض، Referrer Policy سایت شما روی ‘strict-origin-when-cross-origin’ تنظیم شده است. که هیچ یک از داده های ارجاع را از صفحه وب مبدأ مسدود نمی کند مگر اینکه به یک صفحه http کمتر ایمن ارسال شود. اما، از آنجا که امروزه اکثر صفحات وب از https استفاده می کنند، این موضوع اکنون مشکل بزرگ تری نسبت به گذشته است.

البته استفاده های بی ضرر زیادی از این داده های ‘درز کرده’ وجود دارد اگر برای سایت خود Referrer Policy تنظیم نکنید. این موارد می تواند شامل داده های جمع آوری شده توسط سایت پیوند داده شده برای تحلیل، ثبت گزارش، یا ذخیره سازی بهینه باشد.

متأسفانه، هر سایت ارجاع داده شده ای از داده های ‘درز کرده’ شما برای چنین عملیات بی ضرری استفاده نمی کند. وضعیت زیر را به عنوان مثال در نظر بگیرید.

بیشتر سایت هایی که امکان ثبت نام کاربر را فراهم می کنند، لینک بازنشانی رمز عبور را در کنار فرم ورود خود در صفحه ورود/ثبت نام دارند. همچنین احتمال دارد این صفحه حاوی لینک های دیگری به سایت های خارجی، لینک های شبکه های اجتماعی، یا شاید برخی ‘لینک های مفید’ در پاورقی باشد.

همه این ها از محیط امن شما خارج می شوند. حال، اگر هیچ Referrer Policy تنظیم نشده باشد، ممکن است هدر ارجاع (Referrer Header) ارسالی به یکی از آن سایت های خارجی هنگام کلیک روی لینکی از آن صفحه ورود، حاوی لینک بازنشانی رمز عبور باشد. و همچنین سایر اطلاعاتی که با آن سایت خارجی به اشتراک گذاشته اید.

این ممکن است با به خطر انداختن داده های کاربر، خطری امنیتی ایجاد کند.

به دلیل خطر امنیتی بالقوه در این نوع صفحات حساس به داده، بهتر است تمام محتوای شخص ثالث را از صفحه حذف کنید. این شامل تمام لینک ها و محتوای ارائه شده در <iframes> مانند ابزارک های شبکه های اجتماعی و ویدیوهای یوتیوب می شود. زیرا داده های وارد شده در این صفحه ممکن است از طریق هدر ارجاع به آن سایت ها ارسال شود، اگر روی آن ویدیوی بامزه بچه گربه که ظاهر شده کلیک کنید.

پلاگین هدرهای HTTP جوملا این مشکل را با اجازه دادن به شما برای انتخاب یکی از 8 Referrer Policy برای تنظیم یک Referrer Policy برای سایت خود، حل می کند. هر کدام با محدودیت های خاص خود در مورد زمان و میزان داده ای که به اشتراک گذاشته می شود.

بیایید نگاهی به این موارد بیندازیم. توضیح بسیار خوبی از آن ها در صفحه هدرهای موزیلا وجود دارد که آن ها را این گونه توصیف می کند:

• no-referrer
  هدر ارجاع حذف خواهد شد: درخواست های ارسالی هیچ اطلاعات ارجاعی را شامل نمی شوند.
• no-referrer-when-downgrade
  مبدأ، مسیر و رشته پرس و جو را در هدر ارجاع ارسال کنید وقتی سطح امنیت پروتکل یکسان بماند یا بهبود یابد (HTTP→HTTP، HTTP→HTTPS، HTTPS→HTTPS). هدر ارجاع را برای درخواست ها به مقصدهای کمتر امن ارسال نکنید (HTTPS→HTTP، HTTPS→file).
• origin
  فقط مبدأ را در هدر ارجاع ارسال کنید. برای مثال، سندی در https://example.com/page.html ارجاع https://example.com/ را ارسال خواهد کرد.
• origin-when-cross-origin
  هنگام انجام یک درخواست هم مبدأ به همان سطح پروتکل (HTTP→HTTP، HTTPS→HTTPS)، مبدأ، مسیر و رشته پرس و جو را ارسال کنید. برای درخواست های بین مبدأ و درخواست ها به مقصدهای کمتر امن (HTTPS→HTTP) فقط مبدأ را ارسال کنید.
• same-origin
  مبدأ، مسیر و رشته پرس و جو را برای درخواست های هم مبدأ ارسال کنید. هدر ارجاع را برای درخواست های بین مبدأ ارسال نکنید.
• strict-origin
  فقط مبدأ را زمانی ارسال کنید که سطح امنیت پروتکل یکسان بماند (HTTPS→HTTPS). هدر ارجاع را به مقصدهای کمتر امن ارسال نکنید (HTTPS→HTTP).
• strict-origin-when-cross-origin (پیش فرض)
  ارسال مبدأ، مسیر و رشته پرس و جو هنگام انجام درخواست هم مبدأ. برای درخواست های بین مبدأ، فقط مبدأ را زمانی ارسال کنید که سطح امنیت پروتکل یکسان بماند (HTTPS→HTTPS). هدر Referrer را به مقصدهای کم امنیت تر ارسال نکنید (HTTPS→HTTP). توجه: این سیاست پیش فرض است اگر سیاستی مشخص نکنید، یا اگر مقدار ارائه شده نامعتبر باشد. پیش تر، پیش فرض no-referrer-when-downgrade بود.
• unsafe-url
  ارسال مبدأ، مسیر و رشته پرس و جو هنگام انجام هر درخواستی، بدون توجه به امنیت. هشدار: این سیاست ممکن است اطلاعات بالقوه خصوصی را از آدرس های منابع HTTPS به مبداهای ناامن افشا کند. تأثیر این تنظیم را با دقت در نظر بگیرید.

Cross-Origin-Opener-Policy

سومین گزینه برای تنظیم در برگه اول Cross Origin Opener Policy است، که یک ویژگی امنیتی مبتنی بر مرورگر است که به شما اجازه می دهد 'گروه های زمینه مرورگر' مختلف را از یکدیگر جدا کنید.

یک مثال خوب از این، استفاده از پنجره های بازشو است. جایی که گروه زمینه مرورگر اصلی (همه متن ها، تصاویر، لینک ها و غیره) از یک گروه زمینه مرورگر جدید که ایجاد شده و سپس در پنجره بازشو نمایش داده می شود، جدا می گردد.

این گزینه هدر HTTP نسبتاً عمیق و پیچیده است، اگرچه فقط 3 گزینه دارد. بنابراین شما را تشویق می کنم لینک های زیر را بررسی کنید تا درک بهتری از دلیل نیاز به تنظیم این گزینه در سایت خود پیدا کنید. همچنین با برخی از ویژگی های پیشرفته ای که با فعال بودن این گزینه در دسترس شما قرار می گیرد آشنا شوید.

Cross Origin Opener Policy به بستن یک حفره تاریخی در نحوه اشتراک گذاری داده بین گروه های زمینه مختلف توسط مرورگرها کمک می کند، به ویژه زمانی که پنجره های بازشو در سایت استفاده می شوند.

تنظیم COOP به شما کمک می کند تا تهدیدات امنیتی داده را کاهش دهید، که رایج ترین آن به 'Spectre' معروف است. Spectre داده هایی که در همان گروه زمینه مرورگری که کد شما در آن بارگذاری شده قرار دارند را به طور بالقوه برای هکر قابل خواندن می کند. Spectre اجازه می دهد زمان انجام برخی عملیات اندازه گیری شود. این به هکرها اجازه می دهد حدس بزنند در ذخیره ساز CPU چه چیزی وجود دارد. اگر در این کار موفق شوند، خواهند دانست در حافظه پردازش چه چیزی وجود دارد. سپس به داده های شما دسترسی پیدا می کنند. که ممکن است حساس باشند.

COOP با جدا کردن داده های سند HTML اصلی شما از داده های HTML که در یک پنجره بازشو از سند اصلی نمایش داده می شود، کار می کند. این به جلوگیری از چیزی که به آن حملات cross-origin، یا XS-Leaks گفته می شود کمک می کند.

این فرآیند مشابه rel=”noopener” آشنایی است که در لینک های معمولی استفاده می کنیم. اما، برخلاف rel=”noopener” که فقط در لینک های خروجی فعال است، اسنادی که دارای cross-origin-opener-policy تنظیم شده در هدرهای HTTP توسط پلاگین جوملا هستند، داده را در هر دو جهت محدود می کنند. بنابراین، سند HTML که دارای سیاست COOP فعال است، ارجاعی به آن در هدر HTTP نخواهد داشت، و ویژگی window.opener هدر HTTP پنجره جدید روی null تنظیم خواهد شد.

هنگام تنظیم این گزینه در پلاگین هدرهای HTTP جوملا، 3 گزینه در دسترس شما قرار دارد.

• unsafe-none
  این مقدار پیش فرض است. این گزینه اجازه می دهد سند شما به گروه زمینه مرورگر بازکننده خود اضافه شود، مگر اینکه خود بازکننده دارای cross-origin-opener-policy با مقدار same-origin یا same-origin-allow-pop-ups باشد.
• same-origin-allow-popups
  این گزینه ارجاعات به پنجره ها یا برگه های تازه بازشده را که یا cross-origin-opener-policy تنظیم نمی کنند، یا با تنظیم cross-origin-opener-policy روی unsafe-none خود از ایزوله سازی انصراف می دهند، حفظ می کند.
• same-origin
  گروه زمینه مرورگر را فقط به اسناد هم مبدأ ایزوله می کند. اسناد cross-origin در همان گروه زمینه مرورگر بارگذاری نمی شوند.

Force HTTP Headers

آخرین گزینه ای که باید در برگه اول روی آن تمرکز کرد Force HTTP Headers است، که نباید آن را با 'Force HTTPS' در تنظیمات عمومی جوملا اشتباه گرفت.

این بخش از پلاگین هدرهای HTTP جوملا به شما اجازه می دهد، در صورت تمایل، مجموعه ای از هدرهای 'دیگر' که به طور خاص در برگه های پلاگین ذکر نشده اند را اضافه کنید، و همچنین درج برخی از هدرهایی که قبلاً گنجانده شده اند را اجباری کنید.

از لیست کشویی، در حال حاضر 10 گزینه دارید. اما شایان ذکر است که برخی از این موارد ممکن است به مرور زمان حذف شوند زیرا سیاست های هدری که به آنها اشاره دارند قرار است تغییر کنند یا بازنگری شوند.

هدرهای HTTP فعلی که می توانید مستقیماً در اینجا تنظیم کنید، هدرهایی هستند که موارد زیر را هدف قرار می دهند:

می توانید اطلاعات بیشتری درباره هر ویژگی را در سایت Mozilla Developers بدست آورید.

Content-Security-Policy (list)

هدر پاسخ Content-Security-Policy به سایت ها اجازه می دهد منابعی که کاربر ممکن است برای هر صفحه وب بارگذاری کند را کنترل کنند. سیاست ها عمدتاً مبداهای سرور و نقاط پایانی اسکریپت را مشخص می کنند. این امر در برابر حملات cross-site scripting محافظت می کند. Mozilla: Content-Security-Policy

Content-Security-Policy-Report-Only

هدر پاسخ HTTP با عنوان Content-Security-Policy-Report-Only به توسعه دهندگان وب اجازه می دهد با نظارت بر اثرات سیاست ها (بدون اجرای آنها) آزمایش کنند. Mozilla: Content-Security-Policy-Report-Only

Cross-Origin-Opener-Policy (COOP)

هدر پاسخ HTTP با عنوان Cross-Origin-Opener-Policy (COOP) به شما امکان می دهد اطمینان حاصل کنید که یک سند سطح بالا، گروه زمینه مرورگر را با اسناد cross-origin به اشتراک نمی گذارد. Mozilla: Cross-Origin-Opener-Policy

COOP سند شما را از نظر فرآیند ایزوله می کند و مهاجمان احتمالی در صورت باز کردن آن در یک پنجره بازشو، نمی توانند به شیء سراسری شما دسترسی داشته باشند، که این امر از مجموعه ای از حملات cross-origin موسوم به XS-Leaks جلوگیری می کند.

Expect-CT (منسوخ خواهد شد)

هدر Expect-CT به سایت ها اجازه می دهد در گزارش دهی و/یا اجرای الزامات Certificate Transparency مشارکت کنند، تا از استفاده بدون توجه از گواهی های صادر شده اشتباه برای آن سایت جلوگیری شود. Mozilla: Expect-CT (منسوخ خواهد شد)

Feature-Policy (اکنون منسوخ شده)

هدر HTTP با عنوان Feature-Policy مکانیزمی برای اجازه دادن و ممنوع کردن استفاده از ویژگی های مرورگر در فریم خود، و در محتوای هر عنصر <iframe> موجود در سند فراهم می کند. Mozilla: Feature-Policy

Permissions-Policy

این جایگزین Feature-Policy بالا است. Mozilla: Permissions-Policy (جایگزین Feature Policy بالا)

Referrer-Policy (در لیست)

هدر HTTP با عنوان Referrer-Policy میزان اطلاعات ارجاع دهنده (ارسال شده با هدر Referrer) که باید همراه درخواست ها گنجانده شود را کنترل می کند. Mozilla: Referrer-Policy

Report-To

بخشی از Content-Security-Policy. فیلد هدر پاسخ HTTP با عنوان Content-Security-Policy Report-To به عامل کاربر دستور می دهد نقاط پایانی گزارش دهی را برای یک مبدا ذخیره کند. Mozilla: Report-To

دستورالعمل report-to قرار است جایگزین دستورالعمل منسوخ شده report-uri شود، report-to هنوز در اکثر مرورگرها پشتیبانی نمی شود.

Strict-Transport-Security

هدر پاسخ HTTP با عنوان Strict-Transport-Security (که اغلب به اختصار HSTS نامیده می شود) به مرورگرها اطلاع می دهد که سایت باید فقط با استفاده از HTTPS قابل دسترسی باشد، و هرگونه تلاش آینده برای دسترسی به آن با استفاده از HTTP باید به طور خودکار به HTTPS تبدیل شود. Mozilla: Strict-Transport-Security

این روش امن تر از صرفاً پیکربندی یک تغییر مسیر (301) HTTP به HTTPS در سرور شما است، جایی که اتصال اولیه HTTP همچنان در برابر حمله مرد میانی آسیب پذیر است.

X-Frame-Options (در لیست)

هدر پاسخ HTTP با عنوان X-Frame-Options نشان می دهد که آیا یک مرورگر باید اجازه داشته باشد یک صفحه را در <frame>، <iframe>، <embed> یا <object> نمایش دهد یا خیر. سایت ها می توانند از این برای جلوگیری از حملات click-jacking استفاده کنند، با اطمینان از اینکه محتوای آنها در سایت های دیگر جاسازی نمی شود. Mozilla: X-Frame-Options

امنیت اضافه شده فقط در صورتی ارائه می شود که کاربر دسترسی کننده به سند از مرورگری استفاده کند که از X-Frame-Options پشتیبانی می کند.

هدر X-Frame-Options دارای آیتم های فرزندی به نام frame-ancestors است که جایگزین هدر Frame-Options می شوند. اگر یک منبع هر دو سیاست را داشته باشد، سیاست frame-ancestors اجرا شده و سیاست X-Frame-Options نادیده گرفته می شود.

با استفاده از فیلد HTTP Header Value، می توانید مقادیری را که می خواهید دنبال شوند تنظیم کرده و آنها را به سایت خود، سایت مدیریت یا هر دو اختصاص دهید.

تنظیمات پلاگین هدرهای HTTP - برگه 2

Strict-Transport-Security (HSTS)

برگه Strict Transport Security Policy به طور پیش فرض غیرفعال است.

من عاشق تحقیق کردن هستم. چون گاهی اوقات به یک لحظه واقعی OMG! بر می خورید. این یکی از آن لحظات است.

ویکی پدیا بیان می کند:

شرکت Netscape Communications در سال 1994 پروتکل HTTPS را برای مرورگر وب Netscape Navigator خود ایجاد کرد. در ابتدا، HTTPS با پروتکل SSL استفاده می شد. با تکامل SSL به Transport Layer Security (TLS)، HTTPS به طور رسمی توسط RFC 2818 در ماه مه سال 2000 مشخص شد. گوگل در فوریه 2018 اعلام کرد که مرورگر Chrome آن پس از ژوئیه 2018 سایت های HTTP را «ناامن» علامت گذاری خواهد کرد. این اقدام برای تشویق صاحبان سایت ها به پیاده سازی HTTPS، به عنوان تلاشی برای ایمن تر کردن وب جهان گستر بود.» ……

چه کسی فکرش را می کرد که Netscape پروتکل های HTTPS را این قدر پیش تر اختراع کرده باشد؟ حتی شگفت انگیزتر این است که چقدر طول کشید تا آن را در اینترنتی که امروز می شناسیم و دوستش داریم پیاده سازی کنند.

سال هاست که آنها ما را ترغیب، مجبور و در نهایت تهدید کرده اند تا HTTPS را روی تمام سایت های خود پیاده سازی کنیم. اکثر ما تسلیم شدیم و وب جهان گستر اکنون بالاخره امن است. یا شاید هم نه؟

با این حال، برخی سایت های سرسخت، باقی مانده یا فراموش شده هنوز هم فقط از http برای ارائه محتوای خود استفاده می کنند، البته با هشدار «این سایت ناامن است» از گوگل/فایرفاکس و غیره.

یک جستجوی سریع در گوگل چندین لیست قدیمی از آن سایت های «فقط HTTP مقصر» را نشان داد. اگرچه از زمان انتشار آن لیست ها، بسیاری از سایت ها به HTTPS بروزرسانی شده اند. با این حال، برخی استثناهای بارز از سازمان هایی وجود داشت که انتظار می رفت بهتر از این عمل کنند.

برای مثال:

• NGINX (http://nginx.org/)
• GNU (http://www.gnu.org/)
• دانشگاه واشینگتن (http://www.washington.edu/)

طبق گزارش w3techs.com حدود 20% از تمام سایت ها هنوز فقط روی HTTP اجرا می شوند.

پس، چرا این یک مسئله است؟

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

اما حتی سایت های ساده نیز می توانند قربانی هکرها و مهاجمانی شوند که click-jacking و دیگر حملات cross-origin را که به کاربران شما آسیب می رساند، اجرا می کنند.

سایتی که داده های کاربر یا اطلاعات ورود را رد و بدل نمی کند، باز هم باید از HTTPS استفاده کند.

خب، برگردیم به موضوع اصلی.

همانطور که می دانید، کل هدف HTTPS برقراری یک اتصال امن بین مرورگر کاربر و سرور شماست. اتصالی که در آن هرگونه تبادل داده در محیطی امن اتفاق می افتد که نمی تواند توسط شخص ثالث - یک مرد میانی - رهگیری و کپی شود.

اما آیا می دانستید که مگر اینکه گواهی SSL HTTPS شما از TLS استفاده کند، اتصال 'امن' شما به اندازه ای که انتظار دارید امن نیست؟ اتصالات HTTPS بدون TLS همچنان در برابر حملات مرد میانی آسیب پذیر هستند.

اگرچه این یک پست وبلاگ قدیمی است، این مقاله به خوبی توضیح می دهد که حمله مرد میانی چگونه کار می کند.

مرورگرها به طور گسترده TLS را پذیرفته اند.

و، TLS 1.3 به طور مستقیم با نسخه های قبلی سازگار نیست مگر اینکه در حالت سازگاری اجرا شود. که این می تواند برای برخی مشکل ساز باشد.

استفاده از پلاگین هدرهای HTTP جوملا برای مدیریت Strict-Transport-Security (HSTS) به کاهش حملات مرد میانی با اجباری کردن استفاده از TLS در مرورگر وب بازدیدکنندگان شما کمک می کند. TLS تضمین می کند که تمام ارتباطات وب در سمت مشتری با استفاده از یک لایه انتقال امن انجام شود.

آیا شما از یک تغییر مسیر 301 برای ارائه نسخه غیرامن HTTP سایت خود به نسخه امن HTTPS استفاده می کنید؟

اکثر افراد این کار را می کنند. تغییر مسیرهای 301 دستوراتی هستند که بیشتر صاحبان سایت در فایل htaccess خود تنظیم می کنند. آنها به گوگل اطلاع می دهند که نسخه ای از سایت که باید استفاده شود، نسخه HTTPS (امن) است. مشکل این است که 301 فقط یک تغییر مسیر آدرس است، بنابراین سایت شما همچنان بخشی از اتصال اولیه را از طریق HTTP انجام می دهد.

برخلاف اتصالات بین کاربر و سرور سایت که از HSTS استفاده می کنند، جایی که سرور به طور خودکار فقط با استفاده از HTTPS تعامل می کند.

با این حال، HSTS یک نقطه ضعف دارد، زیرا اولین اتصال اولیه بین مرورگر کاربر و سرور سایت همچنان از طریق HTTP اتفاق می افتد. اما تمام اتصالات بعدی به طور خودکار از طریق HTTPS برقرار می شوند تا زمانی که تاریخ انقضای HTTP Header فرا برسد و این هدر بازنشانی شود.

این برخلاف یک تغییر مسیر 301 استاندارد است که در آن هر بارگذاری صفحه شامل یک درخواست http اولیه برای شروع اتصال https است.

راه حلی برای این ضعف در تنظیمات HSTS هدرهای HTTP وجود دارد، 'Preload' را فعال کنید.

که برچسب 'Preload' را به هدر پاسخ اضافه می کند.

در تنظیمات، یک لیست preload پیوند نیز وجود دارد**. این لیستی است که در بسیاری از مرورگرهای مدرن به صورت hard coded قرار داده شده است. این لیست به مرورگر اطلاع می دهد که اتصال به example.com فقط باید از طریق HTTPS برقرار شود. بنابراین نیازی به برقراری حتی اتصال اولیه از طریق HTTP نیست.

پس از راه اندازی HSTS در پلاگین هدر HTTP جوملا، تمام تگ های لازم به هدر پاسخ HTTP اضافه می شوند. این کار به مرورگر هر کاربری که سعی در اتصال به سرور شما دارد اطلاع می دهد که تمام اتصالات باید با HTTPS برقرار شوند، چه در HTML شما مشخص شده باشد چه نشده باشد.

در خلاصه، استفاده از پلاگین هدرهای HTTP جوملا برای یکپارچه سازی HSTS به جای تکیه بر تغییر مسیرهای 301 برای ارائه محتوای شما از طریق HTTPS، یک بهبود امنیتی مهم است. بهبودی که به جلوگیری از حملات مرد میانی کمک می کند و محیطی امن برای کاربر شما فراهم می کند.

HSTS کل دامنه را پوشش می دهد، برخلاف تغییر مسیر 301 که فقط یک مسیر URI خاص را پوشش می دهد.

HSTS از یک ذخیره ساز مرورگر جداگانه استفاده می کند که معمولاً مجزا است، بنابراین نمی توان به راحتی یا به طور تصادفی آن را پاک کرد.

HSTS می تواند در مرورگر پیش بارگذاری (Preload) شود. این تضمین می کند که کاربر فقط با HTTPS به سرور شما متصل می شود، صرف نظر از اینکه قبلاً از سایت بازدید کرده باشد یا نه.

تنظیمات پلاگین هدرهای HTTP - برگه 3

Content Security Policy (برگه 3)

برگه Content Security Policy به طور پیش فرض غیرفعال است.

وقتی Content Security Policy جوملا را از طریق پلاگین هدرهای HTTP فعال می کنید، به مرورگر بازدیدکننده خود دقیقاً می گویید که چه ارزش هایی از سرور سایت شما بارگذاری شوند. که راه خوبی برای اطمینان از این است که فقط محتوایی را که واقعاً می خواهید ارائه دهید، تحویل می دهید.

داشتن یک Content Security Policy مؤثر، راه مؤثری برای جلوگیری از حملات Cross Site Scripting (XSS) و Click Jacking است که منشأ آنها از سایت شماست.

Cross-Site Scripting، که با نام حمله XSS نیز شناخته می شود، حمله ای به سایت شماست که در آن یک اسکریپت مخرب به یک سایت بی خبر و در غیر این صورت قابل اعتماد 'تزریق' می شود. مهاجمان نقطه ضعفی را برای سوءاستفاده پیدا می کنند که معمولاً جایی است که کاربر می تواند داده وارد کند.

کامپوننت های قدیمی که امکان ورود داده توسط کاربر را فراهم می کنند، به عنوان مثال فرم های نظر بدون اعتبارسنجی، ممکن است دارای آسیب پذیری هایی باشند که می توانند در یک حمله Cross Site Scripting مورد سوءاستفاده قرار گیرند. به همین دلیل است که همیشه بروزرسانی کامپوننت های جوملای خود و به حداقل رساندن این فرصت ها ایده خوبی است.

بنابراین، با استفاده از فرم نظرات آلوده به عنوان مثال:

سایت شما از یک فرم نظرات در انتهای مطلب برای جمع آوری بحث کاربران استفاده می کند، همان طور که بسیاری از سایت ها این کار را می کنند. که عالی است.

افزونه نظرات شما از dodgy-joomla-extensions.com به خوبی کار می کند و کاربران شما آن را دوست دارند. اما شما آن را به مدت 5 سال بروزرسانی نکرده اید و توسعه دهندگان آن مدت هاست آن را رها کرده اند.

حالا، 5 سال بعد، آقای هکر متوجه می شود که به دلیل یک آسیب پذیری در کد کامپوننت نظرات، می تواند قطعه کد مخربی را در یک نظر که در ظاهر بی ضرر به نظر می رسد، پنهان کند.

کاری که آن کد در نهایت انجام می دهد متفاوت است، اما چیزی که می توانید روی آن حساب کنید این است که هر بار صفحه مطلب بی گناه شما، همراه با نظرات، بارگذاری می شود، آن کد مخرب نیز بارگذاری و اجرا می شود. بالاخره این هم بخشی از HTML است و مرورگر نمی داند که نباید آنجا باشد یا قابل اعتماد نیست.

پس، کد مخرب اجرا می شود. شاید داده های کوکی شما را بررسی کند. شاید داده های حساسی را که مرورگر نگه داری می کند، سرقت کند. یا، شاید تبلیغاتی از کازینوهای آنلاین یا سایت های بزرگسالان بارگذاری کند. شاید کل HTML صفحه وب بی گناه شما درباره آن بچه گربه های بامزه را از یک فایل جاوا اسکریپت خارجی دوباره بارگذاری کند تا جزئیات کارت اعتباری کاربران شما را سرقت کند.

در واقع، در این مرحله یک اسکریپت می تواند برای انجام تقریباً هر کاری اجرا شود.

یک Content Security Policy خوب به جلوگیری از این نوع حمله کمک می کند، حتی اگر افزونه نظرات آسیب دیده شما هدف آقای هکر قرار گیرد.

این کار را انجام می دهد زیرا پلاگین هدرهای HTTP جوملا، CSP را به عنوان یک HTTP Response Header ارائه می دهد، که به طور صریح به مرورگر می گوید چه چیزی را بارگذاری کند. در تنظیمات برگه CSP در پلاگین هدرهای HTTP، می توانید مستقیماً 28 Policy Directive را هدف قرار دهید. این دایرکتیوها به ایمن سازی سایت شما با استفاده فقط از منابع تأیید شده برای فایل ها و محتوای شما کمک می کنند.

مثال حمله بالا در نهایت منجر به بارگذاری یک فایل جاوا اسکریپت از یک منبع متفاوت شد تا خروجی HTML نمایش داده شده روی صفحه را تغییر دهد. این می توانست با افزودن دایرکتیو script-src 'self' به CSP جوملا در پلاگین جلوگیری شود.

در این مثال، مرورگر فقط فایل های جاوا اسکریپت موجود در سند HTML را در صورتی بارگذاری می کند که از دامنه شما منشأ گرفته باشند. تمام فایل های جاوا اسکریپت دیگر، از جمله فایل های آقای هکر، رد خواهند شد.

در حالی که این به ایمن سازی سایت شما کمک می کند، می تواند سایر فایل های جاوا اسکریپت قانونی که می خواهید هنگام رندر شدن صفحه وب روی صفحه بارگذاری شوند را نیز متوقف کند. این فایل های خارجی را می توان به عنوان منابع لیست سفید در همان دایرکتیو اضافه کرد. برای مثال، اگر از bootstrap از یک CDN استفاده می کنید، باید این را اضافه کنید:

script-src 'self' https://cdn.jsdelivr.net

در این مثال اگر در بارگذاری bootstrap از CDN، https://cdn.jsdelivr.net، مشکل داشتید، می توانید افزودن آدرس کامل فایل bootstrap مورد نیاز خود را امتحان کنید. پس، دایرکتیو خود را به این شکل فرمت می کنید: script-src 'self' https://cdn.jsdelivr.net/npm/[email protected]/dist/js/bootstrap.min.js.

افزودن این منابع خارجی هنگام ساخت یک سایت جدید راحت تر قابل اجرا است. اما اگر HTML رندر شده سایت قدیمی خود را با ابزارهای DEV بررسی کنید، باید بتوانید تمام فایل های خارجی که در حال حاضر در سایت شما استفاده می شوند را پیدا کرده و آنها را در CSP خود قرار دهید.

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

گزینه های دیگری نیز برای برخی از دستورالعمل های پیشرفته تر در دسترس هستند، لیست کامل تر و نمونه های استفاده از آنها را می توانید در سایت Content Security Policy (CSP) Quick Reference Guide بیابید.

• 'none' استفاده از این نوع منبع را مسدود می کند.
• 'self' با مبدأ فعلی مطابقت دارد (اما نه زیردامنه ها).
• 'unsafe-inline' استفاده از JS و CSS درون خطی را مجاز می کند.
• 'unsafe-eval' استفاده از مکانیزم هایی مانند eval() را مجاز می کند.

حال، بیایید نگاهی به برخی از این دستورالعمل ها بیندازیم. در زیر لیستی از برخی از دستورالعمل های موجود در پلاگین هدرهای HTTP جوملا، به همراه توضیحی مختصر، با لطف Content Security Policy آورده شده است. توصیه می کنم برای اطلاعات و نمونه های بیشتر از این سایت بازدید کنید.

default-src

دستورالعمل default-src، سیاست پیش فرض برای دریافت منابعی مانند JavaScript، تصاویر، CSS، فونت ها، درخواست های AJAX، فریم ها، رسانه HTML5 را تعریف می کند.
نمونه سیاست DEFAULT-SRC
default-src 'self' https://cdn.example.com

script-src

منابع معتبر JavaScript را تعریف می کند.
نمونه سیاست SCRIPT-SRC
script-src 'self' https://js.example.com

style-src

منابع معتبر شیت های استایل یا CSS را تعریف می کند.
نمونه سیاست STYLE-SRC
style-src 'self' css.example.com

img-src

منابع معتبر تصاویر را تعریف می کند.
نمونه سیاست IMG-SRC
img-src 'self' https://img.example.com https://example.com

connect-src

برای XMLHttpRequest (AJAX)، WebSocket، fetch()، <a ping> یا EventSource اعمال می شود. اگر مجاز نباشد، مرورگر کد وضعیت HTTP 400 را شبیه سازی می کند.
نمونه سیاست CONNECT-SRC
connect-src 'self'

font-src

منابع معتبر فونت (بارگذاری شده از طریق @font-face) را تعریف می کند.
نمونه سیاست FONT-SRC
font-src https://font.example.com https://example.com

object-src

منابع معتبر پلاگین ها، مانند <object>، <embed> یا <applet> را تعریف می کند.
نمونه سیاست OBJECT-SRC
object-src 'self'

media-src

منابع معتبر صدا و تصویر، مانند عناصر HTML5 <audio>، <video> را تعریف می کند.
نمونه سیاست MEDIA-SRC
media-src https://media.example.com

frame-src

منابع معتبر برای بارگذاری فریم ها را تعریف می کند. در CSP نسخه 2، frame-src به نفع دستورالعمل child-src منسوخ شده بود. در CSP نسخه 3، این وضعیت منسوخ بودن برداشته شده و در صورت عدم وجود، همچنان به child-src واگذار می شود.
نمونه سیاست FRAME-SRC
frame-src 'self'

sandbox

یک sandbox برای منبع درخواست شده مشابه ویژگی sandbox در iframe فعال می کند. sandbox یک سیاست same-origin اعمال می کند، از پاپ آپ ها جلوگیری می کند، پلاگین ها و اجرای اسکریپت مسدود می شوند. می توانید مقدار sandbox را خالی بگذارید تا تمام محدودیت ها اعمال شوند، یا مقادیری اضافه کنید: allow-forms، allow-same-origin، allow-scripts، allow-pop-ups، allow-modals، allow-orientation-lock، allow-pointer-lock، allow-presentation، allow-popups-to-escape-sandbox، و allow-top-navigation.
نمونه سیاست SANDBOX
sandbox allow-forms allow-scripts

report-uri

به مرورگر دستور می دهد گزارش های خطاهای سیاست را به این URI ارسال (POST) کند. همچنین می توانید از Content-Security-Policy-Report-Only به عنوان نام هدر HTTP استفاده کنید تا به مرورگر دستور دهید فقط گزارش ها را ارسال کند (چیزی را مسدود نمی کند). این دستور در CSP Level 3 منسوخ شده و به نفع دستور report-to کنار گذاشته شده است.
مثال REPORT-URI
report-uri /some-report-uri

child-src

منابع معتبر برای web worker ها و زمینه های مرور تودرتو که با استفاده از عناصری مانند <frame> و <iframe> بارگذاری می شوند را تعریف می کند
مثال سیاست CHILD-SRC
child-src 'self'

form-action

منابع معتبری که می توانند به عنوان action یک <form> در HTML استفاده شوند را تعریف می کند.
مثال سیاست FORM-ACTION
form-action 'self'

frame-ancestors

منابع معتبر برای جاسازی منبع با استفاده از <frame> <iframe> <object> <embed> <applet> را تعریف می کند. تنظیم این دستور بر 'none' تقریباً معادل X-Frame-Options: DENY است. وقتی این دستور فعال باشد، اگر مرورگر از آن پشتیبانی کند، تنظیمات موجود در X-frame-options را لغو خواهد کرد.
مثال سیاست FRAME-ANCESTORS
frame-ancestors 'none'

plugin-types

انواع MIME معتبر برای پلاگین هایی که از طریق <object> و <embed> فراخوانی می شوند را تعریف می کند. برای بارگذاری یک <applet> باید application/x-java-applet را مشخص کنید.
مثال سیاست PLUGIN-TYPES
plugin-types application/pdf

base-uri

مجموعه ای از آدرس های مجاز که می توانند در ویژگی src یک برچسب base در HTML استفاده شوند را تعریف می کند.
مثال سیاست BASE-URI
base-uri 'self'

report-to

نام یک گروه گزارش دهی تعریف شده توسط هدر پاسخ HTTP با نام Report-To را تعریف می کند. برای اطلاعات بیشتر به Reporting API مراجعه کنید.
مثال دستور REPORT-TO
report-to groupName

worker-src

آدرس هایی را که ممکن است به عنوان Worker، Shared Worker یا Service Worker بارگذاری شوند، محدود می کند.
مثال سیاست WORKER-SRC
worker-src 'none'

manifest-src

آدرس هایی که مانیفست های برنامه می توانند از آنها بارگذاری شوند را محدود می کند.
مثال سیاست MANIFEST-SRC
manifest-src 'none'

prefetch-src

منابع معتبر برای پیش بارگذاری و پیش رندر درخواست را تعریف می کند، برای مثال از طریق برچسب link با rel="prefetch" یا rel="prerender":
مثال سیاست PREFETCH-SRC
prefetch-src 'none'

navigate-to

آدرس هایی را که سند ممکن است به هر طریقی به آنها جابجا شود، محدود می کند. برای مثال، وقتی یک پیوند کلیک می شود، یک فرم ارسال می شود، یا window.location فراخوانی می شود. اگر form-action وجود داشته باشد، این دستور برای ارسال فرم ها نادیده گرفته می شود. وضعیت پیاده سازی
مثال سیاست NAVIGATE-TO
navigate-to https://example.com

پلاگین هدرهای HTTP جوملا همچنین این فرصت را به شما می دهد که برخی پارامترهای سراسری را در برگه Content Security Policy تنظیم کنید.

می توانید انتخاب کنید که CSP را با تنظیم client بر روی سایت خود، سایت مدیریت، یا هر دو اعمال کنید.

گزینه 'Report-Only' به شما اجازه می دهد دستورات خود را آزمایش کنید و قبل از اجرای نهایی آنها را با ابزارهای DEV از نظر خطا بررسی کنید. همیشه جالب است که دلیل خطاهای CSP را در کنسول گوگل ردیابی کنید!

بعدی تنظیم 'Nonce' است. Nonce، به معنای 'عددی که فقط یک بار استفاده می شود'، سیستمی است که یک رشته تصادفی تولید شده را به یک برچسب <script> یا <style> درون خطی که از طریق Joomla API در HTML شما گنجانده شده است، اعمال می کند. این موارد معمولاً توسط توسعه دهندگان شخص ثالث کامپوننت / ماژول / پلاگین جوملا زمانی که آن قابلیت اضافی را روی سایت خود نصب می کنید، پیاده سازی می شوند.

در تصویر زیر، می توانید برچسب <style> را با ویژگی nonce rel مشاهده کنید که به <styles> CSS اضافه شده به سند HTML من توسط کامپوننت Akeeba Backup اضافه شده است.

جالب است بدانید که کد اصلی جاوااسکریپت و CSS جوملا که به سند HTML اضافه می شود، در حال حاضر شامل یک برچسب «nonce» نمی شود. دلیل این است که آن ها بخشی از «هسته» هستند، نه اینکه از طریق Joomla API اضافه شده باشند.

اگر کلید «Nonce» را در تنظیمات CSP فعال کنید، آن اسکریپت ها و استایل های درون خطی را قادر می سازید تا توسط مرورگر به عنوان «امن» رندر شوند. همچنین باید برچسب {nonce} جوملا را در policy directive با نام script-src خود روی script-src 'self' {nonce} تنظیم کنید. به عنوان یک راه جایگزین برای مرورگرهای قدیمی که از 'nonce' پشتیبانی نمی کنند، می توانید {script-hashes} را نیز بعد از جایگزین {nonce} اضافه کنید، مانند این script-src 'self' {nonce} {script-hashes} (به فاصله گذاری توجه کنید). اما، فراموش نکنید که ابتدا Script Hashes را فعال کنید.

جوملا به صورت تصادفی رشته متنی «nonce» را تولید کرده و آن را به برچسب های <style> و <script> اضافه می کند. وقتی گزینه «nonce» را در تنظیمات پلاگین فعال می کنید، رشته متنی به HTTP Header ارسال می شود. سپس مرورگر HTTP Header را تفسیر کرده و <script> یا <style> منطبق را پردازش می کند. در همان زمان، رشته متنی Nonce را از HTML رندر شده در مرورگر حذف می کند.

این امر به نوبه خود، مانع از آن می شود که آقای هکر بتواند رشته متنی nonce را ربوده و آن را به کد تزریق شده خودش اضافه کند. حتی اگر آقای هکر در تزریق جاوااسکریپت شرورانه خود به HTML شما موفق شود، مرورگر آن را مسدود خواهد کرد.

Script Hashes

همه ما می دانیم که نباید جاوااسکریپت درون خطی را در HTML خود قرار دهیم، بلکه باید آن را در یک فایل my-javascript.js بنویسیم و به <head> اضافه کنیم یا درست قبل از برچسب </body> قرار دهیم. اما همه ما گاهی اوقات این کار را انجام می دهیم.

مشکل این است که اگر این کار را انجام دهید، سپس policy directive با نام ‘script-src 'self'’ را اضافه کنید، تمام جاوااسکریپت درون خطی به طور پیش فرض مسدود خواهد شد. این طراحی برای جلوگیری از اجرای جاوااسکریپت تزریق شده آقای هکرها روی سایت شما است.

برای این مورد یک لغو با policy directive با نام script-src 'unsafe-inline' وجود دارد، که به جاوااسکریپت درون خطی آقای هکرها اجازه اجرا می دهد، همراه با کد قابل اعتماد شما. این بهترین گزینه نیست، به دلایل واضح.

Script Hashes به کمک می آید!

پلاگین هدرهای HTTP جوملا به طور خودکار تمام <styles> و <scripts> ارسال شده از طریق Joomla API را به سایت جمع آوری می کند. سپس hash های مربوطه را تولید کرده و آن ها را از طریق HTTP Header ارسال می کند. سپس مرورگر hash ها را روی خود سایت تولید کرده و تطابق hash ها را تأیید می کند. اگر مطابقت داشته باشند، اسکریپت ها اجرا می شوند، در غیر این صورت مسدود می شوند.

برای فعال کردن این ویژگی پلاگین، کلید را به حالت 'Enabled' تغییر دهید. سپس، در policy directive با نام script-src خود مقدار 'self' {script-hashes} را اضافه کنید. اگر از ویژگی 'nonce' همراه با 'script hashes' استفاده می کنید، مقدار directive را مطابق مثال nonce بالا تنظیم کنید.

حالا، این هوشمندانه است.

اما، نکته بهتر این است که می توانیم از همین ایده برای پردازش دستی هش های اسکریپت و افزودن آن ها به دستور script-src 'self' استفاده کنیم. راه اندازی و نگهداری آن کمی زمان می برد اما اگر جاوااسکریپتی را به یک مطلب یا ماژول سفارشی اضافه کرده باشید، می تواند شما را نجات دهد.

روش های دقیق تری برای انجام این کار با استفاده از تولیدکننده هش sha256، sha384 یا sha512 وجود دارد. اما از آنجا که اکثر افراد فقط قطعات کوچکی از جاوااسکریپت را به مطلب یا ماژول سفارشی خود اضافه می کنند، اجازه می دهیم ابزارهای توسعه گوگل این کار را برای ما انجام دهند.

این فرآیند ساده است. تنها تفاوت در نحوه تولید هش است.

با فرض اینکه پلاگین هدرهای HTTP جوملا را فعال کرده اید، CSP فعال است و دستور script-src 'self' را تنظیم و ذخیره کرده اید.

مرحله 1 - جاوااسکریپت درون خطی خود را به مطلب یا ماژول سفارشی خود اضافه کرده و آن را ذخیره کنید. فراموش نکنید که تنظیمات ویرایشگر خود را تنظیم کنید تا از حذف کد شما توسط ویرایشگر هنگام ذخیره جلوگیری شود.

مرحله 2 - به صفحه وبی که اسکریپت شما در آن قرار دارد بروید. ابزارهای DEV را باز کنید و در برگه کنسول خطایی مشابه این خواهید دید:

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-0Q1c1CuhLHV7WbNt+ltwJoCf3wF/O+MWqsXetkxWSm0='), or a nonce ('nonce-...') is required to enable inline execution.

مرحله 3 - حالا، تنها کاری که باید انجام دهید این است که هش را از پیغام خطا کپی کرده و در دستور JavaScript در پلاگین جای گذاری کرده و دوباره آن را ذخیره کنید:

script-src 'self' 'sha256-0Q1c1CuhLHV7WbNt+ltwJoCf3wF/O+MWqsXetkxWSm0='

سپس، صفحه وب خود را دوباره بارگذاری کنید و دوباره در ابزارهای DEV گوگل بررسی کنید. اکنون خطا برطرف شده و مرورگر اسکریپت شما را در صفحه وب بارگذاری خواهد کرد.

توجه: در مثال من هنوز خطایی نمایش داده می شود زیرا جاوااسکریپت اضافه شده به مطلب من کامل نیست. اما این نشان می دهد که کد درون خطی حداقل در حال تلاش برای کار کردن است.

افزودن هش ها به کد درون خطی شما روش خوبی برای قرار دادن آن ها در لیست سفید هدر HTTP است تا همچنان اجرا شوند، در حالی که هر کد درون خطی که به صراحت هش نشده و به CSP شما اضافه نشده باشد، همچنان مسدود خواهد شد. بدین ترتیب تلاش آقای هکر برای نفوذ به سایت شما خنثی می شود.

توجه:

اگر جاوااسکریپت خود را تغییر دهید، باید هش خود را دوباره محاسبه کرده و مقدار را در دستور CSP تغییر دهید.

اگر در کار کردن هش های خود مشکل دارید، 3 مشکل رایج وجود دارد که می توانید راه حل های آن را در صفحه وب Using a hash with CSP بیابید.

Strict Dynamic

اگر گزینه Strict Dynamic را در CSP خود فعال کنید، این کار اختیار صریحی را که از طریق یک هش یا Nonce به یک اسکریپت داده اید، می گیرد و آن را به هر اسکریپت دیگری که مستقیماً به آن متصل است یا از آن فراخوانی می شود، اعمال می کند. این عمل همچنین دستورات پیش فرض مانند 'self' یا 'unsafe-inline' اعمال شده در دستورات کلی CSP شما را برای آن اسکریپت های فرزند لغو می کند. آن ها نادیده گرفته خواهند شد.

Style Hashes

Style Hash در CSP دقیقاً مانند هش های جاوااسکریپت که در بالا توضیح داده شد عمل می کند، اما از این مورد زمانی استفاده کنید که بلوک های <style> سی اس اس را به بدنه HTML خود اضافه می کنید. درست مانند استفاده از 'Script Hashes'، ویژگی پلاگین را فعال کنید و یک Policy Directive از نوع style-src را برای ارجاع به آن با مقدار 'self' {style-hashes} تنظیم کنید.

توجه:

اگر CSS درون خطی خود را تغییر دهید، نه CSS که توسط API جوملا ایجاد شده است، باید هش خود را دوباره محاسبه کرده و مقدار آن را در دستور CSP تغییر دهید.

Frame Ancestors 'self'

این گزینه در پلاگین اجازه می دهد یک صفحه، برای مثال درون یک iframe، فریم شود، اما فقط از همان سایت.

اگر می خواهید به طور صریح به یک سایت دیگر اجازه فریم کردن محتوای خود را بدهید، می توانید یک دستور مشخص 'frame-src' تنظیم کنید.

یادداشت پایانی / نتیجه گیری:

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

من عاشق کشف موضوعاتی هستم که قبلاً نادیده گرفته ام یا از آن ها بی اطلاع بوده ام. آیا شما هم همین طور هستید؟

نتیجه ای که در تحقیق درباره موضوع هدرهای HTTP و به ویژه استفاده از پلاگین جدید J4 جوملا برای تنظیم آن ها به آن رسیده ام این است که همه ما باید بر این موضوع مسلط شویم. افراد (هکرها) بسیار زیادی بیرون منتظر فرصتی هستند تا از سایت های دارای امنیت ضعیف سوءاستفاده کنند. بنابراین، به کاربران خود کمک نکنید که قربانی شوند.

از بررسی پلاگین هدرهای HTTP جوملا لذت ببرید و یاد بگیرید که چگونه می تواند به ایمن سازی سایت شما کمک کند.

با این حال، توصیه می کنم قبل از شروع، تحقیق بیشتری درباره این موضوع جالب انجام دهید. در زیر پیوندهایی برای شروع تحقیق خودتان آورده شده است. درک بسیار بهتری از نحوه کارکرد اینترنت و نحوه تعامل سایت شما با آن پیدا خواهید کرد.

برای مرجع

اگر نیاز به بازنشانی پلاگین دارید، پلاگین هدرهای HTTP با تنظیمات زیر نصب شده بود:

این پلاگین به طور پیش فرض فعال است.

• برگه های HSTS و CSP به طور پیش فرض غیرفعال هستند.
• X-Frame-Options به طور پیش فرض فعال است.
• Referrer-Policy در ابتدا روی strict-origin-when-cross-origin تنظیم شده است.
• Cross-Origin-Opener-Policy در ابتدا روی same-origin تنظیم شده است.

اگر تا اینجا خوانده اید و فکر کرده اید «این منصفانه نیست، پس J3 چه می شود؟»، «چرا نمی توانیم همان امکانات را در جوملا 3 داشته باشیم؟». خب، خبر خوب این است که می توانید. هرچند باید پلاگین را از JED دریافت کنید.

وقتی هدرهای HTTP خود را با پلاگین جوملا 4 تنظیم کردید، می توانید هدرهای HTTP خود را در سایت Security Headers آزمایش کنید.

چه امتیازی کسب کردید؟

توجه داشته باشید که فعال سازی پلاگین هدرهای HTTP ممکن است اقدامات غیرمنتظره ای در front end داشته باشد.

در پایان، می خواهم از Tobias Zulauf و Ced Keiflin به خاطر کمکشان در به اتمام رساندن این مقاله به موقع تشکر کنم!