حمله فریب کش وب (Web Cache Deception - WCD) زمانی رخ می‌دهد که یک مهاجم بتواند سرور کش (مانند CDN، پروکسی معکوس یا سایر سیستم‌های ذخیره‌ساز) را فریب دهد تا پاسخ‌های حاوی اطلاعات حساس کاربران را ذخیره کند. سپس، این پاسخ‌های کش‌شده ممکن است به کاربران دیگر ارائه شوند و باعث نشت داده‌های محرمانه مانند کوکی‌های احراز هویت، توکن‌های CSRF یا سایر اطلاعات شخصی شوند. شرایط لازم برای این حمله: 1- سرور از کش استفاده می‌کند (مثلاً CDN، کش پروکسی معکوس reverse proxy 2- کش به درستی پیکربندی نشده است و پاسخ‌های حاوی اطلاعات کاربران را ذخیره می‌کند. 3- وب‌سایت محتوای حساس را بر اساس نشست کاربر (Session) ارائه می‌دهد (مثلاً صفحهٔ حساب کاربری). راه‌های پیشگیری ۱. تنظیم صحیح هدرهای کش استفاده از هدرهای HTTP مانند: Cache-Control: no-store → برای صفحات حساس Vary: Cookie → اطمینان از اینکه پاسخ‌ها بر اساس کوکی‌های کاربر متفاوت هستند Cache-Control: private → اجازه ندهد پاسخ‌ها در کش اشتراکی ذخیره شوند ۲. عدم کش‌کردن پاسخ‌های حاوی داده‌های حساس مثلاً صفحاتی مانند: /account /dashboard /profile نباید توسط کش سرور ذخیره شوند. ۳. اعتبارسنجی درخواست‌های کش مطمئن شوید که سیستم کش فقط فایل‌های واقعاً استاتیک (مانند *.css، *.js، *.png) را ذخیره می‌کند. کش وب (Web Cache) سیستمی است که بین سرور اصلی (Origin Server) و کاربر قرار می‌گیرد. هنگامی که یک کلاینت (مثلاً مرورگر) درخواستی برای یک منبع استاتیک (مانند فایل CSS، JS یا تصاویر) ارسال می‌کند، این درخواست ابتدا به کش هدایت می‌شود. اگر کش نسخه‌ای از آن منبع را نداشته باشد (حالت Cache Miss)، درخواست به سرور اصلی فرستاده می‌شود. سرور اصلی درخواست را پردازش کرده و پاسخ را به کش ارسال می‌کند. سپس کش، این پاسخ را ذخیره کرده و به کاربر تحویل می‌دهد. کش بر اساس مجموعه‌ای از قوانین ازپیش‌تنظیم‌شده تصمیم می‌گیرد که آیا پاسخ را ذخیره کند یا خیر. وقتی در آینده درخواست مشابهی برای همان منبع استاتیک ارسال شود، کش نسخه ذخیره‌شده پاسخ را مستقیماً به کاربر ارائه می‌دهد (حالت Cache Hit). ساخت یک حمله فریب کش وب (Web Cache Deception) به طور کلی، ساخت یک حمله فریب کش وب پایه شامل مراحل زیر است: 1- شناسایی یک اندپوینت هدف که پاسخ دینامیکی حاوی اطلاعات حساس برمی‌گردد. 2- پاسخ‌ها را در Burp بررسی کنید، زیرا برخی اطلاعات حساس ممکن است در صفحه رندر شده قابل مشاهده نباشند. 3- روی اندپوینت‌هایی تمرکز کنید که از متدهای GET، HEAD یا OPTIONS پشتیبانی می‌کنند، زیرا درخواست‌هایی که وضعیت سرور اصلی را تغییر می‌دهند معمولاً کش نمی‌شوند. 4- شناسایی اختلاف در نحوه پردازش مسیر URL توسط کش و سرور اصلی. این اختلاف می‌تواند در موارد زیر باشد: نحوه نگاشت URLها به منابع. پردازش کاراکترهای جداکننده. نرمال‌سازی مسیرها. 5- ساخت یک URL مخرب که از این اختلاف برای فریب کش استفاده می‌کند تا پاسخ دینامیکی را ذخیره کند. 6- وقتی قربانی به این URL دسترسی پیدا می‌کند، پاسخ او در کش ذخیره می‌شود. 7- با استفاده از Burp می‌توانید درخواستی به همان URL ارسال کنید تا پاسخ کش‌شده حاوی داده‌های قربانی را دریافت کنید. از انجام این کار مستقیماً در مرورگر خودداری کنید، زیرا برخی برنامه‌ها کاربران بدون نشست را ریدایرکت می‌کنند یا داده‌های محلی را باطل می‌کنند که ممکن است آسیب‌پذیری را پنهان کند شناسایی پاسخ‌های کش شده در طول تست، شناسایی پاسخ‌های کش شده از اهمیت بالایی برخوردار است. برای این کار باید به هدرهای پاسخ و زمان پاسخدهی توجه کنید. نشانگرهای هدر پاسخ: چندین هدر پاسخ ممکن است نشان دهنده کش بودن پاسخ باشند. برای مثال: هدر X-Cache اطلاعاتی درباره منشأ پاسخ ارائه می‌دهد: X-Cache: hit - پاسخ از کش ارائه شده است. X-Cache: miss - کش حاوی پاسخ مورد نظر نبوده و پاسخ از سرور اصلی دریافت شده است. معمولاً در این حالت پاسخ جدید در کش ذخیره می‌شود. برای تأیید این موضوع، درخواست را دوباره ارسال کنید تا ببینید آیا مقدار به hit تغییر می‌کند یا خیر. X-Cache: dynamic - محتوا به صورت دینامیک توسط سرور اصلی تولید شده است. معمولاً این به معنای عدم مناسب بودن پاسخ برای کش شدن است. X-Cache: refresh - محتوای کش تاریخ گذشته بوده و نیاز به بروزرسانی یا اعتبارسنجی مجدد داشته است. هدر Cache-Control ممکن است شامل دستورالعمل‌هایی باشد که نشان دهنده قابلیت کش شدن هستند، مانند public همراه با max-age بزرگتر از صفر. توجه داشته باشید که این فقط نشان می‌دهد منبع قابلیت کش شدن دارد و همیشه به معنای کش شدن آن نیست، زیرا گاهی اوقات کش ممکن است این هدر را نادیده بگیرد. زمان پاسخ دهی: اگر تفاوت قابل توجهی در زمان پاسخدهی برای یک درخواست یکسان مشاهده کردید، این ممکن است نشان دهنده این باشد که پاسخ سریع‌تر از کش ارائه شده است روش‌های شناسایی آسیب‌پذیری Web Cache Deception 1. تست دستی با بررسی هدرهای پاسخ بررسی هدر Cache-Control و X-Cache: اگر پاسخ شامل Cache-Control: public یا max-age بالا باشد، احتمال کش شدن وجود دارد. هدر X-Cache: hit نشان می‌دهد پاسخ از کش ارائه شده است. تست تغییر مسیر (Path Manipulation): اضافه کردن پسوندهای رایج کش‌شونده (مثل .css، .js، .png) به انتهای URLهای دینامیک. مثال: اصلی: https://example.com/account تست: https://example.com/account/style.css اگر پاسخ کش شد (X-Cache: hit)، آسیب‌پذیری وجود دارد. 2. استفاده از ابزارهای اتوماسیون Burp Suite: ارسال درخواست‌های متعدد با پسوندهای مختلف و بررسی تفاوت در هدرها. استفاده از Extensionهای مثل Collaborator Everywhere برای ردیابی کش شدن پاسخ‌ها. OWASP ZAP: اسکن خودکار برای شناسایی مسیرهای حساس که ممکن است کش شوند. Invicti/Acunetix: ابزارهای اسکن تجاری که این آسیب‌پذیری را به صورت خودکار تشخیص می‌دهند. 3. تکنیک‌های پیشرفته مقایسه زمان پاسخ‌دهی (Timing Analysis): درخواست تکراری به یک URL و اندازه‌گیری زمان پاسخ. پاسخ‌های کش شده معمولاً سریع‌تر هستند. تست با کوکی‌های مختلف: ارسال درخواست با و بدون کوکی برای بررسی رفتار کش. اگر پاسخ یکسان باشد، احتمال کش شدن وجود دارد. 4. بررسی رفتار سرور تست با متدهای مختلف (GET, POST, HEAD): کش معمولاً فقط برای GET و HEAD فعال است. تست پارامترهای Query String: اضافه کردن پارامترهای تصادفی به URL و بررسی کش شدن پاسخ. ابزارهای مفید برای تست ابزار کاربرد Burp Suite تست دستی، بررسی هدرها، ارسال درخواست‌های اصلاح‌شده OWASP ZAP اسکن خودکار، شناسایی مسیرهای حساس Nmap بررسی پیکربندی سرور و کش curl/wget ارسال درخواست‌های سفارشی و تحلیل پاسخ‌ها Browser DevTools مشاهده هدرهای پاسخ و زمان بارگذاری جمع‌بندی 1- حمله فریب کش وب یک تکنیک خطرناک است که می‌تواند منجر به نشت اطلاعات کاربران شود. 2- راه حل اصلی، پیکربندی صحیح کش و استفاده از هدرهای امنیتی HTTP است. 3- توسعه‌دهندگان و مدیران سرورها باید مطمئن شوند که صفحات حساس هرگز کش نمی‌شوند.