پیکربندیهای نادرست CORS (Cross-Origin Resource Sharing) در بسیاری از برنامههای کاربردی وب یافت میشوند. با این حال، شناسایی موارد واقعی نیازمند درک عمیقتری از مدل اعتماد زیربنایی سیستم است، فراتر از صرفاً تست پیلودها. این گزارش، داستان کشف یک سیاست CORS آسیبپذیر از طریق بررسی عبارات منظم (Regular Expressions) و چگونگی تبدیل آن به یک آسیبپذیری خطرناک با ترکیب یک API قدیمی و فراموششده را شرح میدهد. تمرکز این بررسی بر روی برنامهای با نام فرضی site.com بود که دارای زیردامنههای متعدد و شبکهای پیچیده از APIها بود.
شناسایی سیاست CORS
پس از ورود به برنامه، یک درخواست جالب مشاهده شد:
GET https://site.com/api/login/user
این نقطه پایانی، اطلاعات کاربر شامل ایمیل، شناسه کاربری و نام کامل را در قالب JSON برمیگرداند و دارای CORS فعال بود. تستهای اولیه برای ارزیابی امکان دور زدن سیاست CORS به شرح زیر انجام شد:
Origin: https://site.com → ✅ (مجاز)
Origin: https://site.com.attacker.com → ❌ (غیرمجاز)
Origin: https://anything.site.com → ✅ (مجاز)
Origin: https://anything.domain.com → ❌ (غیرمجاز)
تحلیل عبارات منظم (Regex)
به جای تست کورکورانه، تمرکز بر روی منطق تصمیمگیری برنامه برای اعتماد به Originها قرار گرفت. با بررسی ابزارهای توسعهدهنده (DevTools) و جستجو برای RegExp، الگوهای زیر کشف شد:
// الگوهای کشف شده در سمت کلاینت i = [ new RegExp(`^(?:${ r.join('|') })-(.*).(?:site|siteteam)(?:ga)?.com`), new RegExp('^(.*).(?:sitequote)(?:ga)?.com') ]; // ... new RegExp( `^(?!local|test)(.*\\.)?(${ Object.entries(a).map((([e,t]) => `(?:${ t })(ga)?\\.${ e }`)).join('|') }|wtsite\\.(com|de))$` )
این الگوها لیستی از دامنهها مانند siteemail.com, sitequote.com, wtsite.com و موارد دیگر را مشخص میکردند. این موضوع این احتمال را تقویت کرد که همین دامنهها، یا بخشی از آنها، ممکن است در سمت سرور نیز برای اعتبارسنجی Originها بازبینی شوند، زیرا توسعهدهندگان غالباً الگوهای پیکربندی را در محیطهای مختلف بازاستفاده میکنند.
با این فرضیه، تست دستی هر یک از این دامنهها با تنظیم هدر Origin سفارشی آغاز شد:
https://siteemail.com → ❌ (غیرمجاز)
https://anything.siteemail.com → ✅ (مجاز)
https://anything.siteemail.com.attacker.com → ❌ (غیرمجاز)
https://wtsite.com → ❌ (غیرمجاز)
https://anything.wtsite.com → ✅ (مجاز)
https://anything.wtsite.com.attacker.com → ✅ (مجاز)
ارسال درخواست با هدر:
Origin: https://anything.wtsite.com.attacker.com
با موفقیت پاسخ
Access-Control-Allow-Origin: https://anything.wtsite.com.attacker.com و Access-Control-Allow-Credentials: true را دریافت کردیم. این امر نشان میدهد که سرور، هدر Origin را به شکلی ناامن اعتبارسنجی میکند؛ احتمالاً با منطقی شبیه به origin.includes('wtsite.com'). این آسیبپذیری به مهاجم اجازه میدهد تا با میزبانی یک صفحه مخرب در دامنه خود (attacker.com)، درخواستهای مورد اعتماد به سرور ارسال کند.
زنجیرهسازی آسیبپذیریها: یافتن نقطه پایانی حساس
دستیابی به قابلیت دور زدن CORS به تنهایی کافی نبود؛ نیاز به نقطهای حساس برای بهرهبرداری بود. با استفاده از Wayback Machine، جستجو برای APIهای قدیمی و فراموششده انجام شد. درخواست زیر به بازیابی مسیرهای API قدیمی کمک کرد:
http://web.archive.org/cdx/search/cdx?url=api.site.com/*&fl=original&collapse=urlkey
پس از بررسی دستی مسیرهای بازیابی شده، نقطه پایانی زیر فعال یافت شد:
https://api.site.com/refresh/csrf/app
این API توکن CSRF، هدرهای مرتبط با نشست (session) و سایر اطلاعات مفید را بازمیگرداند. نکته مهم این بود که کوکیهای مهم سایت با ویژگی SameSite=None تنظیم شده بودند که امکان ارسال آنها را در درخواستهای Cross-Origin فراهم میکرد.
سناریوهای بهرهبرداری (Exploit Scenarios)
با ترکیب قابلیت دور زدن CORS و توکن CSRF تازه، چندین مسیر برای بهرهبرداری ممکن شد:
تغییر آدرس ایمیل: ارسال درخواست به نقطه پایانی بهروزرسانی ایمیل (/api/user/update/email) همراه با توکن CSRF و اعتبار کاربر (به لطف SameSite=None) میتوانست ایمیل بازیابی را تغییر داده و منجر به تصاحب کامل حساب کاربری شود.
بهروزرسانی پروفایل: امکان تغییر نام، پروفایل یا جزئیات آدرس کاربر وجود داشت. اگرچه این مورد منجر به تصاحب کامل حساب نمیشود، اما یکپارچگی دادهها را به خطر انداخته و با تأثیر بر معیار Integrity در CVSS، بر امتیاز آسیبپذیری میافزاید.
نتیجهگیری
این یافته نشان داد که چگونه یک سیاست CORS ضعیف، ناشی از اعتبارسنجی نامناسب عبارات منظم، در ترکیب با یک API CSRF قدیمی و نادیده گرفته شده، میتواند به آسیبپذیریهای جدی منجر شود. درس اصلی برای محققان امنیتی این است که: مدلهای اعتماد را در Regexها جستجو کنند، APIهای قدیمی را شناسایی نمایند و به دامنههای ذکر شده در Regex سمت کلاینت توجه ویژه داشته باشند، همچنین سیاستهای CORS را نباید دستکم گرفت. این آسیبپذیری به صورت مسئولانه به site.comگزارش شد. پس از آن، آنها سیاست CORS را درست کردند و آن نقطه پایانی را غیرفعال کردند.
