فرایند کشف آسیب پذیری PDF-based Stored XSS روی یک وبسایت فروشگاهی ایرانی ✍

اول از همه بریم ببینیم اصلاً PDF-based Stored XSS چیه.

همون‌طور که می‌دونید Stored XSS جزو آسیب‌پذیری‌های خطرناک محسوب می‌شه، چون Payload روی سرور ذخیره می‌شه و هر کسی که بهش دسترسی داشته باشه، اکسپولیت می‌شه.

معمولاً برای پیدا کردنش سراغ پروفایل کاربری، احراز هویت، کامنت‌ها، تیکت‌های پشتیبانی و جاهایی که از کاربر ورودی گرفته میشه میریم.

ولی خیلی وقت‌ها WAF ( Application Firewall) اجازه نمیده Payload های مخرب xss  جواب بدن و باعث بلاک کردن پیلود میشن .


اینجاست که آپلود فایل PDF مخرب می‌تونه راه خوبی برای رسیدن به Stored XSS باشه، چون PDF می‌تونه javascript parsing داشته باشه و خیلی از سایت‌ها این موضوع رو جدی نمیگیرن.

چطور به این آسیب‌پذیری می‌رسیم؟

اول باید Payload یا کد کد مخرب جاوا اسکریپت رو داخل یک فایل PDF تزریق کنیم. بعد اون فایل رو توی بخش‌هایی که سایت اجازه آپلود فایل میده، آپلود می‌کنیم؛
مثل:
حساب کاربری، تیکت‌های پشتیبانی، ارسال مدارک، نظرات و موارد مشابه
وقتی فایل مخرب پشت صحنه آپلود می‌شه، اگه سایت فایل PDF رو مستقیم داخل مرورگر نمایش بده و محدودیتی روی محتوای فعالش نداشته باشه، مرورگر میاد کدهای JavaScript داخل PDF رو اجرا می‌کنه. Payload ما (مثلاً alert) اجرا می‌شه و یعنی به Stored XSS رسیدیم.

نکته مهم: این رفتار معمولاً روی مرورگر Chrome بهتر دیده می‌شه.

چه زمانی باگ حساب نمی‌شه؟

بعضی وقت‌ها بعد از آپلود فایل مخرب، مرورگر به‌جای اجرا کردن PDF، فایل رو دانلود می‌کنه یا اصلاً اجازه اجرای کد رو نمی‌ده. این یعنی سایت تنظیمات امنیتی بهتری داره و عملاً به Self XSS یا عدم بهره‌برداری می‌خوریم و باگ قابل سوءاستفاده‌ای وجود نداره.

چطوری این باگ رو کشف کردم؟

داشتم یکی از فروشگاه‌های اینترنتی ایرانی رو بررسی می‌کردم که دیدم توی بخش تیکت پشتیبانی امکان آپلود فایل PDF وجود داره. فایل PDF مخرب خودم رو اونجا آپلود کردم و به محض اینکه روی فایل کلیک کردم، Payload اجرا شد و به باگ رسیدم.

این آسیب‌پذیری روی یکی از Subdomainها بود. طبیعتاً اگه همین مشکل روی دامنه اصلی وجود داشت، شدت باگ خیلی بالاتر حساب می‌شد و پاداش بیشتری هم می‌شد گرفت.

@dagen_security