تستخدم المتصفحات الحديثة سياسة نفس الأصل (SOP) بشكل افتراضي مما يعني أن جلب الموارد من أصول أخرى غير مسموح به. ومع ذلك ، في بعض الحالات ، مثل هذه العمليات ضرورية. تم تصميم مشاركة الموارد عبر المنشأ (CORS) لمعالجة مثل هذه المواقف باستخدام رؤوس استجابة HTTP ، والتي تشمل التحكم في الوصول والسماح بالأصل.
المحتويات
ما هي سياسة نفس المنشأ
سياسة نفس المنشأ (SOP) هي سياسة أمان عامة لمتصفح الويب للطلبات عبر الأصل. يتحكم في الوصول إلى البيانات بين مواقع الويب وتطبيقات الويب. إذا لم يكن هناك SOP ، فإن أي صفحة ويب وأي شفرة JavaScript ستكون قادرة على الوصول إلى DOM لصفحات HTML الأخرى ، والتي لن تكون مواتية لأسباب أمنية.
ال الأصل هي مجموعة من الخصائص المشتركة لمورد الويب. يتضمن عادةً ثلاثة عناصر: المخطط (البروتوكول) ، واسم المضيف (المجال / المجال الفرعي) ، والمنفذ. تم تحديد جميع الموارد بنفسه المخطط: اسم المضيف / أي شيء: المنفذ من نفس الأصل. ومع ذلك ، إذا كان أحد العناصر الثلاثة مختلفًا ، ليس فقط إذا كانت الموارد لها مجال مختلف ، فإن المتصفحات الحديثة مثل Google Chrome تعتبر أن الموارد لها أصل مختلف. يتم تطبيق إجراءات التشغيل المعيارية (SOP) بواسطة المتصفح في كل مرة تتفاعل فيها عناصر من أصول مختلفة ، على سبيل المثال ، لا يمكن لصفحة ما جلب محتوى إطار iframe الخاص بها ما لم تكن من نفس الأصل.
ما سبق هو مجرد مقدمة قصيرة جدًا لهذا الموضوع. لمعرفة المزيد حول سياسة نفس المنشأ (SOP) ، اقرأ مقالتنا حول هذا الموضوع.
كيف يقوم CORS بإرخاء الإجراء التشغيلي الموحد
تعمل مشاركة الموارد متعددة الأصول على النحو التالي:
- يتم تقديم كود JavaScript للواجهة من https://example.com (المورد 1) يحاول استخدام XmlHttpRequest (XHR) لتقديم طلب Ajax لـ https://css.example.com/formdata/content.json (المورد 2).
GET /formdata/content.json HTTP/1.1 Host: css.example.com Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Accept-Encoding: gzip, deflate User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36 Origin: https://example.com - يتلقى المتصفح الاستجابة من خادم الويب ويرى أن الأصول مختلفة.
- عادة ، بسبب SOP ، يرفض المتصفح المورد 1 الولوج إلى المورد 2، على سبيل المثال ، إرجاع خطأ حظر طلب متعدد المنشأ: لا تسمح نفس سياسة المنشأ بقراءة المورد البعيد.
- إذا تم إعداد CORS لـ المورد 2، الرد من المورد 2 يتضمن رؤوس HTTP خاصة ، بشكل أساسي التحكم في الوصول والسماح بالأصل.
HTTP/1.1 200 OK Age: 277354 Cache-Control: max-age=604800 Content-Encoding: gzip Content-Length: 1701 Content-Type: text/html; charset=UTF-8 Date: Mon, 03 Aug 2020 11:43:26 GMT Vary: Accept-Encoding X-Cache: HIT Access-Control-Allow-Origin: https://example.com - ال التحكم في الوصول والسماح بالأصل رأس تنص على ذلك المورد 1 يسمح للوصول المورد 2.
- المتصفح يعالج الطلب.
نلاحظ أن التحكم في الوصول والسماح بالأصل قد يحدد header أصل مصدر واحد فقط أو قد يحدد حرف بدل. حرف البدل يجعل المورد 2 يمكن الوصول إليها من جميع الأصول. قد يكون هذا ، على سبيل المثال ، منطقيًا لخطوط الويب ، والتي يجب أن تكون متاحة عبر المجال.
لتمكين CORS على خادم الويب الخاص بك ، راجع موقع enable-cors على الويب ، والذي يحتوي على تعليمات لـ nginx و Apache و IIS والعديد من خوادم الويب الأخرى.
نوصيك أيضًا بمشاهدة مقطع فيديو ممتاز يُظهر عمليًا ما هو الأصل ، وكيف يعمل SOP ، وكيف يجعل CORS طلبات HTTP عبر الأصل ممكنة.
https://www.youtube.com/watch؟v=0IMz8d9Cby4
طلبات Preflight
تُستخدم الطريقة المذكورة أعلاه للطلبات البسيطة التي يعتبرها متصفح الويب آمنة ، على سبيل المثال ، طلبات GET النموذجية. في حالات أخرى ، على سبيل المثال عند وجود رؤوس مخصصة في الطلب (أي رأس آخر باستثناء قبول، قبول اللغة، لغة المحتوى، نوع المحتوى، DPR، الهابطة، حفظ البيانات، عرض منفذ العرض، عرض) أو إذا كانت طريقة HTTP هي PUT أو DELETE أو CONNECT أو OPTIONS أو TRACE أو PATCH.
طلب CORS الاختبار المبدئي هو طلب OPTIONS برؤوس CORS:
OPTIONS / HTTP/1.1
Host: www.example.com
(...)
Origin: http://example2.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-CUSTOM, Content-Type
تتضمن استجابة الخادم لطلب أسلوب OPTIONS هذا الطرق المسموح بها ، وما إذا كانت تقبل الرؤوس ، وكيفية معالجة بيانات الاعتماد ، ومدة صلاحية طلب الاختبار المبدئي:
HTTP/1.1 204 No Content
(...) Access-Control-Allow-Origin: http://example2.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-CUSTOM, Content-Type
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 86400
بعد اكتمال الاختبار المبدئي ، قد يتم إرسال الطلبات المنتظمة برؤوس CORS.
هل تستحق ذلك؟
الآن بعد أن عرفت كيفية عمل CORS ، يمكنك أن تسأل نفسك: هل يستحق تطبيق هذا على الخادم الخاص بي؟ قد يعني ذلك تغيير تكوين الخادم لإضافة رؤوس CORS لموارد محددة أو تغيير رمز جانب الخادم لإرسال هذه الرؤوس في الاستجابة. هل سيجعل هذا تطبيق الويب الخاص بك أكثر أمانًا؟
لسوء الحظ ، لا تمنع SOP و CORS أي هجمات على الويب. قد يتم التعامل معها كآلية إضافية لمنع هجمات التزوير عبر المواقع (CSRF) ولكن يجب عدم استخدامها بدلاً من الرموز المميزة المضادة لـ CSRF. أيضًا ، SOP و CORS غير مجديين تمامًا في منع أي هجمات نصية عبر المواقع (XSS).
ومع ذلك ، نظرًا لأن جميع المتصفحات الحديثة تدعم SOP ، فقد تضطر إلى تنفيذ رؤوس CORS على أي حال ، فقط لتمكين استخدام مواردك من أصول أخرى. ومع ذلك ، هذا ليس مطلبًا أمنيًا ولكنه مطلب وظيفي – بدون رؤوس CORS لن تعمل بعض تطبيقات الويب ببساطة.
احصل على أحدث محتوى حول أمان الويب
في بريدك الوارد كل أسبوع.
المؤلف
كاتب المحتوى الفني
Tomasz Andrzej Nidecki (المعروف أيضًا باسم tonid) هو كاتب محتوى تقني يعمل في Acunetix. صحفي ومترجم وكاتب تقني يتمتع بخبرة 25 عامًا في مجال تكنولوجيا المعلومات ، وكان توماسز مدير التحرير لمجلة hakin9 IT Security في سنواتها الأولى ، وكان يستخدم لتشغيل مدونة تقنية كبرى مخصصة لأمن البريد الإلكتروني.
