فراموش کردن یا استفاده نادرست از هدر Cache-Control ممکن است بر امنیت وب سایت شما و حریم خصوصی کاربران شما تأثیر منفی بگذارد.
بهطور پیشفرض، منابع همیشه مجاز هستند که توسط هر نوع کش ذخیره شوند. عدم استفاده یا سوء استفاده از هدر Cache-Control
ممکن است بر امنیت وب سایت شما و حریم خصوصی کاربران شما تأثیر منفی بگذارد.
برای پاسخهای شخصیشدهای که میخواهید خصوصی نگه دارید، به شما توصیه میکنیم:
- از ذخیره سازی منابع توسط واسطه ها جلوگیری کنید. تنظیم
Cache-Control: private
. - یک کلید حافظه پنهان ثانویه مناسب تنظیم کنید. اگر پاسخ به دلیل کوکیها متفاوت باشد - که ممکن است زمانی اتفاق بیفتد که کوکی اعتبارنامهها را ذخیره میکند -
Vary: Cookie
تنظیم کنید.
در ادامه بخوانید تا بدانید چرا این مهم است و کشف کنید:
- مشکلات امنیتی و حریم خصوصی که ممکن است از آنها بی اطلاع باشید
- انواع مختلف کش HTTP و باورهای غلط رایج
- اقدامات توصیه شده برای وب سایت های با ارزش بالا
خطرات امنیتی و حریم خصوصی مرتبط با حافظه پنهان
منابع نشت از آسیب پذیری های Spectre
آسیب پذیری Spectre به صفحه اجازه می دهد تا حافظه یک فرآیند سیستم عامل را بخواند. این بدان معنی است که یک مهاجم می تواند به داده های منبع متقابل دسترسی غیرمجاز داشته باشد. در نتیجه، مرورگرهای وب مدرن استفاده از برخی از ویژگیهای خود را - مانند SharedArrayBuffer
یا تایمر با وضوح بالا - به صفحاتی با انزوا با مبدا متقابل محدود کردهاند.
مرورگرهای وب مدرن خط مشی جاسازی بین مبدا (COEP) را اعمال می کنند. این تضمین می کند که منابع متقاطع یکی از موارد زیر هستند:
- منابع عمومی، بدون کوکی درخواست شده است
- منابع به صراحت مجاز به اشتراک گذاری با منشاء متقابل، از طریق CORS یا سربرگ CORP هستند
راه اندازی COEP مانع از سوء استفاده مهاجم از Spectre نمی شود. با این حال، تضمین میکند که منابع متقاطع برای مهاجم ارزشمند نیستند (هنگامی که مرورگر بهعنوان منبع عمومی بارگیری میکند) یا اجازه اشتراکگذاری با مهاجم را ندارند (وقتی با CORP: cross-origin
).
کش HTTP چگونه بر Spectre تأثیر می گذارد؟
اگر هدر Cache-Control
به درستی تنظیم نشده باشد، مهاجم می تواند یک حمله را اجرا کند. مثلا:
- منبع اعتبارنامه کش ذخیره می شود.
- مهاجم یک صفحه جدا شده از مبدا متقاطع را بارگیری می کند.
- مهاجم دوباره منبع را درخواست می کند.
-
COEP:credentialless
توسط مرورگر تنظیم شده است ، بنابراین منبع بدون کوکی واکشی می شود. با این حال، یک کش ممکن است به جای آن پاسخ اعتباری را برگرداند. - سپس مهاجم می تواند منبع شخصی شده را با استفاده از حمله Spectre بخواند.
اگرچه حافظه پنهان HTTP مرورگر وب اجازه نمی دهد این نوع حمله در عمل انجام شود، حافظه های پنهان اضافی خارج از کنترل فوری مرورگر وجود دارند. این ممکن است منجر به موفقیت این حمله شود.
تصورات غلط رایج در مورد حافظه پنهان HTTP
1. منابع فقط توسط مرورگر کش می شوند
اغلب چندین لایه کش وجود دارد. برخی از کش ها به یک کاربر اختصاص داده شده اند، برخی به چند کاربر. برخی توسط سرور، برخی توسط کاربر و برخی توسط واسطه ها کنترل می شوند.
- حافظه پنهان مرورگر این کش ها متعلق به یک کاربر و اختصاص داده شده به آن در مرورگر وب آن ها است. آنها با اجتناب از واکشی چندین بار یک پاسخ، عملکرد را بهبود می بخشند.
- پروکسی محلی این ممکن است توسط کاربر نصب شده باشد، اما می تواند توسط واسطه ها نیز مدیریت شود: شرکت، سازمان یا ارائه دهنده اینترنت آنها. پراکسی های محلی اغلب یک پاسخ واحد را برای چندین کاربر ذخیره می کنند که یک کش عمومی را تشکیل می دهد. پراکسی های محلی چندین نقش دارند.
- حافظه پنهان سرور مبدا / CDN . این توسط سرور کنترل می شود. هدف حافظه پنهان سرور Origin کاهش بار روی سرور مبدا با ذخیره کردن پاسخ یکسان برای چندین کاربر است. اهداف CDN مشابه هستند، اما در سراسر جهان گسترش یافته و برای کاهش تاخیر به نزدیکترین مجموعه از کاربران اختصاص داده شده است.
2. SSL از ذخیره منابع HTTPS توسط واسطه ها جلوگیری می کند
بسیاری از کاربران به طور منظم از پراکسی های پیکربندی شده محلی استفاده می کنند، چه برای اهداف دسترسی (مانند اشتراک گذاری یک اتصال اندازه گیری شده)، بازرسی ویروس، یا برای اهداف پیشگیری از از دست دادن داده ها (DLP). حافظه پنهان واسطه در حال انجام رهگیری TLS است.
یک کش واسطه اغلب در ایستگاه های کاری یک شرکت نصب می شود. مرورگرهای وب به گونه ای پیکربندی شده اند که به گواهی های پروکسی محلی اعتماد کنند.
در نهایت، برخی از منابع HTTPS ممکن است توسط این پراکسی های محلی ذخیره شوند.
نحوه کار کش HTTP
- منابع به طور ضمنی به طور پیش فرض مجاز به ذخیره سازی در حافظه پنهان هستند.
- کلید حافظه پنهان اولیه شامل URL و متد است. (URL، روش)
- کلید حافظه پنهان ثانویه هدرهایی است که در هدر
Vary
قرار دارند.Vary: Cookie
نشان می دهد که پاسخ بهCookie
بستگی دارد. - هدر
Cache-Control
کنترل دقیق تری می دهد.
این اقدامات توصیه شده را برای وب سایت خود انجام دهید
توسعهدهندگان وبسایتهای با ارزش، که شامل وبسایتهایی با ترافیک بالا و وبسایتهایی هستند که با اطلاعات شناسایی شخصی در تعامل هستند، باید از هم اکنون برای بهبود امنیت اقدام کنند.
بیشترین خطر زمانی رخ می دهد که دسترسی به یک منبع بسته به کوکی ها متفاوت باشد. یک حافظه پنهان واسطه ممکن است پاسخی را که با کوکیها درخواست شده است، برای درخواستی که اینطور نبود، در صورتی که اقدام پیشگیرانه انجام نشده باشد، برگرداند.
توصیه می کنیم یکی از مراحل زیر را انجام دهید:
- از ذخیره سازی منابع توسط واسطه ها جلوگیری کنید. تنظیم
Cache-Control: private
. - یک کلید حافظه پنهان ثانویه مناسب تنظیم کنید. اگر پاسخ به دلیل کوکیها متفاوت باشد - که ممکن است زمانی اتفاق بیفتد که کوکی اعتبارنامهها را ذخیره میکند -
Vary: Cookie
تنظیم کنید.
به ویژه، رفتار پیش فرض را تغییر دهید: همیشه Cache-Control
یا Vary
را تعریف کنید.
ملاحظات اضافی
انواع دیگری از حملات مشابه با استفاده از حافظه پنهان HTTP وجود دارد، اما این حملات به مکانیسم متفاوتی نسبت به جداسازی مبدا متقابل متکی هستند. به عنوان مثال، جیک آرچیبالد برخی از حملات را در نحوه برنده شدن در CORS توضیح می دهد.
این حملات توسط برخی از مرورگرهای وب کاهش مییابد که حافظه پنهان HTTP خود را بسته به اینکه پاسخ منبع با اعتبار درخواست شده است یا خیر، تقسیم میکنند. از سال 2022، فایرفاکس کش را تقسیم می کند، در حالی که کروم و سافاری این کار را انجام نمی دهند. کروم ممکن است کش را در آینده تقسیم کند . توجه داشته باشید که این حملات متفاوت و مکمل تقسیم آن در مبدا سطح بالا هستند.
حتی اگر بتوان این مشکل را برای مرورگرهای وب کاهش داد، مشکل در حافظه پنهان پروکسی محلی باقی خواهد ماند. بنابراین، ما همچنان توصیه می کنیم توصیه های بالا را دنبال کنید.
عکس هدر توسط بن پتینسون در Unsplash .