آسیب‌پذیری CORS Misconfiguration و نحوه سوءاستفاده از آن

درود دوستان

اول ببینیم CORS چیه و اصلاً چرا به وجود اومده؟

CORS یا Cross-Origin Resource Sharing یک مکانیزم امنیتی در سمت مرورگره که به سرور اجازه می‌ده مشخص کنه کدوم Originها می‌تونن به منابعش دسترسی داشته باشن.
CORS برای حذف SOP ساخته نشده، بلکه برای دور زدن کنترل‌شده‌ی Same-Origin Policy به وجود اومده.

SOP چی بود؟

طبق SOP، مرورگر اجازه نمی‌ده یک وب‌سایت به پاسخ‌های وب‌سایتی با Origin متفاوت دسترسی داشته باشه.

Origin از سه بخش تشکیل می‌شه:

1. پروتکل (http / https)

2. دامنه

3. پورت

اگه یکی از این‌ها فرق کنه، Origin متفاوت حساب می‌شه.

چطور بفهمیم سایت از CORS استفاده می‌کنه؟

برای این کار، هدر Origin رو به درخواست اضافه می‌کنیم.
اگه در پاسخ هدر زیر وجود داشت یعنی CORS فعاله:

Access-Control-Allow-Origin

اما برای اینکه این موضوع به یک آسیب‌پذیری واقعی تبدیل بشه، معمولاً باید هدر زیر هم وجود داشته باشه:

Access-Control-Allow-Credentials: true

\شروع تست آسیب‌پذیری CORS

نکته مهم اینه که تست CORS بعد از احراز هویت انجام می‌شه و بهترین نقطه برای تست، بخش‌هایی مثل پروفایل کاربر یا APIهای حساس هست.

مراحل تست

ابتدا مقدار Origin رو برابر دامنه خود سایت قرار می‌دیم (با https و بدون https تست می‌کنیم).
اگر در پاسخ این هدرها برگشت:

Access-Control-Allow-Origin
Access-Control-Allow-Credentials: true

یعنی برنامه از CORS استفاده می‌کنه.

بعد میایم Origin رو با ساب‌دامنه‌های سایت تست می‌کنیم.
اگر پاسخ معتبر بود، سراغ دامنه‌های دلخواه می‌ریم، مثلاً:

Origin: https://hacker.com

اگر سرور این Origin رو هم قبول کرد، برنامه آسیب‌پذیره.

سناریوهای پیشرفته‌تر

اگر به دامنه مستقیم جواب نداد:

• مقدار Origin رو null می‌ذاریم

• دامنه‌هایی با ساختار اشتباه تست می‌کنیم، مثلاً:

  • hackertarget.com

  • target.com.hacker.com

در این حالت احتمال زیادی وجود داره که برنامه‌نویس از regex اشتباه برای اعتبارسنجی Origin استفاده کرده باشه.

نکته مهم

این نوع آسیب‌پذیری زمانی قابل سوءاستفاده است که اپلیکیشن Cookie-based authentication داشته باشه، چون کوکی‌ها به‌صورت خودکار توسط مرورگر ارسال می‌شن.