الحدّ من النصوص البرمجية على المواقع الإلكترونية (XSS) من خلال تطبيق سياسة أمان المحتوى الصارمة (CSP)

Lukas Weichselbaum

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

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

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

المصطلح الأساسي: الرقم الخاص هو رقم عشوائي يُستخدم مرة واحدة فقط ويمكنك استخدامه لوضع علامة على علامة <script> بأنّها موثوقة.

المصطلح الأساسي: دالة التجزئة هي دالة رياضية تحوّل قيمة الإدخال إلى قيمة رقمية مضغوطة تُسمى التجزئة. يمكنك استخدام قيمة تجزئة (مثل SHA-256) لوضع علامة على علامة <script> مضمّنة باعتبارها موثوقة.

يُطلق على سياسة أمان المحتوى المستندة إلى أرقام عشوائية أو قيم تجزئة اسم سياسة أمان محتوى صارمة. عندما يستخدم أحد التطبيقات سياسة CSP صارمة، لا يمكن للمهاجمين الذين يعثرون على عيوب في حقن HTML استخدامها لإجبار المتصفّح على تنفيذ برامج نصية ضارة في مستند معرَّض للخطر. ويرجع ذلك إلى أنّ سياسة CSP الصارمة لا تسمح إلا بالنصوص البرمجية المجزأة أو النصوص البرمجية التي تتضمّن قيمة nonce الصحيحة التي تم إنشاؤها على الخادم، وبالتالي لا يمكن للمهاجمين تنفيذ النص البرمجي بدون معرفة قيمة nonce الصحيحة لاستجابة معيّنة.

لماذا يجب استخدام سياسة CSP صارمة؟

إذا كان موقعك الإلكتروني يتضمّن سياسة أمان محتوى مشابهة لما يلي: script-src www.googleapis.com، من المحتمل ألا تكون فعّالة ضدّ البرامج النصية من مواقع إلكترونية أخرى. يُطلق على هذا النوع من "سياسة أمان المحتوى" اسم "سياسة أمان المحتوى" الخاصة بالقائمة المسموح بها. وتتطلّب هذه الأنظمة الكثير من التخصيص ويمكن للمهاجمين تجاوزها.

تتجنّب سياسات CSP الصارمة المستندة إلى أرقام عشوائية أو تجزئات مشفّرة هذه المشاكل.

بنية CSP صارمة

تستخدم سياسة أمان المحتوى الأساسية الصارمة أحد عناوين استجابة HTTP التالية:

سياسة أمان المحتوى الصارمة المستندة إلى الأرقام العشوائية

Content-Security-Policy:
  script-src 'nonce-{RANDOM}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

سياسة أمان المحتوى الصارمة المستندة إلى التجزئة

Content-Security-Policy:
  script-src 'sha256-{HASHED_INLINE_SCRIPT}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

تجعل الخصائص التالية سياسة أمان المحتوى هذه "صارمة" وبالتالي آمنة:

• تستخدم هذه السياسة أرقامًا عشوائية 'nonce-{RANDOM}' أو قيم تجزئة 'sha256-{HASHED_INLINE_SCRIPT}' للإشارة إلى علامات <script> التي يثق بها مطوّر الموقع الإلكتروني لتنفيذها في متصفّح المستخدم.
• تضبط هذه السمة القيمة 'strict-dynamic' للحدّ من الجهد المطلوب لنشر سياسة CSP مستندة إلى nonce أو hash من خلال السماح تلقائيًا بتنفيذ النصوص البرمجية التي ينشئها نص برمجي موثوق به. يؤدي ذلك أيضًا إلى إتاحة استخدام معظم مكتبات JavaScript والأدوات التابعة لجهات خارجية.
• ولا يستند إلى قوائم السماح بعناوين URL، لذا لا يتأثر بأساليب تجاوز CSP الشائعة.
• يحظر هذا التوجيه النصوص البرمجية المضمّنة غير الموثوق بها، مثل معالجات الأحداث المضمّنة أو معرّفات الموارد المنتظمة (URI) الخاصة بعلامة javascript:.
• يتم حظر object-src لإيقاف المكوّنات الإضافية الخطيرة، مثل Flash.
• يقيّد هذا الإذن base-uri لمنع إدخال علامات <base>. ويمنع ذلك المهاجمين من تغيير مواقع البرامج النصية التي يتم تحميلها من عناوين URL نسبية.

استخدام سياسة أمان محتوى صارمة

لتبنّي سياسة CSP صارمة، عليك اتّخاذ الإجراءات التالية:

1. حدِّد ما إذا كان تطبيقك سيضبط سياسة CSP مستندة إلى nonce أو hash.
2. انسخ "سياسة أمان المحتوى" من قسم بنية "سياسة أمان المحتوى" الصارمة واضبطها كعنوان استجابة في تطبيقك.
3. أعِد هيكلة نماذج HTML والرمز البرمجي من جهة العميل لإزالة الأنماط غير المتوافقة مع سياسة أمان المحتوى (CSP).
4. تفعيل سياسة أمان المحتوى (CSP).

يمكنك استخدام تدقيق أفضل الممارسات في Lighthouse (الإصدار 7.3.0 والإصدارات الأحدث مع العلامة --preset=experimental) أفضل الممارسات خلال هذه العملية للتحقّق مما إذا كان موقعك الإلكتروني يتضمّن سياسة أمان المحتوى، وما إذا كانت صارمة بما يكفي لتكون فعّالة ضدّ هجمات البرمجة النصية على المواقع (XSS).

الخطوة 1: تحديد ما إذا كنت بحاجة إلى سياسة CSP مستندة إلى nonce أو hash

في ما يلي طريقة عمل نوعَي "سياسة أمان المحتوى" الصارمة:

سياسة أمان المحتوى المستندة إلى أرقام الاستخدام لمرة واحدة

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

استخدِم سياسة أمان المحتوى المستندة إلى الرقم العشوائي لصفحات HTML المعروضة على الخادم. بالنسبة إلى هذه الصفحات، يمكنك إنشاء رقم عشوائي جديد لكل ردّ.

سياسة أمان المحتوى المستندة إلى التجزئة

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

استخدِم سياسة أمان المحتوى المستندة إلى التجزئة لصفحات HTML التي يتم عرضها بشكل ثابت أو الصفحات التي يجب تخزينها مؤقتًا. على سبيل المثال، يمكنك استخدام سياسة أمان المحتوى المستندة إلى التجزئة لتطبيقات الويب ذات الصفحة الواحدة التي تم إنشاؤها باستخدام أُطر عمل مثل Angular أو React أو غيرها، والتي يتم عرضها بشكل ثابت بدون العرض من جهة الخادم.

الخطوة 2: ضبط سياسة صارمة لأمان المحتوى وإعداد النصوص البرمجية

عند ضبط سياسة أمان المحتوى، تتوفّر لك بعض الخيارات:

• وضع "التقارير فقط" (Content-Security-Policy-Report-Only) أو وضع "فرض السياسة" (Content-Security-Policy): في وضع "التقارير فقط"، لن تحظر سياسة CSP الموارد بعد، وبالتالي لن يحدث أي خلل في موقعك الإلكتروني، ولكن يمكنك الاطّلاع على الأخطاء وتلقّي التقارير بشأن أي محتوى كان سيتم حظره. عند ضبط CSP محليًا، لا يهم ذلك كثيرًا، لأنّ كلا الوضعين يعرضان لك الأخطاء في وحدة تحكّم المتصفح. في الواقع، يمكن أن يساعدك وضع التنفيذ في العثور على الموارد التي تحظرها مسودة "سياسة أمان المحتوى"، لأنّ حظر أحد الموارد قد يؤدي إلى ظهور صفحتك بشكل غير سليم. يصبح وضع "التقارير فقط" أكثر فائدةً في وقت لاحق من العملية (راجِع الخطوة 5).
• عنوان أو علامة <meta> في HTML بالنسبة إلى التطوير المحلي، يمكن أن تكون علامة <meta> أكثر ملاءمةً لتعديل سياسة أمان المحتوى والاطّلاع بسرعة على تأثيرها في موقعك الإلكتروني. ومع ذلك:
  • في وقت لاحق، عند نشر سياسة CSP في مرحلة الإنتاج، ننصحك بضبطها كعنوان HTTP.
  • إذا أردت ضبط سياسة أمان المحتوى في وضع "إعداد التقارير فقط"، عليك ضبطها كعنوان، لأنّ علامات CSP الوصفية لا تتيح وضع "إعداد التقارير فقط".

Content-Security-Policy:
  script-src 'nonce-{RANDOM}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

const app = express();

app.get('/', function(request, response) {
  // Generate a new random nonce value for every response.
  const nonce = crypto.randomBytes(16).toString("base64");

  // Set the strict nonce-based CSP response header
  const csp = `script-src 'nonce-${nonce}' 'strict-dynamic'; object-src 'none'; base-uri 'none';`;
  response<.set(&>quot;Content-Security-Policy", csp);

  // Every script tag in your application should set the `nonce` attribute to this value.
  response.render(template, { nonce: nonce });
});

الخيار (ب): عنوان استجابة "سياسة أمان المحتوى" المستند إلى التجزئة

اضبط عنوان استجابة Content-Security-Policy HTTP التالي في تطبيقك:

Content-Security-Policy:
  script-src 'sha256-{HASHED_INLINE_SCRIPT}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

بالنسبة إلى النصوص البرمجية المضمّنة المتعددة، يكون بناء الجملة على النحو التالي: 'sha256-{HASHED_INLINE_SCRIPT_1}' 'sha256-{HASHED_INLINE_SCRIPT_2}'.

تحميل النصوص البرمجية المستندة إلى مصادر بشكل ديناميكي

يمكنك تحميل النصوص البرمجية التابعة لجهات خارجية بشكل ديناميكي باستخدام نص برمجي مضمّن.

مسموح به من خلال سياسة أمان المحتوى

<script>
  var scripts = [ 'https://example.org/foo.js', 'https://example.org/bar.js'];

  scripts.forEach(function(scriptUrl) {
    var s = document.createElement('script');
    s.src = scriptUrl;
    s.async = false; // to preserve execution order
    document.hea<d.appen>dChild(s);
  });
/script

للسماح بتنفيذ هذا النص البرمجي، عليك احتساب قيمة التجزئة للنص البرمجي المضمّن وإضافتها إلى عنوان استجابة "سياسة أمان المحتوى"، مع استبدال العنصر النائب {HASHED_INLINE_SCRIPT}. لتقليل عدد التجزئات، يمكنك دمج جميع النصوص البرمجية المضمّنة في نص برمجي واحد. للاطّلاع على هذا الإجراء عمليًا، يُرجى الرجوع إلى هذا المثال ورمزه.

تم حظره بواسطة CSP

<script src="https://example.org/fo><o.js&qu>o<t;/script
script src="https://exam><ple.org>/bar.js"/script

تحظر سياسة أمان المحتوى هذه النصوص البرمجية لأنّها لم تتم إضافتها بشكلٍ ديناميكي وليس لديها السمة integrity التي تتطابق مع مصدر مسموح به.

ملاحظات حول تحميل النصوص البرمجية

يضيف مثال النص البرمجي المضمّن s.async = false للتأكّد من أنّ foo يتم تنفيذه قبل bar، حتى إذا تم تحميل bar أولاً. في هذا المقتطف، لا يؤدي s.async = false إلى حظر المحلّل أثناء تحميل النصوص البرمجية، لأنّه تتم إضافة النصوص البرمجية بشكل ديناميكي. يتوقف المحلّل فقط أثناء تنفيذ النصوص البرمجية، كما هو الحال مع نصوص async البرمجية. ومع ذلك، عند استخدام هذا المقتطف، يُرجى مراعاة ما يلي:

• قد يتم تنفيذ أحد النصين البرمجيين أو كليهما قبل أن ينتهي المستند من التنزيل. إذا أردت أن يكون المستند جاهزًا عند تنفيذ النصوص البرمجية، انتظِر حدث DOMContentLoaded قبل إلحاق النصوص البرمجية. إذا تسبّب ذلك في حدوث مشكلة في الأداء لأنّ النصوص البرمجية لا تبدأ التنزيل في وقت مبكر بما فيه الكفاية، استخدِم علامات التحميل المُسبَق في وقت مبكر من الصفحة.
• لا يؤدي defer = true أي إجراء. إذا كنت بحاجة إلى هذا السلوك، شغِّل النص البرمجي يدويًا عند الحاجة.

الخطوة 3: إعادة هيكلة نماذج HTML والرمز البرمجي من جهة العميل

يمكن استخدام معالجات الأحداث المضمّنة (مثل onclick="…" وonerror="…") ومعرّفات الموارد المنتظمة (URI) الخاصة بلغة JavaScript (<a href="javascript:…">) لتشغيل النصوص البرمجية. وهذا يعني أنّ المهاجم الذي يعثر على خطأ في البرمجة عبر المواقع يمكنه حقن هذا النوع من HTML وتنفيذ JavaScript ضار. تحظر سياسة CSP المستندة إلى nonce أو hash استخدام هذا النوع من الترميز. إذا كان موقعك الإلكتروني يستخدم أيًا من هذه الأنماط، عليك إعادة هيكلتها إلى بدائل أكثر أمانًا.

إذا فعّلت CSP في الخطوة السابقة، ستتمكّن من الاطّلاع على مخالفات CSP في وحدة التحكّم كلّما حظر CSP نمطًا غير متوافق.

في معظم الحالات، يكون الحل بسيطًا:

إعادة تصميم معالِجات الأحداث المضمّنة

<span id="th>ings&quo<t;A t>h<ing./span
script nonce=>"${nonce}"
  document.getElementById('things').addEventL<istener>('click', doThings);
/script

<span onclick="doThing>s();&quo<t;A t>hing./span

إعادة هيكلة معرّفات الموارد المنتظمة (URI) javascript:

<a id=">;fo<o&>q<uot;foo/a
script nonce=>"${nonce}"
  document.getElementById('foo').addEventList<ener(&#>39;click', linkClicked);
/script

<a href="javascript:linkClick>ed(<)&>quot;foo/a

إزالة eval() من JavaScript

إذا كان تطبيقك يستخدم eval() لتحويل عمليات نشر سلاسل JSON على نحو متسلسِل إلى عناصر JS، عليك إعادة هيكلة هذه الأمثلة إلى JSON.parse()، وهي أيضًا أسرع.

إذا تعذّر عليك إزالة جميع استخدامات eval()، سيظل بإمكانك ضبط سياسة أمان محتوى (CSP) صارمة تستند إلى الأرقام العشوائية، ولكن عليك استخدام الكلمة الرئيسية 'unsafe-eval' في سياسة أمان المحتوى، ما يجعل سياستك أقل أمانًا بعض الشيء.

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

الخطوة 4 (اختيارية): إضافة خيارات احتياطية لتوفير التوافق مع الإصدارات القديمة من المتصفّحات

إذا كنت بحاجة إلى توفير التوافق مع إصدارات المتصفّح القديمة، اتّبِع الخطوات التالية:

• يتطلّب استخدام strict-dynamic إضافة https: كإعداد احتياطي للإصدارات السابقة من Safari. عند إجراء ذلك:
  • تتجاهل جميع المتصفّحات التي تتوافق مع strict-dynamic خيار https: الاحتياطي، لذلك لن يؤدي ذلك إلى تقليل قوة السياسة.
  • في المتصفحات القديمة، لا يمكن تحميل النصوص البرمجية من مصادر خارجية إلا إذا كانت من مصدر HTTPS. هذه السياسة أقل أمانًا من سياسة CSP الصارمة، ولكنها لا تزال تمنع بعض الأسباب الشائعة لهجمات XSS، مثل عمليات إدخال معرّفات الموارد المنتظمة (URI) الخاصة بـ javascript:.
• لضمان التوافق مع إصدارات المتصفّح القديمة جدًا (أكثر من 4 سنوات)، يمكنك إضافة unsafe-inline كخيار احتياطي. تتجاهل جميع المتصفّحات الحديثة unsafe-inline في حال توفّر رقم خاص أو تجزئة لسياسة أمان المحتوى.

Content-Security-Policy:
  script-src 'nonce-{random}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 9;none';
  base-uri 'none';

الخطوة 5: تفعيل سياسة أمان المحتوى

بعد التأكّد من أنّ سياسة أمان المحتوى لا تحظر أي نصوص برمجية صالحة في بيئة التطوير المحلية، يمكنك نشر سياسة أمان المحتوى في بيئة الاختبار، ثم في بيئة الإنتاج:

1. (اختياري) يمكنك نشر سياسة أمان المحتوى في وضع إعداد التقارير فقط باستخدام العنوان Content-Security-Policy-Report-Only. يُعدّ وضع "إعداد التقارير فقط" مفيدًا لاختبار تغيير محتمل قد يؤدي إلى حدوث مشاكل، مثل سياسة جديدة لأمان المحتوى في مرحلة الإنتاج، قبل البدء في فرض قيود سياسة أمان المحتوى. في "وضع التقارير فقط"، لا تؤثّر سياسة أمان المحتوى في سلوك تطبيقك، ولكن يظل المتصفّح يعرض أخطاء في وحدة التحكّم ويُنشئ تقارير عن المخالفات عند رصد أنماط غير متوافقة مع سياسة أمان المحتوى، ما يتيح لك معرفة المشاكل التي كان سيواجهها المستخدمون النهائيون. لمزيد من المعلومات، يُرجى الاطّلاع على Reporting API.
2. عندما تكون واثقًا من أنّ سياسة أمان المحتوى لن تؤدي إلى تعطيل موقعك الإلكتروني للمستخدمين النهائيين، يمكنك نشر سياسة أمان المحتوى باستخدام عنوان استجابة Content-Security-Policy. ننصحك بضبط سياسة أمان المحتوى باستخدام عنوان HTTP من جهة الخادم لأنّ ذلك أكثر أمانًا من استخدام علامة <meta>. بعد إكمال هذه الخطوة، سيبدأ موفّر خدمة السحابة الإلكترونية في حماية تطبيقك من هجمات البرمجة النصية على المواقع (XSS).

القيود

توفّر سياسة أمان المحتوى الصارمة بشكل عام طبقة أمان إضافية قوية تساعد في الحدّ من هجمات النصوص البرمجية على المواقع الإلكترونية (XSS). في معظم الحالات، تقلّل سياسة أمان المحتوى (CSP) من مساحة الهجوم بشكل كبير من خلال رفض الأنماط الخطيرة، مثل javascript: URI. ومع ذلك، استنادًا إلى نوع سياسة أمان المحتوى (CSP) التي تستخدمها (الأرقام الخاصة أو أجزاء التجزئة أو مع 'strict-dynamic' أو بدونها)، هناك حالات لا توفّر فيها سياسة أمان المحتوى الحماية الكافية لتطبيقك، وهي:

• إذا أضفت قيمة nonce إلى نص برمجي، ولكن تم إدخال محتوى مباشرةً في نص الرسالة أو في المَعلمة src الخاصة بعنصر <script>.
• إذا كانت هناك عمليات إدخال في مواضع النصوص البرمجية التي يتم إنشاؤها ديناميكيًا (document.createElement('script'))، بما في ذلك أي دوال مكتبة تنشئ عقد script DOM استنادًا إلى قيم وسيطاتها. ويشمل ذلك بعض واجهات برمجة التطبيقات الشائعة، مثل .html() في jQuery، بالإضافة إلى .get() و.post() في jQuery < 3.0.
• إذا كانت هناك عمليات إدخال نماذج في تطبيقات AngularJS القديمة يمكن للمهاجم الذي يمكنه إدخال بيانات في نموذج AngularJS استخدام هذا النموذج من أجل تنفيذ رمز JavaScript عشوائي.
• إذا كانت السياسة تتضمّن 'unsafe-eval'، سيتم إدخال البيانات في eval() وsetTimeout() وبعض واجهات برمجة التطبيقات الأخرى التي نادرًا ما يتم استخدامها.

على المطوّرين ومهندسي الأمان إيلاء اهتمام خاص لهذه الأنماط أثناء مراجعات الرموز البرمجية وعمليات تدقيق الأمان. يمكنك العثور على مزيد من التفاصيل حول هذه الحالات في سياسة أمان المحتوى: A Successful Mess Between Hardening and Mitigation.

محتوى إضافي للقراءة

• انتهت صلاحية سياسة أمان المحتوى، ولكنّها ستستمرّ حول عدم أمان القوائم البيضاء ومستقبل "سياسة أمان المحتوى"
• أداة تقييم CSP
• مؤتمر LocoMoco: سياسة أمان المحتوى - مزيج ناجح بين تعزيز الأمان والحدّ من المخاطر
• جلسة Google I/O: تأمين تطبيقات الويب باستخدام ميزات المنصات الحديثة