ما هو CORS؟

في الماضي، عندما كانت تقنيات الإنترنت لا تزال جديدة، حدثت مشكلات تزييف الطلبات عبر المواقع (CSRF). أدت هذه المشكلات إلى إرسال طلبات عملاء وهمية من متصفح الضحية إلى تطبيق آخر.

على سبيل المثال، سجلت الضحية الدخول إلى تطبيق البنك الخاص بها. ثم جرى خداعها لتحميل موقع ويب خارجي على علامة تبويب متصفح جديدة. ثم استخدم موقع الويب الخارجي بيانات اعتماد ملفات تعريف الارتباط الخاصة بالضحية ونقل البيانات إلى تطبيق البنك في أثناء التظاهر بأنه الضحية. ثم حصل المستخدمون غير المصرح لهم على وصول غير مقصود إلى تطبيق البنك.

لمنع مشكلات تزييف الطلبات عبر المواقع (CSRF) هذه، تطبق جميع المتصفحات حاليًا سياسة الأصل الأوحد.

سياسة الأصل الأوحد

اليوم، تفرض المتصفحات ألا يمكن للعملاء إلا إرسال الطلبات إلى مورد له أصل عنوان URL الخاص نفسه بالعميل. يجب أن يتطابق البروتوكول والمنفذ واسم المضيف لعنوان URL الخاص بالعميل مع الخادم الذي يطلبه.

على سبيل المثال، ضع في اعتبارك مقارنة الأصل لعناوين URL أدناه مع عنوان URL الخاص بالعميل http://store.aws.com/dir/page.html.

URL	النتيجة	السبب
http://store.aws.com/dir2/new.html	أصل أوحد	اختلاف المسار فقط
http://store.aws.com/dir/inner/other.html	أصل أوحد	اختلاف المسار فقط
https://store.aws.com/page.html	أصل مختلف	بروتوكول مختلف
http://store.aws.com:81/dir/page.html	أصل مختلف	منفذ مختلف (http://‎ هو المنفذ 80 افتراضيًا)
http://news.aws.com/dir/page.html	أصل مختلف	مضيف مختلف

لذا، فإن سياسة الأصل الأوحد آمنة للغاية ولكنها غير مرنة لحالات الاستخدام الحقيقية.

تُعد مشاركة الموارد عبر الأصول (CORS) امتدادًا لسياسة الأصل الأوحد. إنك بحاجة إليها لمشاركة الموارد المصرح بها مع جهات خارجية. على سبيل المثال، تحتاج إلى مشاركة الموارد عبر المصادر (CORS) عندما تريد سحب البيانات من واجهات برمجة التطبيقات (API) الخارجية العامة أو المصرح بها. وتحتاج إليها أيضًا إذا كنت تريد السماح بالوصول المصرح به من جهة خارجية إلى موارد الخادم الخاصة بك.

في بروتوكول نقل النص التشعبي (HTTP)، أساليب الطلب هي عمليات البيانات التي يريد العميل أن ينفذها الخادم. تتضمن أساليب بروتوكول نقل النص التشعبي (HTTP) الشائعة GET (الحصول) وPOST (نشر) وPUT (وضع) وDELETE (حذف).

في التفاعل المعتاد لمشاركة الموارد عبر الأصول (CORS)، يرسل المتصفح رؤوس الطلب والتحكم في الوصول في الوقت نفسه. عادةً ما تكون هذه طلبات البيانات GET وتُعد منخفضة المخاطر.

ومع ذلك، تعتبر بعض طلبات بروتوكول نقل النص التشعبي (HTTP) معقدة، وتتطلب تأكيد الخادم قبل إرسال الطلب الفعلي. تُسمى عملية الموافقة المسبقة طلب التحقق المسبق.

الطلبات المعقدة عبر الأصول

تكون الطلبات عبر الأصول معقدة إذا استخدمت أيًا مما يلي:

• أساليب أخرى غير GET أو POST أو HEAD
• رؤوس أخرى غير Accept-Language أو Accept أو Content-Language
• رؤوس نوع المحتوى بخلاف multipart/form-data أو application/x-www-form-urlencoded أو text/plain

لذلك، على سبيل المثال، تُعد طلبات حذف البيانات الموجودة أو تعديلها معقدة.

كيفية عمل طلبات التحقق المسبق

تنشئ المتصفحات طلبات التحقق المسبق إذا لزم الأمر. إنه طلب OPTIONS (خيارات) مثل الطلب الآتي.

OPTIONS /data HTTP/1.1 الأصل: https://example.com Access-Control-Request-Method: DELETE

يرسل المتصفح طلب التحقق المسبق قبل رسالة الطلب الفعلي. يجب أن يستجيب الخادم لطلب التحقق المسبق بمعلومات حول طلبات الأصل المتعدد التي يرغب الخادم في قبولها من عنوان URL الخاص بالعميل. يجب أن تتضمن رؤوس استجابة الخادم ما يلي:

• Access-Control-Allow-Methods
• Access-Control-Allow-Headers
• Access-Control-Allow-Origin

فيما يلي مثال لاستجابة الخادم.

HTTP/1.1 200 OK Access-Control-Allow-Headers: Content-Type Access-Control-Allow-Origin: https://news.example.com Access-Control-Allow-Methods: GET, DELETE, HEAD, OPTIONS

تتضمن استجابة التحقق المسبق أحيانًا رأس Access-Control-Max-Age إضافيًا. يحدد هذا المقياس المدة (بالثواني) التي يستغرقها المتصفح لتخزين نتائج التحقق المسبق مؤقتًا في المتصفح. يسمح التخزين المؤقت للمتصفح بإرسال العديد من الطلبات المعقدة فيما بين طلبات التحقق المسبق. لا يلزم إرسال طلب التحقق المسبق آخر حتى ينقضي الوقت المحدد من خلال max-age.

 

يجب مراعاة ما يلي عند تكوين مشاركة الموارد عبر الأصول (CORS) على خادمك.

تحديد قوائم الوصول المناسبة

من الأفضل دائمًا منح إمكانية الوصول إلى النطاقات الفردية باستخدام قوائم مفصولة بفواصل. تجنب استخدام أحرف البدل إلا إذا كنت تريد جعل واجهة برمجة التطبيقات (API) عامة. وبخلاف ذلك، قد يؤدي استخدام أحرف البدل والتعبيرات العادية إلى وجود ثغرات أمنية.

على سبيل المثال، لنفترض أنك تكتب تعبيرًا عاديًا يمنح الوصول إلى جميع المواقع التي تحتوي على اللاحقة permitted-website.com. باستخدام تعبير واحد، تمنح إمكانية الوصول إلى api.permitted-website.com وnews.permitted-website.com. ولكنك أيضًا تمنح إمكانية الوصول عن غير قصد إلى مواقع غير مصرح بها يمكنها استخدام نطاقات، مثل maliciouspermitted-website.com.

تجنب استخدام الأصل الفارغ في قائمتك

ترسل بعض المتصفحات القيمة null (فارغ أو فارغة) في رأس الطلب لسيناريوهات معينة، مثل طلبات الملفات أو الطلبات من المضيف المحلي.

ومع ذلك، يجب عدم تضمين القيمة الفارغة في قائمة الوصول الخاصة بك. فهذا يتسبب أيضًا في مخاطر أمنية نظرًا إلى أن الطلبات غير المصرح بها التي تحتوي على رؤوس فارغة قد تتمكن من الوصول.