مسمومیت حافظه پنهان وب
در این مطلب قصد داریم، یکی از حملات سایبری بر بستر وب، به نام Cache Poisoning، را شرح دهیم. اول، کمی با Cache و انواع آن آشنا خواهیم شد. دوم، به سراغ مفهوم پایه ای این آسیب پذیری و چگونگی شناسایی آن می رویم. سوم، عواقب آن را مرور می کنیم. چهارم، مکانیزم های دفاع در برابر این آسیب پذیری (Mitigations) و پنجم راه های دور زدن این مکانیزم ها را بررسی می کنیم.
در مورد Cache و انواع آن
به طور کلی حافظه نهان (Cache) در سطوح مختلف دنیای کامپیوتر مورد استفاده قرار می گیرد. حافظه نهان، یک سخت افزار یا محصول مشخص نیست؛ بلکه یک روش معماری و طراحی است. هدف از آن افزایش سرعت و کاهش تاخیر زمانی است. در سطح وب از حافظه نهان در قسمت های مختلفی استفاده می شود، که می توان آن را به دو بخش سمت-کاربر و سمت-سرور تقسیم کرد. در این مطلب، تمرکز ما روی حافظه های نهان سمت سرور است. این سرور ها خود به دو دسته قابل تقسیم بندی هستند. دسته اول، سرور های میانی ای که به صورت یک Proxy عمل می کنند و در عین حال عملیات Caching را نیز انجام می دهند. دسته دیگر، مکانیزم Caching تعبیه شده در سرور وب اصلی است. خیلی از Framework های وب به طور پیشفرض، حافظه نهان نیز دارند (مثلا Drupal).
1. حافظه نهان در سرور Proxy (بیرونی)
2. حافظه نهان در سرور وب اصلی (داخلی)
از این پس، هر جا از سرور Cache صحبت می کنیم، منظورمان سرور Web Cache است.
کلید شده (Keyed)
ما در انجام حمله Cache Poisoning، باید بدانیم که سرور Cache کدام بخش های درخواست را به عنوان کلید در نظر می گیرد. نام این بخش ها را کلید شده یا Keyed می گذاریم. در صورت تغییر مقدار موارد کلید شده، پاسخ دریافتی از سرور Cache متفاوت خواهد بود و یک رکورد Cache جدید در سرور Cache اضافه خواهد شد.
کلید نشده (Unkeyed)
در مقابل کلید شده، کلید نشده یا Unkeyed قرار دارد. موارد کلید نشده در درخواست وب، مواردی هستند که با تغییر آن ها، سرور Cache، پاسخ متفاوتی نمی دهد. یعنی از حافظه خود، موردی را بر می گرداند که قبلا توسط ما یا کاربر دیگری مشاهده شده است.
جلوگیری از ایجاد Gadget
به عنوان توسعه دهنده وبسایت، اولین نکته ای که باید به آن توجه کرد، این است که تمام مقادیری که از سمت کاربر به سمت سرور وارد می شوند، باید صحت سنجی و پاکسازی شوند. حال این مقدار ممکن است، مقدار هدر باشد یا پارامتر های URI. این قاعده ای کلی است که از به وجود آمدن بسیاری از آسیب پذیری ها جلوگیری می کند. هر یک از این آسیب پذیری ها ممکن است در حمله Web Cache Poisoning به عنوان یک Gadget مورد استفاده قرار گیرند. راه دیگر جلوگیری از به وجود آمدن Gadget ها استفاده CSP (Content Security Policy) در مرورگر های مدرن است. و نهایتا در یک کلام باید گفت، هر چیزی که به عنوان جلوگیری از حملات XSS، HTML Injection و … شناخته می شود، اینجا نیز قابل استفاده است؛ زیرا Gadget چیزی جز این آسیب پذیری های سمت کاربر نیست که مستقل از Cache وجود دارند و عمل می کنند.
جلوگیری از Cache شدن نادرست
در حالت کلی نباید یک مقدار هم کلید نشده باشد و هم استفاده شده. این نکته، کلید ایجاد آسیب پذیری Web Cache Poisoning است. اصلاح این مشکل هم در سرور وب اصلی ممکن است و هم در سرور Cache. اگر به تنظیمات سرور Cache دسترسی داشته باشیم، می توانیم موارد استفاده شده در برنامه سمت سرور را، کلید شده در نظر بگیریم. اما اگر به تنظیمات سرور Cache دسترسی نداشته باشیم، باید از مقدار مورد نظر استفاده نکنیم و جایگزینی در موارد کلید شده برای آن پیدا کنیم.