Cors چیست:
به اشتراک گذاری منابع متقاطع (CORS) را می توان به عنوان یک آرامش کنترل شده از سیاست همان مبدا درک کرد. CORS یک راه کنترل شده برای به اشتراک گذاشتن منابع متقاطع ارائه می دهد.
پروتکل CORS با هدرهای خاص HTTP کار میکند که مشخص میکند کدام منبع وب قابل اعتماد هستند و ویژگیهای مرتبط با آنها، مانند اینکه آیا دسترسی تأیید شده مجاز است یا خیر. این پارامترها در تبادل هدر HTTP بین یک مرورگر و وب سایت متقاطع که سعی در دسترسی به آن دارد بیان می شود.
در اینجا یک هدر معمولی با پارامتر مبدا مشخص شده (پررنگ) به نظر می رسد:
GET /resources/public-data/ HTTP/1.1
Host: bar.other User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Connection: keep-alive
Origin: https://foo.example
در مثال بالا، طرح URI HTTPS، دامنه foo.example و شماره پورت 443 است (همانطور که توسط HTTPS مشخص است).
هنگامی که این هدر به وبسایت منتقل میشود، وبسایت باید در مورد اجازه یا عدم اجازه درخواست مبدا متقابل تماس برقرار کند. اینکه آیا درخواست اعطا می شود یا خیر بستگی به پیکربندی CORS وب سایت دریافت کننده دارد. و این پیکربندی است که در را برای حملات CORS باز می کند.
اگر CORS در وب سرور به اشتباه پیکربندی شود و “foo.example” یک سایت مخرب باشد، درخواست را می پذیرد و می تواند قربانی یک حمله CORS شود. اما این فقط نیمی از داستان است.
Types of CORS misconfigurations
این نیمی از داستان است زیرا دو نوع اصلی از پیکربندی نادرست CORS وجود دارد که می تواند یک وب سرور را در برابر حملات CORS آسیب پذیر کند – و برای رفع آن به هر دو نیاز دارید.
Access-Control-Allow-Origin (ACAO): این امکان برقراری ارتباط دو طرفه با وب سایت های شخص ثالث را فراهم می کند. پیکربندی نادرست Access-Control-Allow-Origin (ACAO) می تواند برای اصلاح یا انتقال داده های حساس مانند نام کاربری و رمز عبور مورد سوء استفاده قرار گیرد.
Access-Control-Allow-Credentials (ACAC): این به وبسایتهای شخص ثالث اجازه میدهد تا اقدامات ممتازی را انجام دهند که فقط کاربر تأیید شده واقعی باید قادر به انجام آن باشد. به عنوان مثال می توان رمز عبور یا اطلاعات تماس خود را تغییر داد.
هر دوی این پارامترها به صورت پشت سر هم در پیکربندی CORS وب سرور کار می کنند.
آنها به دو سوال خلاصه می شوند که وب سرور باید به آنها پاسخ دهد:
آیا وب سرور درخواست را از مبدا اعلام شده می پذیرد؟
اگر چنین است، آیا اعتباری برای اقدامات ممتاز نیز ارائه می دهد؟
سوال اول مربوط به خط مشی Access-Control-Allow-Origin و سوال دوم مربوط به خط مشی Access-Control-Allow-Credentials است.
بیایید به روشهای مختلفی که سرورهای وب میتوانند خطمشی Access-Control-Allow-Origin خود را پیکربندی کنند نگاهی بیندازیم:
CORS attack example
در اینجا یک حمله CORS می تواند شبیه باشد:
- قربانی در حالی که احراز هویت به goodwebsite.com احراز هویت می شود، از evilwebsite.com بازدید می کند.
- evilwebsite.com یک اسکریپت مخرب طراحی شده برای تعامل با goodwebsite.com را روی دستگاه قربانی میریزد.
- قربانی ناخواسته اسکریپت مخرب را اجرا می کند و اسکریپت یک درخواست متقاطع را به goodwebsite.com ارسال می کند. در این مثال، فرض کنید درخواست برای به دست آوردن اعتبار لازم برای انجام یک اقدام ممتاز، مانند افشای رمز عبور کاربر، ساخته شده است.
- goodwebsite.com درخواست منبع متقابل قربانی و هدر CORS را دریافت می کند.
- وب سرور هدر CORS را بررسی می کند تا مشخص کند که داده ها را به goodwebsite.com ارسال کند یا نه. در این مثال، ما فرض می کنیم که CORS با احراز هویت مجاز است (Access-Control-Allow-Credentials: true).
- درخواست تأیید می شود و داده ها از مرورگر قربانی به evilwebsite.com ارسال می شود.
این بدترین سناریو است که در آن همه چیز کاملاً باز است. اما همچنان نمونه ای از ظاهر یک حمله CORS است. و این بدترین سناریو در واقع بسیار رایج است. در واقع، در سال 2016 مشخص شد که فیس بوک در برابر چنین حمله CORS آسیب پذیر است.
نحوه جلوگیری از حملات مبتنی بر CORS
این در درجه اول پیکربندی نادرست وب سرور است که آسیب پذیری های CORS را فعال می کند. راه حل این است که با پیکربندی صحیح خط مشی های CORS وب سرور خود، در وهله اول از بروز آسیب پذیری ها جلوگیری کنید. در اینجا چند نکته ساده برای جلوگیری از حملات CORS آورده شده است.
1. مبداهای مجاز را مشخص کنید
اگر یک منبع وب حاوی اطلاعات حساس باشد، مبدأ(های) مجاز باید به طور کامل در سربرگ Access-Control-Allow-Origin مشخص شود (یعنی بدون علامت های عام).
2. فقط به سایت های قابل اعتماد اجازه دهید
اگرچه ممکن است این یکی بدیهی به نظر برسد، به خصوص با توجه به نکته قبلی، اما منشاء مشخص شده در سربرگ Access-Control-Allow-Origin باید منحصراً سایت های قابل اعتماد باشد. منظور من این است که باید از انعکاس پویا سرچشمه ها از سرصفحه های درخواست متقابل دامنه بدون اعتبار سنجی خودداری کنید، مگر اینکه وب سایت یک سایت عمومی است که برای دسترسی به هیچ نوع احراز هویتی مانند نقطه پایانی API نیاز ندارد.
3. «تهی» را در لیست سفید قرار ندهید
شما باید از استفاده از هدر Access-Control-Allow-Origin: null خودداری کنید. در حالی که تماسهای منابع بین دامنهای از اسناد داخلی و درخواستهای sandbox میتوانند منشأ «تهی» را مشخص کنند، شما باید با درخواستهای متقاطع داخلی مانند درخواستهای متقاطع خارجی رفتار کنید. شما باید هدرهای CORS خود را به درستی تعریف کنید.
4. سیاست های امنیتی سمت سرور مناسب را اجرا کنید
فکر نکنید که پیکربندی صحیح هدرهای CORS برای ایمن سازی وب سرور شما کافی است. این یکی از قطعات است، اما جامع نیست. CORS رفتارهای مرورگر را تعریف می کند و هرگز جایگزینی برای محافظت از سمت سرور از داده های حساس نیست. علاوه بر پیکربندی مناسب CORS، باید از داده های حساس مانند احراز هویت و مدیریت جلسه محافظت کنید.
به عنوان یک کاربر، اساساً میخواهید یک قدم جلوتر از کلاهبرداریهای فیشینگ و وبسایتهای مخرب و دانلودها باشید تا شانس خود را برای قربانی شدن در حمله CORS به حداقل برسانید. نکات عقل سلیم زیر می تواند کمک کننده باشد.
این مراحل برای بسیاری از حملات آنلاین مانند اجتناب از آنتی ویروس جعلی مشابه هستند، بنابراین به طور کلی روش های خوبی برای دنبال کردن هستند.
- از فایروال استفاده کنید – تمام سیستم عامل های اصلی دارای فایروال ورودی داخلی هستند و تمام روترهای تجاری موجود در بازار دارای فایروال NAT داخلی هستند. مطمئن شوید که اینها را فعال کرده اید زیرا ممکن است در صورت کلیک روی یک پیوند مخرب از شما محافظت کنند.
- فقط نرم افزار آنتی ویروس معتبر و معتبر را از فروشندگان قانونی خریداری کنید و آن را طوری پیکربندی کنید که اسکن های مکرر را در فواصل زمانی منظم انجام دهد.
- هرگز روی پاپ آپ ها کلیک نکنید. شما هرگز نمی دانید که آنها شما را کجا خواهند برد.
- اگر مرورگر شما هشداری در مورد وب سایتی که می خواهید به آن دسترسی پیدا کنید نشان می دهد، باید توجه کنید و اطلاعات مورد نیاز خود را از جای دیگری دریافت کنید.
- پیوستها را در ایمیلها باز نکنید، مگر اینکه دقیقاً بدانید چه کسی پیوست را ارسال کرده و چیست.
- روی پیوندها (URL) در ایمیلها کلیک نکنید، مگر اینکه دقیقاً بدانید چه کسی URL را فرستاده و به کجا پیوند میدهد. و حتی پس از آن، لینک را به دقت بررسی کنید. آیا این پیوند HTTP است یا HTTPS؟ امروزه اکثر سایت های قانونی از HTTPS استفاده می کنند. آیا لینک حاوی اشتباهات املایی (فیس بوک به جای فیس بوک) است؟ اگر می توانید بدون استفاده از پیوند به مقصد برسید، در عوض این کار را انجام دهید.
نظرات کاربران