التعليق: مقدمة: بعد ظهور HTML5 ، اجتذب أمان الشبكة المزيد من الاهتمام الواسع. ما هي التحسينات التي أجراها الويب لأمن الشبكة؟ كيف نواجه عمليات الاحتيال والهجمات الإلكترونية الخطرة بشكل متزايد؟ يتحدث المقالة التالية عن أحدث حلقة W3C لهذه المشكلة. إذا أتيحت لي الفرصة في المستقبل ، فسوف أقوم بإجراء محتوى HTML5 على XSS و P3P والسياسة المتماثلة والسياسة (مشاركة الموارد عبر المجال) و CSP.
تتجذر السياسة الأمنية للشبكة العالمية في سياسة متجانسة. على سبيل المثال ، لا يمكن للكود الوصول إلى البيانات فقط ، ولكن ليس لديه أذونات الوصول. يتم فصل كل مصدر عن بقية الشبكة ، مما يؤدي إلى إنشاء صندوق رمل آمن للمطورين. هذا مثالي من الناحية النظرية ، ولكن الآن وجد المهاجمون طريقة ذكية لتدمير النظام.هذا هو هجوم البرمجة النصية عبر المواقع XSS ، متجاوزًا السياسات المتماثلة من خلال محتوى مزيف ونقرات خداع. هذه مشكلة كبيرة ، إذا نجح المهاجم في حقن الكود ، فسيتم تسريب قدر كبير من بيانات المستخدم.
نقدم الآن استراتيجية دفاع أمنية جديدة وفعالة للتخفيف من هذا المخاطر ، وهي سياسة الأمن المحتوية (CSP).
القائمة البيضاء المصدر
جوهر هجمات XSS هو أنه لا يمكن للمتصفح معرفة ما إذا كان يتم حقن البرنامج النصي من قبل طرف ثالث أو هو حقًا جزء من طلبك. على سبيل المثال ، سيقوم زر Google +1 بتحميل وتنفيذ التعليمات البرمجية من https://apis.google.com/js/plusone.js ، لكن لا يمكننا أن نتوقع أن نقول من الصور على المتصفح ما إذا كان الرمز هو حقًا من APIS.google.com أو من APIS.evil.example.com. يقوم المتصفح بتنزيل وتنفيذ طلب صفحة لأي رمز ، بغض النظر عن مصدره.
يعرّف CSP رأس محتوى-أمنية policyhttp للسماح لك بإنشاء قائمة بيضاء من المصادر الموثوقة ، بحيث لا ينفذ المتصفح فقط ويجعل الموارد من تلك المصادر ، بدلاً من الثقة في كل شيء يوفره الخادم. حتى إذا تمكن المهاجم من إيجاد ثغرة أمنية لحقن البرنامج النصي ، فلن يتم تنفيذه لأن المصدر غير مدرج في القائمة البيضاء.
يعد زر Google +1 أعلاه مثالًا ، لأننا نعتقد أن APIS.Google.com يوفر رمزًا صالحًا ، وكذلك أنفسنا ، يمكننا تحديد سياسة تتيح للمتصفح تنفيذ البرامج النصية من أحد المصدرين أدناه.
المحتوى-الأمن السيلي: Script-Src 'Self' https://apis.google.com
أليس هذا بسيط جدا؟ يمكن لـ Script-SRC التحكم في أذونات النصوص للصفحات المحددة. وبهذه الطريقة ، سيقوم المتصفح بتنزيل وتنفيذ البرامج النصية فقط من هذه الصفحة نفسها.
بمجرد تحديد هذه السياسة ، سيقوم المتصفح برمي خطأ عندما يكتشف الكود المحقن (لاحظ المستعرض).
تنطبق سياسات أمان المحتوى على جميع الموارد المشتركة
على الرغم من أن موارد البرامج النصية هي أكثر مخاطر الأمان وضوحًا ، فإن CSP يوفر أيضًا مجموعة غنية من التعليمات التي تسمح للصفحات بالتحكم في تحميل أنواع مختلفة من الموارد ، مثل الأنواع التالية:
Content-SRC: تقييد نوع الاتصال (مثل XHR و WebSockets و Eventsource)
Font-SRC: يتحكم في مصدر خطوط الشبكة. على سبيل المثال ، يمكنك استخدام خطوط الويب من Google من خلال font-src https://themes.googleusercontent.com.
الإطار SRC: يسرد مصدر الإطارات التي يمكن تضمينها. على سبيل المثال ، لا يسمح Frame-Src https://youtube.com فقط مقاطع الفيديو المضمنة في YouTube. .
IMG-SRC: يحدد مصدر الصورة القابلة للتحميل.
Media-SRC: تقييد مصدر الفيديو والصوت.
Object-SRC: تقييد مصدر الفلاش والمكونات الإضافية الأخرى.
النمط SRC: على غرار Script-SRC ، فهو يعمل فقط على ملف CSS.
بشكل افتراضي ، يتم تشغيل جميع الإعدادات دون أي قيود. يمكنك فصل تعليمات متعددة بواسطة Semicolons ، ولكن على غرار SCRIPT-SRC https: //host1.com ؛ script-src https://host2.com ، سيتم تجاهل التعليمات الثانية. الطريقة الصحيحة للكتابة هي البرنامج النصي https://host1.com https://host2.com.
على سبيل المثال ، لديك تطبيق يحتاج إلى تحميل جميع الموارد من شبكة توزيع المحتوى (CDN ، على سبيل المثال https://cdn.example.net) وتعرف أن محتوى عدم وجود إطارات والإضافات مطلوبة ، قد تبدو استراتيجيتك مثل:
Content-Security-Policy: Default-SRC https://cdn.example.net ؛ الإطار SRC 'لا شيء' ؛ Object-Src 'none'
التفاصيل
رأس HTTP الذي استخدمته في مثالي هو السياسة بين المحتوى ، لكن المتصفحات الحديثة قدمت بالفعل الدعم من خلال البادئات: يستخدم Firefox السياسة X-Content-Security ، WebKit يستخدم X-Webkit-CSP. في المستقبل ، سوف ينتقل تدريجيا إلى معايير موحدة.
يمكن تعيين الاستراتيجية لكل صفحة مختلفة ، والتي توفر الكثير من المرونة. نظرًا لأن بعض الصفحات الموجودة على موقعك قد تحتوي على أزرار Google +1 ، في حين أن البعض الآخر لا يفعل ذلك.
يمكن أن تكون قائمة مصدر كل تعليمة مرنة تمامًا. يمكنك تحديد نمط (بيانات: ، https :) ، أو تحديد اسم مضيف في نطاق (مثال ، والذي يطابق أي مصدر ، أي وضع وأي منفذ على المضيف) ، أو تحديد URI كاملة (https://example.com:443 ، على وجه التحديد بروتوكول HTTPS ، اسم DOMAIN على سبيل المثال ، Port 443).
يمكنك أيضًا استخدام أربع كلمات رئيسية في قائمة المصادر:
لا شيء: قد تتوقع عدم تطابق أي شيء
الذات: نفس المصدر الحالي ، ولكن لا يحتوي على نادي فرعي
غير آمن: يسمح JavaScript و CSS المضمن
غير آمن-آلية: الآليات التي تسمح بالنص إلى JS ، مثل Eval
يرجى ملاحظة أن هذه الكلمات الرئيسية تحتاج إلى اقتباس.
صندوق الرمل
هناك تعليمات أخرى تستحق مناقشة هنا: صندوق الرمل. إنه غير متسق إلى حد ما مع التعليمات الأخرى. إنه يتحكم بشكل أساسي في السلوك الذي تم التقاطه على الصفحة ، بدلاً من الموارد التي يمكن أن يتم تحميل الصفحة. إذا تم تعيين هذه الخاصية ، فسوف تتصرف الصفحة مثل إطار مع مجموعة خاصية Sandbox. هذا له مجموعة واسعة من التأثير على الصفحة ، مثل منع التقديمات النموذجية ، وما إلى ذلك. هذا يتجاوز نطاق هذه المقالة ، ولكن يمكنك العثور على مزيد من المعلومات في قسم إعدادات شعار Sandbox في مواصفات HTML5.
رمز مضمن ضار
يعتمد CSP على المصدر البيضاء ، لكنه لا يحل أكبر مصدر لهجمات XSS: حقن البرنامج النصي المضمّن. إذا كان بإمكان المهاجم ضخ علامات البرنامج النصي التي تحتوي على رمز ضار (<script> sendMyDatatoevildotcom () ؛ </script>) ، فإن المتصفح ليس لديه آلية جيدة لتمييز هذه العلامة. يمكن لـ CSP حل هذه المشكلة فقط عن طريق منع البرامج النصية المضمنة تمامًا.
لا يتضمن هذا الحظر علامات البرنامج النصي المضمنة فقط في البرنامج النصي ، ولكن أيضًا معالجات الأحداث المضمنة و JavasCrpt: URL. تحتاج إلى وضع محتويات علامة البرنامج النصي في ملف خارجي واستبدال javaScript: و <a ... onClick = [javaScript]> مع addeventListener المناسب. على سبيل المثال ، يمكنك وضع النموذج التالي:
<script>
وظيفة doamazingthings () {
تنبيه ("أنت مذهل!") ؛
}
</script>
<utont> هل أنا مدهش؟ </button>
أعد كتابة النموذج التالي:
<!-مذهلة. html->
<script src = 'Amazing.js'> </script>
<utont> هل أنا مدهش؟ </button>
// مذهلة
وظيفة doamazingthings () {
تنبيه ("أنت مذهل!") ؛
}
document.adDeventListener ('DomContentReady' ، function () {
document.getElementByid ('مذهلة')
.addeventListener ("Click" ، doamazingthings) ؛
}) ؛
بغض النظر عما إذا كنت تستخدم CSP أم لا ، فإن الكود أعلاه لديه بالفعل مزايا أكبر. INLINE JavaScript يمزج تمامًا الهيكل والسلوك ، يجب ألا تفعل ذلك. بالإضافة إلى ذلك ، من الأسهل في موارد التوعية ذاكرة التخزين المؤقت في المتصفحات ، وأسهل للمطورين فهمها ، ومن السهل تجميعها وضغطها. إذا كنت تستخدم رمز التوعية ، فستكتب رمزًا أفضل.
يجب معالجة الأنماط المضمنة بنفس الطريقة ، يجب استخراج كل من سمات النمط وعلامات النمط في ورقة الأنماط الخارجية. هذا يمكن أن يمنع جميع أنواع تسرب البيانات السحرية.
إذا كان عليك أن يكون لديك نصوص وأنماط مضمّنة ، فيمكنك تعيين قيمة "غير آمنة في خط السمة SCRIPT-SRC أو STYLE-SRC. لكن لا تفعل هذا. تحظر البرامج النصية المضمنة هي الحد الأقصى لضمان الأمان الذي توفره CSP. في الوقت نفسه ، يمكن أن تجعل الأساليب المضمنة ممنوع تطبيقك أكثر أمانًا وأكثر قوة. إنها مفاضلة ، لكنها تستحق ذلك.
تقييم
حتى إذا لم يتمكن المهاجم من ضخ البرنامج النصي مباشرةً ، فقد يحفز تطبيقك على تحويل النص المدرج إلى برنامج نصي قابل للتنفيذ وتنفيذه بنفسه. يمكن أن يصبح eval () ، و newFunction () ، و setTimeout ([string] ، ...) و setInterval ([سلسلة] ، ...) جميع الناقلات الخطرة. استراتيجية CSP لاستهداف هذا الخطر هي منع هذه المتجهات تمامًا.
هذا له بعض الآثار المترتبة على طريقة بناء تطبيقك:
Parse JSON عبر json.parse مدمج دون الاعتماد على eval. المتصفحات بعد دعم IE8 عمليات JSON المحلية ، والتي هي آمنة تماما.
أعد كتابة طريقة استدعاء SetTimeout و SetInterval بواسطة وظائف مضمنة بدلاً من الأوتار. على سبيل المثال:
setTimeout (document.queryselector ('a'). style.display = 'none' ؛ ، 10) ؛
يمكن إعادة كتابتها على النحو التالي:
setTimeOut (function () {document.queryselector ('a'). style.display = 'none' ؛} ، 10) ؛
تجنب القوالب المضمنة في وقت التشغيل: تستخدم العديد من مكتبات القالب وظيفة جديدة () لتسريع توليد القالب. هذا رائع للبرامج الديناميكية ، لكنه محفوف بالمخاطر للنص الخبيث.
تقرير
يمكن لـ CSP حظر الموارد غير الموثوق بها على جانب الخادم ، وهو أمر مفيد جدًا للمستخدمين ، ولكن من المفيد جدًا أن يتم إرسال إشعارات مختلفة إلى الخادم ، حتى نتمكن من تحديد أي حقن نصية خبيثة. لهذا الغرض ، يمكنك إرشاد المتصفح لإرسال تقرير اعتراض بتنسيق JSON إلى عنوان من خلال توجيه التقرير-URI.
محتوى الأمن السياسي: الافتراضي-SRC "الذات" ؛ ... Report-uri /my_amazing_csp_report_parser ؛
سيبدو التقرير هكذا:
{
CSP-Report: {
وثيقة-uri: ،
المرجع: ،
محظور-uri: ،
العنف المؤثر: Script-Src 'Self' https://apis.google.com ،
policy الأصلي: script-src 'self' https://apis.google.com ؛ تقرير-uri
}
}
ستساعدك المعلومات الواردة في ذلك في تحديد موقف الحظر ، بما في ذلك Document-URI الذي يحدث ، ومرجع الصفحة ، والمورد الذي ينتهك سياسة الصفحة ، والتوجيه المنتهك ، والسياسة الأصلية لجميع محتوى الصفحة.
استخدام واقعي
CSP متاح الآن على متصفحات Chrome 16+ و Firefox 4+ ، ومن المتوقع أن تتلقى دعمًا محدودًا على IE10. لا يتم دعم Safari بعد ، لكن WebKit Nightly Build متاح ، لذلك من المتوقع أن يتم دعم Safari في التكرار أدناه.
دعونا نلقي نظرة على بعض حالات الاستخدام الشائعة الاستخدام أدناه:
الحالة الفعلية 1: أداة وسائل التواصل الاجتماعي
يتضمن زر Google +1 البرامج النصية من https://apis.google.com ، بالإضافة إلى Iframes المضمنة من https://plusone.google.com. يجب أن تضم سياستك هذه المصادر لاستخدام زر Google+1. أسهل استراتيجية هي SCRIPT-SRC https://apis.google.com ؛ Frame-SRC https://plusone.google.com. تحتاج أيضًا إلى التأكد من تخزين شظايا JS التي توفرها Google في ملفات JS الخارجية.
هناك العديد من حلول التنفيذ لزر مثل Facebook. أوصيك بالالتزام بإصدار iFrame لأنه يحافظ على عزله جيدًا عن بقية موقعك. يتطلب ذلك استخدام التوجيه HTTPS://facebook.com Frame-SRC. يرجى ملاحظة ذلك افتراضيًا ، يستخدم رمز iframe الذي يوفره Facebook المسار النسبي //facebook.com. يرجى تعديل هذا الرمز إلى https://facebook.com. ليست هناك حاجة لعدم استخدام HTTP.
يعتمد زر تغريدة Twitter على البرنامج النصي والإطار ، سواء من https://platform.twitter.com (يوفر Twitter عنوان URL نسبيًا افتراضيًا ، يرجى تحرير الكود عند النسخ لتحديده على أنه HTTPS).
المنصات الأخرى لها مواقف مماثلة ويمكن حلها بالمثل. أوصي بإعداد الافتراضية SRC إلى لا شيء ومن ثم النظر إلى وحدة التحكم للتحقق من الموارد التي تحتاج إلى استخدامها للتأكد من أن القطعة تعمل بشكل صحيح.
يعد استخدام أجهزة واجهة المستخدم متعددة أمرًا بسيطًا للغاية: ما عليك سوى دمج جميع توجيهات السياسة وتذكر وضع إعدادات نفس التوجيه معًا. إذا كنت ترغب في استخدام الأدوات الثلاث أعلاه ، فستبدو الإستراتيجية هكذا:
Script-src https://apis.google.com https://platform.twitter.com ؛ Frame-SRC https://plusone.google.com https://facebook.com https://platform.twitter.com
الحالة الفعلية 2: الدفاع
لنفترض أنك تزور موقع ويب مصرفي وترغب في التأكد من تحميل الموارد التي تحتاجها فقط. في هذه الحالة ، ابدأ في إعداد إذن افتراضي لحظر كل شيء (الافتراضي-SRC "لا شيء") وإنشاء السياسة من نقطة الصفر.
على سبيل المثال ، يحتاج موقع الويب المصرفي إلى تحميل الصور والأنماط والبرامج النصية من CDN من https://cdn.mybank.net ، والاتصال بـ https://api.mybank.com/ عبر XHR لسحب البيانات المختلفة. يحتاج أيضًا إلى استخدام إطار ، لكن الإطارات كلها من الصفحات المحلية غير الثلثية. لا يوجد فلاش وخطوط ومحتوى آخر على الموقع. في هذه الحالة ، يمكننا إرسال أهم رأس CSP هو:
محتوى الأمن السياسي: الافتراضي src 'none' ؛ Script-Src https://cdn.mybank.net ؛ style-src https://cdn.mybank.net ؛ IMG-SRC https://cdn.mybank.net ؛ Connect-SRC https://api.mybank.com ؛ إطار SRC "الذات"
الحالة الفعلية 3: استخدم SSL فقط
يريد مسؤول منتدى خاتم الزواج أن يتم تحميل جميع الموارد بطريقة آمنة ، لكنه لا يريد كتابة الكثير من التعليمات البرمجية ؛ إعادة كتابة عدد كبير من البرامج النصية والأنماط المضمنة من طرف ثالث تتجاوز قدرته. لذلك ستكون الاستراتيجية التالية مفيدة للغاية:
محتوى الأمن السياسي: الافتراضي-SRC HTTPS: ؛ Script-Src Https: 'unfafe-Inline' ؛ Style-SRC HTTPS: "خط غير آمن"
على الرغم من أن SRC الافتراضي يحدد HTTPs ، فإن البرامج النصية والأنماط لا يتم موروثة تلقائيًا. سيقوم كل توجيهات بتجاوز نوع المورد الافتراضي تمامًا.
مستقبل
تقوم مجموعة عمل أمان تطبيق الويب الخاصة بـ W3C بتطوير تفاصيل مواصفات سياسة أمان المحتوى. سيدخل الإصدار 1.0 مرحلة المراجعة النهائية ، والتي هي قريبة جدًا مما هو موضح في هذه المقالة. تناقش مجموعة البريد الإلكتروني العامة لـ WebAppSec@ الإصدار 1.1 ، كما يعمل مصنعو المستعرضات بجد لتوحيد وتحسين تنفيذ CSP.
يحتوي CSP 1.1 على بعض الأشياء المثيرة للاهتمام على Artboard التي تستحق الإدراج بشكل منفصل:
إضافة السياسات من خلال علامات التعريف: الطريقة المفضلة لتعيين CSP هي رؤوس HTTP ، وهي مفيدة للغاية ، ولكنها ستكون مباشرة من خلال العلامات أو البرامج النصية ، ولكن لم يتم الانتهاء منها بعد. نفذت WebKit ميزة إعداد الإذن من خلال عناصر التعريف ، بحيث يمكنك الآن تجربة الإعدادات التالية في Chrome: إضافة <metahtp-equiv = x-webkit-csp content = [السياسة تذهب هنا]> إلى رأس المستند.
يمكنك حتى إضافة سياسات من خلال البرامج النصية في وقت التشغيل.
DOM API: إذا تمت إضافة هذه الميزة إلى التكرار التالي لـ CSP ، فيمكنك الاستعلام عن سياسة الأمان الحالية للصفحة من خلال JavaScript وضبطها وفقًا لمواقف مختلفة. على سبيل المثال ، إذا كان Eval () متاحًا ، فقد يكون تطبيق الكود الخاص بك مختلفًا قليلاً. هذا مفيد جدًا لمؤلف إطار عمل JS ؛ وما زالت مواصفات API غير مؤكدة للغاية ، يمكنك العثور على أحدث التكرار في قسم واجهة البرنامج النصي في مسودة المواصفات.
توجيهات جديدة: هناك العديد من التوجيهات الجديدة قيد المناقشة ، بما في ذلك البرنامج النصي: لا يمكن استخدام البرامج النصية المضمنة إلا إذا تم استخدام عناصر البرنامج النصي المحددة بشكل صريح ؛ الأنواع المكون الإضافي: سيؤدي ذلك إلى الحد من نوع المكون الإضافي ؛ Form-action: السماح بإرسال النموذج إلى مصدر محدد فقط.
إذا كنت مهتمًا بالمناقشات حول هذه الميزات المستقبلية ، فيمكنك قراءة أرشيف القائمة البريدية أو إضافتها إلى القائمة البريدية.
يتم ترجمة هذه المقالة من:
مقتطف من: مدونة جيانغ يوجي