هدف از ارایه این مقاله بررسی موارد زیر است:

اولاً تشریح آسیب‌پذیری‌ها و تهدیدات ناشی از پیکربندی نادرست مکانیزم CORS (Cross-Origin Resource Sharing)؛ ثانیاً نشان‌دادن اینکه چگونه تنظیمات اشتباه می‌تواند به افشای اطلاعات یا دسترسی غیرمجاز به منابع محافظت‌شده بینجامد. در نهایت، با تحلیل دقیق SOP (Same Origin Policy) ارتباط و تعامل این دو مکانیزم امنیتی را تبیین می‌کنیم تا مخاطب به‌صورت کاربردی و دقیق بفهمد قرار است از خواندن این داکیومنت به چه نتایجی برسد.همچنین برای درک بهتر نحوه شکل‌گیری این ضعف‌ها، مفهوم SOP یا Same Origin Policy را به طور کامل مورد تحلیل قرار خواهیم داد، تا ارتباط میان این دو مکانیزم امنیتی و تأثیر آن‌ها بر امنیت کلی وب‌اپلیکیشن‌ها به‌صورت دقیق روشن شود.

تعاریف:

برای خواننده‌ای که ممکن است با برخی اصطلاحات آشنا نباشد، در ادامه تعاریف کوتاهِ مفاهیم کلیدی آورده شده است:

• Origin : ترکیبی از سه مؤلفهٔ اصلی — پروتکل (Protocol)، پورت (Port) و هاست (Host).
• Same Origin Policy (SOP) : سیاست امنیتی مرورگرها که تعیین می‌کند آیا منابع و پاسخ‌های HTTP مربوط به درخواست‌های Cross-Origin قابل پردازش یا رندر هستند یا خیر.
• Cross-Origin : حالتی که در آن حداقل یکی از سه مؤلفهٔ Origin (پروتکل، پورت و هاست) بین دو منبع متفاوت باشد.
• CORS (Cross Origin Resource Sharing) : مکانیزمی برای کنترل و مدیریت دسترسی بین Originهای متفاوت، به‌منظور مجاز یا غیرمجاز کردن پردازش پاسخ‌ها توسط مرورگر در مواقعی که SOP به‌طور پیش‌فرض مانع از رندر می‌شود.
• Access-Control-Allow-Origin : هدر پاسخ HTTP که مشخص می‌کند کدام Originها مجاز به دسترسی هستند.
• Access-Control-Allow-Credentials : هدر پاسخ HTTP که تعیین می‌کند آیا مرورگر اجازه دارد کوکی‌ها و اطلاعات احراز هویت را همراه درخواست ارسال کند (برای ارسال کوکی‌ها مقدار این هدر باید true باشد).
• XHR (XMLHttpRequest) : روش‌هایی که مرورگرها برای ارسال درخواست‌های HTTP از سمت کلاینت استفاده می‌کنند و معمولاً در بررسی رفتار SOP/CORS کاربرد دارند.
• HTTP Response : پاسخی که سرور به یک درخواست HTTP برمی‌گرداند و شامل هدرها و بدنهٔ پاسخ است.

در ابتدا باید SOP رو خوب درک کنیم:

SOP( Same Origin Policy )

یک قاعده یا سیاست امنیتی در مرورگرها هست که از پردازش یا رندر شدن HTTP Responseهای مربوط به درخواست‌های Cross-Origin  جلوگیری می‌کند مگر آنکه مکانیزم‌های دیگری مثلCORS  (که در ادامه آن را بررسی میکنیم) به ‌صراحت اجازه دهند.

اصلا Origin  چیست؟

در واقع Origin  ترکیبی از سه بخش اصلی است:

• Protocol
• Port
• Host

زمانی که هر سه جزء یک Origin شامل پروتکل (protocol)، پورت (port) و هاست (host) با یکدیگر یکسان باشند ،Originها Same هستن که و ارتباط آن ها از نوعSame-Origin  محسوب می شود.

اما اگر حتی یکی از این سه مؤلفه میان دو Origin تفاوت داشته باشد ،  Originها متفاوت بوده و ارتباط میان آن‌ها در دسته‌ی  Cross-Origin  قرار می‌گیرد. مثال های زیر رو بررسی کنید:

Origin A: https://example.com    Origin B: https://www.example.com  è Cross-Origin , Host

Origin A: http://example.com      Origin B: https://example.com  è Cross-Origin , Protocol

Origin A: https://example.com      Origin B: https://example.com:8080  è Cross-Origin , Port

نحوه عملکرد SOP

حالا برای درک بهتر و عمیق تر SOP سعی میکنیم با مثال پیش بریم:

Origin A : https://example.com

Origin B : https://target.com

چنان‌که می‌دانیم این دو Origin متفاوت‌اند و ارتباط میان آن‌ها از نوع Cross-Origin خواهد بود. حال فرض کنید مهاجم دو تب در مرورگر خود باز کرده است:

• تب 1 مربوط به com که همان Origin A
• و تب 2 مربوط به com که همان Origin B

اتکر تلاش می‌کند از تب 1 به target.com  درخواست HTTP ارسال کند. از آن‌جا که ارتباط Cross-Origin است، درخواست به سمت target.com  ارسال می‌شود ولی مرورگر به‌دلیل وجود قانون SOP پاسخ (HTTP Response) را رندر نکرده و آن راblock  می‌کند.

مثال واقعی از عملکرد مرورگر و SOP  :

کاربر در حال تلاش برای ارسال XHR بهtarget.com  است:

در این حالت ممکن است وضعیت پاسخ (HTTP Status Code) برابر با 200  باشد، اما به‌علت اعمال SOP، پاسخِ دریافتی block  شده و قابل پردازش نیست.

حالا بریم سراغ بررسی CORS:

CORS: Cross Origin Resource Sharing

CORS  در واقع یک سازوکار مدیریت دسترسی است که اجازه می‌دهد مرورگرها در شرایطی که SOP مانع از پردازش پاسخ‌های Cross-Origin است، با قواعد مشخصی آن مانع را بردارند یا تعدیل کنند. به‌عبارت دیگر، CORS  راهی کنترل‌شده برای «دورزدن» محدودیت‌های SOP است، اما فقط در صورتی که سرور با هدرهای مناسب این دسترسی‌ها را مجاز کند.

چه زمانی نیاز به دور زدن SOP داریم؟

برای مثال فرض کنید که کمپانی target.com دارای دارایی‌ها و سرویس‌های مختلفی است که باید با هم تعامل داشته باشند، مانند:

api.target.com, store.target.com, dev.target.com, mail.target.com

یا حتی بخواهد با سرویس‌های third-party مانند google.com  تعامل کند.

همه ی این Originها با هم Same یا یکسان نیستند و ارتباط اون ها با هم قطعا Cross-Origin محسوب میشه!

پس برای اینکه این تعامل صورت بگیره تنظیمات CORS  باید در سرور target.com  انجام بشه.

زمانی متوجه میشی که CORS  در یک وب اپلیکیشن تنظیم شده که توی هدرهای HTTP Response  ,  موارد زیر رو ببینی:

که دو هدر اول از باقی مهم تر هستند که در ادامه بررسی میکنیم.

CORS Misconfiguration

در صورت پیکربندی نادرست CORS، سرور ممکن است به‌طور غیرمجاز به درخواست‌هایی از Originهای غیرمجاز پاسخ دهد که این امر می‌تواند به افشای اطلاعات حساس یا دسترسی غیرمجاز به منابع محافظت‌شده منجر شود.

برای شناسایی آسیب‌پذیری CORS Misconfiguration  معمولاً بررسی دقیق هدرهای  HTTP Responseضروری است. برخی از هدرهای کلیدی که باید به آن‌ها توجه شود عبارت‌اند از:

• هدر Access-Control-Allow-Originمشخص می‌کند که کدام Origin مجاز است به منابع سرور دسترسی داشته باشد.
• هدر Access-Control-Allow-Credentials تعیین می‌کند که آیا مرورگر مجاز است همراه درخواست، کوکی‌ها یا اطلاعات احراز هویت را نیز ارسال کند یا خیر. مقدار این هدر در صورت نیاز به ارسال کوکی‌ها باید true تنظیم شود.

یکی از روش‌های رایج برای شناسایی این آسیب‌پذیری تغییر Origin درخواست به Origin  دیگر(مثلا hacker.com ) توسط مهاجم است.

اگر در پاسخ سرور، هدرهای Access-Control-Allow-Origin  و Access-Control-Allow-Credentials  وجود داشته باشند و مقدار Origin مهاجم در HTTP Response برگردد ، می‌توان نتیجه گرفت که پیکربندی CORS به‌درستی انجام نشده است.

نمونه:

 یک Misconfiguration مرسوم

یکی از مرسوم‌ترین و کلاسیک‌ترین Misconfigurationها این است که سرور به‌صورت انعطاف‌ناپذیری هر Originی را می‌پذیرد. یعنی عملاً مقدار Origin ارسال‌شده را echo می‌کند یا از *  به‌شکل نادرست استفاده می‌نماید.

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

ارزیابی شدت آسیب پذیری:

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

برای درک بهتر و عمیق‌تر پیشنهاد می‌کنم حتماً لابراتوارهای PortSwigger  را حل کنید؛ این تمرین‌ها کاربردی بودن مفاهیم و نحوهٔ کشف و بهره‌برداری از Misconfigurationها را به‌خوبی نشان می‌دهند.