هنوز هیچ محصولی خریداری نکرده اید.
باگهای پنهان دنیای باگ بانتی بخش دوم
در مقاله باگهای پنهان دنیای باگ بانتی بخش دوم در مورد آسیبپذیری Web Cache Deception صحبت میکنیم که از دید افراد مخفی مانده.
بسیاری از باگ هانترها از کنار رفتارهای مربتط با Cache عبور میکنند و با خودشان میگویند:
«این موضوع مربوط به CDN است… به من ربطی ندارد.»
اما همین تصور اشتباه، برای مهاجمان هزاران دلار ضرر داشته است.
در این مطلب به سراغ Web Cache Deception میرویم؛ آسیبپذیریای که نه کد شما را هدف قرار میدهد و نه منطق برنامه را، بلکه از تفاوت در نحوه تفسیر درخواستها توسط لایههای کش سوءاستفاده میکند.
و زمانی که این آسیبپذیری رخ دهد، میتواند دادههای کاربران احراز هویتشده را در اختیار عموم قرار دهد.
Web Cache Deception چیست؟ (به زبان ساده)
آسیبپذیری Web Cache Deception زمانی رخ میدهد که:
- کاربر وارد حساب کاربری خود شده باشد.
- یک صفحه پویا و نیازمند احراز هویت را درخواست کند.
- درخواست ظاهری شبیه فایلهای استاتیک داشته باشد.
- CDN یا Reverse Proxy آن پاسخ را در کش ذخیره کند.
- افراد دیگر بتوانند بدون نیاز به احراز هویت به همان پاسخ کششده دسترسی پیدا کنند.
برنامه تصور میکند:
«کاربر احراز هویت شده است؛ پس اطلاعات خصوصی را نمایش بده.»
اما سیستم کش تصور میکند:
«این یک فایل استاتیک است؛ آن را ذخیره کن و در درخواستهای بعدی مجدداً ارائه بده.»
همین اختلاف در تفسیر، منشأ آسیبپذیری است.
🎯 چرا این آسیبپذیری خطرناک است و پاداش بالایی دارد؟
این آسیبپذیری معمولاً منجر به افشای موارد زیر میشود:
- اطلاعات پروفایل کاربران
- آدرس ایمیل و شماره تلفن
- تنظیمات حساب کاربری
- پاسخهای API
- شناسههای داخلی سیستم
- در برخی موارد توکنها و اطلاعات حساس دیگر
و نگرانکنندهترین بخش ماجرا:
- پس از کش شدن دادهها، دیگر نیازی به تعامل با قربانی وجود ندارد.
- یک درخواست میتواند اطلاعات هزاران کاربر را در معرض افشا قرار دهد.
به همین دلیل این آسیبپذیری اغلب در سطح P1 (بحرانی) طبقهبندی میشود.
📹 روند سوءاستفاده در دنیای واقعی (PoC Mindset)
بدون نیاز به:
- Brute Force
- XSS
- IDOR
فقط کافی است سوءبرداشت بین برنامه و سیستم کش وجود داشته باشد.
🧪 چگونه Web Cache Deception را پیدا کنیم؟ (گام به گام)
مرحله اول: شناسایی Endpointهای احراز هویتشده
پس از ورود به حساب کاربری، صفحات زیر را بررسی کنید:
/account
/profile
/settings
/dashboard
/api/user
/me
اگر صفحه اطلاعات اختصاصی کاربر را نمایش میدهد، گزینه مناسبی برای تست است.
مرحله دوم: اضافه کردن پسوندهای جعلی فایلهای استاتیک
پسوندهایی را امتحان کنید که معمولاً توسط CDNها کش میشوند:
.css
.js
.jpg
.png
.svg
.ico
.json
مثال:
/account/profile.css
/settings.js
/api/user.json
/dashboard.png
⚠️ نکته مهم:
این تستها را در حالی انجام دهید که وارد حساب کاربری شدهاید و کوکیهای احراز هویت فعال هستند.
مرحله سوم: بررسی هدرهای کش
به دنبال هدرهایی مانند موارد زیر باشید:
X-Cache: HIT
X-Cache-Status: HIT
CF-Cache-Status: HIT
Age: 120
اگر مقدار HIT مشاهده کردید، یعنی پاسخ در کش ذخیره شده است.
مرحله چهارم: تست بدون احراز هویت
اکنون:
- یک پنجره Incognito باز کنید.
- یا از curl بدون کوکی استفاده کنید.
سپس همان آدرس را فراخوانی کنید:
curl https://target.com/account/profile.css
اگر همچنان اطلاعات کاربر نمایش داده شد:
💥 آسیبپذیری تأیید شده است.
🧰 ابزارهایی که واقعاً نیاز دارید
ابزارهای اصلی
- Burp Suite
- Burp Repeater
- Burp Proxy
- curl
- حالت Incognito مرورگر
برای شناسایی این آسیبپذیری معمولاً نیازی به ابزارهای پیچیده یا اتوماسیون خاص نیست.
🧪 Payloadهایی که در عمل جواب میدهند
این موارد را ذخیره کنید؛ در بسیاری از سناریوها مؤثر هستند:
/profile.css
/account/settings.jpg
/dashboard.js
/api/me.json
/user/info.png
💡 نکته:
پسوندهای .css و .jpg معمولاً بیشترین نرخ موفقیت را دارند.
🚩 تکنیکهای پیشرفته شناسایی (سطح حرفهای)
1. مقایسه رفتار کش
دو درخواست زیر را ارسال کنید:
/profile
/profile.css
اگر رفتار سیستم متفاوت بود، موضوع را با دقت بیشتری بررسی کنید.
2. تست نشت اطلاعات بین کاربران
- با حساب کاربری A وارد شوید.
- صفحه را کش کنید.
- با حساب کاربری B وارد شوید.
- آدرس کششده را باز کنید.
اگر کاربر B اطلاعات کاربر A را مشاهده کرد:
🚨 آسیبپذیری بحرانی است.
3. بررسی زمان ذخیرهسازی در کش
به هدر زیر توجه کنید:
Age: 300
این مقدار نشان میدهد دادهها ۵ دقیقه است که در کش ذخیره شدهاند.
🧨 زنجیرهسازی این آسیبپذیری (چگونه به P1 تبدیل میشود)
Web Cache Deception زمانی بسیار خطرناکتر میشود که با آسیبپذیریهای دیگر ترکیب شود:
- IDOR
- Endpointهای API
- تصاویر و اسناد کاربران
- Endpointهای OAuth User Info
در این شرایط: یک باگ با پیچیدگی پایین میتواند به یک رخداد با تأثیر تجاری بسیار بالا تبدیل شود.
📝 نحوه گزارش این آسیبپذیری
عنوان گزارش
Web Cache Deception Allows Public Access to Authenticated User Data
تأثیر
یک مهاجم بدون نیاز به احراز هویت میتواند از طریق نسخه کششده صفحات محافظتشده به اطلاعات حساس کاربران دسترسی پیدا کند. این موضوع میتواند منجر به افشای گسترده اطلاعات کاربران بدون هیچگونه تعامل مستقیم با قربانی شود.
اهمیت
- تمام کاربران پشت CDN تحت تأثیر قرار میگیرند.
- مکانیزم احراز هویت را بیاثر میکند.
- حریم خصوصی کاربران را نقض میکند.
🧠 چرا بسیاری از باگهانترها این آسیبپذیری را از دست میدهند؟
زیرا:
- در OWASP Top 10 جایگاه پررنگی ندارد.
- اسکنرهای خودکار معمولاً آن را تشخیص نمیدهند.
- در نگاه اول شبیه یک باگ به نظر نمیرسد.
- نیازمند درک تعامل میان چندین لایه مختلف سیستم است.
اما سازمانها و شرکتها نسبت به این آسیبپذیری حساسیت بسیار بالایی دارند.
🚀 بعد از خواندن این مطلب چه کاری انجام دهید؟
هر زمان که:
- با یک CDN مواجه شدید،
- صفحات احراز هویتشده مشاهده کردید،
- یا هدرهای کش غیرمعمول دیدید،
آن را نادیده نگیرید. تست و بررسی کنید.
همین یک آسیبپذیری برای بسیاری از پژوهشگران امنیتی گزارشهای سطح P1 و پاداشهای قابل توجه به همراه داشته است.
🐾 در قسمت بعدی این مجموعه
به بررسی آسیبپذیری زیر خواهیم پرداخت:
OAuth Misbinding
آسیبپذیریای که میتواند قربانی را بهصورت ناخواسته وارد حساب کاربری مهاجم کند.
همراه با:
- سناریوهای واقعی
- Payloadهای کاربردی
- منطق ساخت PoC
- روشهای شناسایی و بهرهبرداری
با من همراه باشید
