تكوين رؤوس أمان HTTP على ووردبريس
نشرت: 2022-02-23تدعم معظم المتصفحات الحديثة مجموعة متنوعة من رؤوس أمان HTTP لتحسين أمان موقع WordPress الخاص بك ، وحماية زوارك بشكل أفضل من فئات هجمات المستعرض مثل النقر ، والبرمجة عبر المواقع ، والهجمات الشائعة الأخرى ، وحتى تحسين خصوصية زوار موقعك عبر الانترنت.
تقدم هذه المقالة نظرة عامة على ماهية رؤوس أمان HTTP هذه ، وتشرح كيفية عملها وما هو نطاقها. يشرح أيضًا كيف يمكنك إضافة رؤوس أمان HTTP هذه إلى موقع الويب الخاص بك لتحسين أمان موقع WordPress الخاص بك.
ما هو رأس أمان HTTP على أي حال؟
رؤوس أمان HTTP هي سلسلة من رؤوس HTTP 1 يتم تبادلها بين عميل الويب (المستعرض) وخادم الويب التي تُستخدم لتحديد الإعدادات المتعلقة بالأمان لاتصالات HTTP بين عميل الويب والخادم. يمكن أن يؤدي تمكين رؤوس الأمان على موقع WordPress الخاص بك إلى تحسين مرونة موقع الويب الخاص بك ضد الهجمات الشائعة ، بما في ذلك البرمجة النصية عبر المواقع (XSS) و clickjacking.
كيف يمكن لرؤوس أمان HTTP تحسين أمان WordPress
يمكن أن تساعد رؤوس أمان HTTP في تحسين أمان موقع WordPress الخاص بك عن طريق توجيه المتصفح لتمكين مجموعة متنوعة من ميزات الأمان وفقًا لذلك. في كثير من الحالات ، يعد تنفيذ الرؤوس الصحيحة أمرًا صعبًا وقد يكون له نتائج مختلفة (أو يكون غير فعال تمامًا) في المتصفحات القديمة ، لذلك فمن الأفضل تجربة أي تغييرات في بيئة الاختبار أو التدريج قبل تطبيق أي تغييرات على موقع WordPress مباشر.
أكثر رؤوس أمان HTTP شيوعًا
أي رؤوس تفعل ماذا؟ دعنا نتعمق في نظرة عامة على بعض رؤوس أمان HTTP الأكثر أهمية والأكثر استخدامًا.
أمن النقل الصارم
يقوم رأس HTTP Strict-Transport-Security بتوجيه المتصفح لفرض أمان نقل HTTP الصارم (HSTS) 2 . يوجه رأس HSTS المتصفح الزائر للوصول دائمًا إلى الموقع عبر HTTPS (بدلاً من HTTP) ، حتى إذا حاول المستخدم (أو مهاجم يحاول تشغيل هجوم Man-in-the-Middle) الوصول إلى الموقع عبر HTTP ، سيتحول المتصفح قسرًا إلى HTTPS ، حتى إذا كان HTTP غير متاح - إلى حد ما ، يجب عليك فقط تمكين HSTS إذا كان لديك HTTPS ممكّنًا ويعمل بشكل كامل دون مشاكل المحتوى المختلط 3 .
يتيح رأس استجابة HTTP لأمان النقل الصارم HTTP (HSTS) التالي HSTS لمدة عام واحد (31536000 ثانية).
Strict-Transport-Security: max-age=31536000
سياسة أمن المحتوى
رأس أمان HTTP Content-Security-Policy هو رأس HTTP يتمتع بقدر كبير من القوة وقابلية التكوين. يقوم بتكوين سياسة أمان المحتوى (CSP) الخاصة بالمستعرض وهي مجموعة من ميزات الأمان الموجودة في المتصفحات الحديثة والتي توفر طبقة إضافية من الأمان تساعد على اكتشاف وتخفيف الهجمات مثل البرمجة النصية عبر المواقع (XSS) وهجمات حقن البيانات.
من المعروف أيضًا أن سياسة أمان المحتوى (CSP) صعبة للغاية لأن إعدادات CSP الصحيحة ستعتمد على نطاق واسع جدًا على موقع الويب المعني ، ويجب اختبارها بشدة قبل النشر - إلى حد كبير ، لديها سياسة أمان المحتوى الشقيقة -تقرير فقط 4 يستخدم رأس HTTP فقط لاختبار CSP.
فيما يلي مثال على سياسة سياسة أمان المحتوى (CSP) البسيطة جدًا التي تسمح فقط بتحميل الأصول من الأصل الذي يتم تقديم موقع الويب منه.
Content-Security-Policy: default-src 'self'
ومع ذلك ، فإن سياسة أمان المحتوى (CSP) قابلة للتكوين بشكل أكبر مما هو موضح في هذا المثال البسيط. يتضمن CSP توجيهات أخرى مثل script-src و style-src و img-src لتحديد المصادر التي قد يقوم المستعرض بتحميل الأصول منها (على سبيل المثال CSS والصور والخطوط). للحصول على قائمة كاملة بكيفية تكوين CSP ، راجع الإرشادات المرجعية السريعة لسياسة أمان المحتوى.
X- نوع المحتوى- خيارات
رأس أمان HTTP من نوع X-Content-Type-Options هو رأس غير قياسي تحترمه جميع المتصفحات الرئيسية ويمنع هجمات البرمجة النصية عبر المواقع (XSS) التي تنتج عن استنشاق نوع MIME 5 . عند وجوده ، يخبر هذا العنوان المتصفح باتباع أنواع MIME المحددة في رأس HTTP من نوع المحتوى ، وأن المتصفح لا يجب أن يحاول اكتشاف نوع MIME الصحيح لبيانات الاستجابة نفسها. يحتوي الرأس على توجيه واحد - nosniff.
X-Content-Type-Options: nosniff
رؤوس أمان HTTP القديمة أو غير المستخدمة
هناك أيضًا عدد من رؤوس أمان HTTP القديمة وغير المستخدمة. لم تعد مستخدمة أو لم تعد تعمل لأنها إما مقدمة كإصلاحات مؤقتة أو تجارب أو حتى مبادرات غير قياسية تم إهمالها أو استبدالها بالكامل منذ ذلك الحين. فيما يلي قائمة برؤوس أمان HTTP هذه.
تم استبدال رؤوس أمان HTTP بسياسة أمان المحتوى
X- خيارات الإطار
إن رأس أمان HTTP X-Frame-Options هو رأس مهمل الآن تم تقديمه لأول مرة بواسطة Microsoft Internet Explorer (واعتمدته متصفحات أخرى بدرجات متفاوتة من التوحيد والتوافق) لحماية المتصفحات من البرمجة النصية عبر المواقع (XSS) و Clickjacking و الهجمات الأخرى التي تعتمد على موقع ويب يتم وضعه داخل إطار iframe.
تم استبدال هذا العنوان الآن بتوجيه سياسة أمان المحتوى (CSP) من أسلاف الإطار. يُنصح باستخدام CSP مع توجيه أسلاف الإطار بدلاً من X-Frame-Options.
حماية X-XSS
كان رأس أمان X-XSS-Protection HTTP عبارة عن رأس غير قياسي تم تقديمه لتمكين أو تعطيل حماية المتصفح ضد هجمات البرمجة النصية عبر المواقع (XSS). من الناحية العملية ، كان من السهل على المهاجمين تجاوز هذا العنوان ونتيجة لذلك يتم تجاهله من قبل معظم المتصفحات الحديثة نتيجة لذلك.
العامة-دبابيس المفاتيح
يستخدم رأس أمان HTTP Public-Key-Pins لتكوين ميزة أمان تثبيت المفتاح العام (HPKP) التي تم تقديمها في Google Chrome و Firefox لمنع انتحال شهادة TLS. عمل HPKP من خلال جعل خادم الويب يزود المتصفح بمجموعة من تجزئات التشفير للمفاتيح العامة لشهادة TLS التي يستخدمها موقع الويب ، والتي يستخدمها المتصفح بدوره للمقارنة مع الشهادات التي يتلقاها من الخادم في الطلبات اللاحقة. تكمن المشكلة في أن HPKP كان معقدًا إلى حد ما في إدارته وكثيرًا ما أدى إلى تكوينات خاطئة يمكن أن تعطل الوصول إلى موقع الويب تمامًا - على هذا النحو ، لم يعد من المستحسن استخدامه.
إضافة رؤوس أمان HTTP في ووردبريس
تعمل رؤوس أمان HTTP بشكل أفضل عندما يتم تكوينها على خادم الويب الخاص بك أو ، عند الاقتضاء ، شبكة توصيل المحتوى (CDN) أو جدار حماية تطبيق الويب. هذا يسمح لهم بإرسالها عند كل طلب. بدلاً من ذلك ، بينما أقل مثالية ، يمكنك استخدام مكون WordPress الإضافي لتعيين هذه الرؤوس لك.
الآن بعد أن غطينا الغرض من رؤوس أمان HTTP ، إليك بعض الطرق التي يمكن من خلالها تمكينها على موقع WordPress الخاص بك.
إضافة رؤوس أمان HTTP في WordPress باستخدام خادم Apache HTTP
فيما يلي مثال لتكوين خادم Apache HTTP المطلوب لتمكين أمان نقل HTTP الصارم (HSTS) وخيارات نوع المحتوى X وسياسة أمان المحتوى البسيطة.
<ifModule mod_headers.c> Header set Strict-Transport-Security "max-age=31536000" Header set X-Content-Type-Options "nosniff" Header set Content-Security-Policy "default-src 'self'" </ifModule>
إضافة رؤوس أمان HTTP في WordPress باستخدام Nginx
وبالمثل ، ما يلي هو مثال على تكوين Nginx المطلوب لتمكين HTTP Strict Transport Security (HSTS) و X-Content-Type-Options وسياسة أمان المحتوى البسيطة.
server { add_header Strict-Transport-Security "max-age=31536000; always; add_header X-Content-Type-Options "nosniff" always; add_header Content-Security-Policy "default-src 'self'" always; }
إضافة رؤوس أمان HTTP في WordPress باستخدام مكون إضافي
بدلاً من ذلك ، في حين أنه أقل فاعلية (نظرًا لأنه يعتمد على WordPress نفسه لتعديل الرؤوس) ، فإن استخدام مكون WordPress الإضافي قد يكون أسهل طريقة لإضافة رؤوس أمان HTTP إلى موقع WordPress الخاص بك. تسمح لك المكونات الإضافية مثل المكون الإضافي Redirection بإضافة رؤوس HTTP مخصصة إلى موقع الويب الخاص بك.
كيفية التحقق من رؤوس أمان HTTP لموقع ويب
بمجرد إضافة رؤوس أمان HTTP على موقع WordPress الخاص بك ، فأنت تريد التأكد من تهيئتها بشكل صحيح ومن أنها تعمل بالشكل الذي تتوقعه منهم. أسهل طريقة لاختبار ذلك هي استخدام أداة مجانية تسمى Security Headers 6 .
يعد استخدام أداة Security Headers أمرًا بسيطًا مثل إدخال عنوان URL لموقع الويب الخاص بك والضغط على "Scan". ستحصل بعد ذلك على درجة من A + إلى F مع شرح لكيفية تحديد هذه الدرجة.
المراجع المستخدمة في هذه المقالة
↑ 1 | https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers |
---|---|
↑ 2 | https://owasp.org/www-project-secure-headers/#http-strict-transport-security |
↑ 3 | https://web.dev/what-is-mixed-content/ |
↑ 4 | https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy-Report-Only |
↑ 5 | https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#mime_sniffing |
↑ 6 | https://securityheaders.com/ |