مقدمهای بر مکانیزم کش در CDN
پیش از ورود به بحث امنیتی، لازم است درک درستی از مکانیزم کش در CDNها داشته باشیم.
CDN (Content Delivery Network) برای کاهش بار روی سرور اصلی (origin server) و افزایش سرعت پاسخگویی، نسخهای از برخی صفحات سایت را در نزدیکی کاربر ذخیره (کش) میکند. اما این سؤال مطرح میشود: CDN بر چه اساسی تصمیم میگیرد یک صفحه را کش کند یا نه؟
معیارهای زیادی در این تصمیمگیری دخیل هستند که یکی از مهمترین آنها پسوند (extension) آدرس درخواستشده است. هر CDN قوانین خاص خود را برای این موضوع دارد و برای جزئیات دقیق، بهترین منبع همیشه داکیومنت رسمی همان CDN است.
مفهوم Cache Key
برای اینکه CDN بتواند تشخیص دهد یک درخواست باید از کش پاسخ داده شود یا باید به سرور اصلی ارسال شود، از مفهومی به نام cache key استفاده میکند. این کلید معمولاً از ترکیب چند بخش از درخواست ساخته میشود:
method | scheme | domain | path | query stringهرگاه ترکیب این مقادیر برای یک درخواست جدید با ورودیهایی که قبلاً کش شدهاند یکسان باشد، CDN نسخهی کششده را برمیگرداند. در غیر این صورت، درخواست به سرور اصلی ارسال شده و نتیجهی جدید کش میشود. توجه داشته باشید که عناصر تشکیلدهندهی cache key در هر CDN میتواند متفاوت باشد و محدود به موارد بالا نیست.
تفاوت HIT و MISS
هنگامی که یک درخواست برای اولین بار به CDN میرسد و نسخهای از آن در کش وجود ندارد، CDN درخواست را به سرور اصلی فوروارد میکند، پاسخ را دریافت و کش میکند، و در هدر پاسخ مقدار MISS را برمیگرداند.
در درخواستهای بعدی، اگر CDN بتواند پاسخ را از کش بازیابی کند، در هدر پاسخ مقدار HIT را برمیگرداند.
Keyed Input و Unkeyed Input
به بخشهایی از درخواست که در ساخت cache key نقش دارند و تغییر آنها باعث ایجاد یک ورودی کش جدید میشود، keyed input گفته میشود. در مقابل، بخشهایی که در ساخت cache key دخیل نیستند و تغییرشان روی نتیجهی کش تأثیری ندارد، unkeyed input نامیده میشوند.
بهعبارت دیگر، اگر مقدار یک keyed input تغییر کند، CDN آن را بهعنوان یک درخواست جدید در نظر میگیرد و بهجای HIT، پاسخ MISS برمیگرداند؛ زیرا باید برای این ورودی جدید، فرایند کش از ابتدا انجام شود.
Cache Deception چیست؟
Cache Deception نوعی آسیبپذیری است که در آن مهاجم میتواند CDN را فریب دهد تا صفحهای را کش کند که در حالت عادی نباید کش شود؛ معمولاً صفحهای حاوی اطلاعات حساس و اختصاصی کاربر (مانند داشبورد شخصی، اطلاعات پروفایل، یا توکنهای نشست).
اگر چنین اتفاقی بیفتد، یک نسخه از این صفحهی شخصی در کش عمومی CDN ذخیره میشود و سایر کاربرانی که همان آدرس را درخواست کنند، ممکن است نسخهی کششدهی حاوی اطلاعات قربانی را دریافت کنند.
چرا این اتفاق میافتد؟
ریشهی این آسیبپذیری معمولاً به نحوهی تعریف روتها (routes) در سمت برنامهنویسی برمیگردد. اگر روتها بهگونهای پیادهسازی شده باشند که بخشهای اضافی در انتهای مسیر را نادیده بگیرند، زمینه برای این حمله فراهم میشود.
برای مثال، فرض کنید برنامهنویس روتی به شکل /dash/user تعریف کرده است. اگر این روت بهگونهای پیادهسازی شده باشد که حتی با اضافهشدن بخشهای اضافی به انتهای مسیر، همچنان همان روت در نظر گرفته شود (برای مثال بهدلیل عدم تطبیق دقیق مسیر یا استفاده از الگوهای منعطف در سمت سرور)، زمینه برای سوءاستفاده فراهم میشود.
در این حالت، اگر مهاجم آدرس را بهصورت زیر تغییر دهد:
/dash/user/.cssو CDN در منطق تشخیص فایل استاتیک خود ضعف داشته باشد، ممکن است این آدرس را بهاشتباه یک فایل استاتیک قابل کش (مانند فایل CSS) تشخیص دهد.
از سوی دیگر، وقتی این درخواست به سرور اصلی میرسد، سرور همچنان آن را بهعنوان درخواست به روت /dash/user پردازش میکند و پاسخی حاوی اطلاعات حساب کاربری قربانی برمیگرداند. اما چون CDN این مسیر را بهعنوان فایل استاتیک شناسایی کرده بود، همین پاسخ شخصی را در کش عمومی ذخیره میکند.
از این پس، مهاجم تنها کافی است لینک /dash/user/.css را برای قربانی ارسال کند. وقتی قربانی (در حالی که نشست فعال خود را دارد) روی این لینک کلیک کند، اطلاعات حساب او در کش CDN ذخیره میشود و مهاجم میتواند با درخواست همان آدرس، به این اطلاعات دسترسی پیدا کند.
شرایط لازم برای وقوع Cache Deception
برای اینکه یک سیستم در برابر این حمله آسیبپذیر باشد، معمولاً باید سه شرط زیر بهطور همزمان برقرار باشند:
- سایت پشت یک CDN قرار داشته باشد.
- روتی وجود داشته باشد که با اضافهشدن پسوند یا مسیر اضافی، همچنان به همان منبع اصلی پاسخ دهد، اما توسط CDN بهعنوان محتوای استاتیک و قابل کش تشخیص داده شود.
- پاسخ آن صفحه شامل اطلاعات حساس و وابسته به کاربر (user-specific) باشد.
نتیجهگیری
Cache Deception نمونهای از حملاتی است که از تفاوت دیدگاه میان لایهی CDN و لایهی اپلیکیشن سرچشمه میگیرد. CDN صرفاً بر اساس ظاهر آدرس (مثلاً پسوند فایل) تصمیم میگیرد، در حالی که اپلیکیشن منطق مسیرها را بر اساس routing داخلی خود پردازش میکند. عدم هماهنگی بین این دو لایه میتواند منجر به افشای اطلاعات حساس کاربران شود.
برای پیشگیری از این آسیبپذیری، توصیه میشود:
- روتها بهصورت دقیق (exact match) تعریف شوند و مسیرهای اضافی منجر به پردازش روت اصلی نشوند.
- صفحات حاوی اطلاعات شخصی با هدرهای مناسب (مانند
Cache-Control: private, no-store) از کش عمومی مستثنی شوند. - پیکربندی CDN بهگونهای باشد که تصمیم کشکردن بر اساس Content-Type واقعی پاسخ باشد، نه صرفاً پسوند ظاهری آدرس.
🔗 مقاله مرتبط: Cache Poisoning
این مقاله هنوز منتشر نشده، اما به زودی در دسترس خواهد بود.