الأمن السيبراني

شرح ترويسات أمان HTTP: HSTS وCSP وnosniff وReferrer-Policy وframe-ancestors في Nginx وApache

ست ترويسات استجابة تجعل المتصفح يفرض HTTPS ويمنع الاحتيال بالإطارات ويحد من حقن السكربتات، مع إعدادات Nginx وApache وطريقة آمنة لتطبيق CSP.

تاريخ النشر
مدة القراءة
6 دقائق
الكاتب
SKYLINE Engineering

هناك مجموعة صغيرة من ترويسات استجابة HTTP تطلب من المتصفح تطبيق حماية إضافية على موقعك: استخدام HTTPS دائماً، ورفض عرض الموقع داخل إطارات مواقع أخرى، والتوقف عن تخمين نوع المحتوى، وإرسال بيانات أقل عن الصفحة المُحيلة، وتقييد المصادر التي تُحمَّل منها السكربتات. إرسالها لا يكلف شيئاً، لكن اثنتين منها (HSTS وCSP) قد تمنعان المستخدمين من الوصول أو تكسران الصفحات إذا طُبقتا دون تخطيط.

تتبع التعريفات أدناه صفحات المرجع في MDN Web Docs المذكورة في كل قسم.

Strict-Transport-Security (HSTS)

تطلب ترويسة HSTS من المتصفح استخدام HTTPS فقط مع مضيفك من الآن فصاعداً، وترقية أي طلب http:// لاحق تلقائياً. القيمة max-age هي عدد الثواني التي يتذكر فيها المتصفح ذلك، وincludeSubDomains يمدها إلى كل النطاقات الفرعية، وmax-age=0 يلغيها.

Strict-Transport-Security: max-age=63072000; includeSubDomains

ارفع القيمة تدريجياً بدلاً من البدء بسنتين. يقترح موقع HSTS preload مراحل تبدأ بـmax-age=300 ثم 604800 (أسبوع) ثم 2592000 (شهر)، مع فحص الصفحات المعطلة في كل مرحلة وانتظار المدة كاملة قبل الانتقال إلى التالية. ولا تستخدم includeSubDomains إلا بعد التأكد من عمل كل نطاق فرعي عبر HTTPS، بما في ذلك الأدوات الداخلية وأسماء المضيفين القديمة.

أما الإدراج المسبق (إضافة preload وتقديم النطاق ليُضمَّن في المتصفحات) فيتطلب max-age لا تقل عن سنة، وincludeSubDomains، وتحويلاً من HTTP إلى HTTPS على المضيف نفسه. ويحذّر موقع الإدراج من أن الإدخالات الجديدة تحتاج أشهراً لتصل إلى نسخة Chrome المستقرة، وأن الإزالة بطيئة، وأن أدوات الإعداد لا ينبغي أن تضيف preload افتراضياً. اعتبره قراراً باتجاه واحد.

X-Content-Type-Options

X-Content-Type-Options: nosniff

مع nosniff يحجب المتصفح السكربت الذي لا يحمل نوع MIME خاصاً بـJavaScript، وملف التنسيق الذي ليس text/css، ولن يعرض استجابة text/plain على أنها HTML. تأكد من أن خادمك يرسل ترويسات Content-Type صحيحة قبل التفعيل.

Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin

هذه هي السياسة الافتراضية في المتصفح عند عدم تحديد سياسة، بحسب MDN: الرابط الكامل للطلبات من الأصل نفسه، والأصل فقط للطلبات إلى أصول أخرى، ولا شيء عند الانتقال من HTTPS إلى HTTP. تحديدها صراحةً يوثّق اختيارك، واستخدم no-referrer أو same-origin إذا كانت روابط موقعك قد تحتوي على رموز دخول أو بيانات شخصية.

Permissions-Policy

Permissions-Policy: camera=(), microphone=(), geolocation=()

القائمة الفارغة () تعطل الميزة للصفحة ولكل إطار مضمَّن فيها. اذكر فقط الميزات التي تعرف أنك لا تستخدمها. وتصف MDN ترويسة Permissions-Policy بأنها محدودة التوفر، إذ لا تدعمها كل المتصفحات الرئيسية، فاعتبرها طبقة إضافية لا ضماناً.

الاحتيال بالإطارات: frame-ancestors وX-Frame-Options

يتحكم توجيه CSP المسمى frame-ancestors في المواقع المسموح لها بتضمين صفحاتك داخل إطار. القيمة 'none' تمنع كل التضمين، و'self' تسمح لأصلك فقط. ولا يعمل داخل وسم <meta> بل كترويسة فقط. أما الترويسة الأقدم X-Frame-Options: DENY أو SAMEORIGIN فتؤدي المهمة نفسها بخيارات أقل، وكثير من المواقع ترسل الاثنتين.

Content-Security-Policy مع البدء بوضع التقارير فقط

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

ابدأ بـContent-Security-Policy-Report-Only، حيث لا يفرض المتصفح شيئاً لكنه يبلّغ عن كل مخالفة إلى نقطة استقبال تحددها:

Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports"
Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'none'; frame-ancestors 'self'; report-to csp-endpoint; report-uri /csp-reports

تذكر MDN أن report-to هو المفضل وأن report-uri مهمل، لكن ذكر الاثنين مفيد ما دام دعم report-to غير مكتمل. اجمع التقارير بضعة أسابيع، وأضف المصادر التي تحتاجها فعلاً، ثم أرسل السياسة نفسها باسم Content-Security-Policy.

تجنّب 'unsafe-inline' للسكربتات، إذ تصفه MDN بأنه يُفقد CSP جزءاً كبيراً من غايتها. والنهج الموصى به هو "CSP صارمة" تستخدم قيمة nonce عشوائية لكل استجابة على كل وسم سكربت (script-src 'nonce-...')، وهو ما يحتاج دعماً من تطبيقك أو إطار العمل.

إعدادات Nginx وApache

في Nginx داخل كتلة server، ويضيف الخيار always الترويسات إلى استجابات الأخطاء أيضاً:

add_header Strict-Transport-Security "max-age=2592000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "frame-ancestors 'self'" always;

انتبه لفخ مهم: تقول وثائق Nginx إن توجيهات add_header تُورَث من المستوى الأعلى فقط إذا لم يُعرَّف أي منها في المستوى الحالي. أي أن توجيه add_header واحداً داخل كتلة location يُسقط بصمت كل ترويسات مستوى الخادم لذلك المسار. ضع الترويسات في ملف مستقل وضمّنه بـinclude أينما أضفت ترويسات أخرى.

أما Apache فيحتاج الوحدة mod_headers (sudo a2enmod headers):

Header always set Strict-Transport-Security "max-age=2592000; includeSubDomains"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set Content-Security-Policy "frame-ancestors 'self'"

تحقق مما يُرسل فعلاً:

curl -sI https://example.com | grep -i -E 'strict-transport|content-security|x-content-type|referrer-policy|permissions-policy|x-frame'

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

ما الذي ينبغي فعله

  • أضف X-Content-Type-Options وReferrer-Policy وframe-ancestors الآن، فنادراً ما تكسر شيئاً.
  • ارفع HSTS على مراحل، ولا تضف includeSubDomains أو preload إلا بعد جاهزية كل النطاقات الفرعية لـHTTPS.
  • طبّق CSP بوضع التقارير فقط أولاً، واجمع التقارير، ثم افرضها، واتجه إلى nonce بدلاً من 'unsafe-inline'.
  • في Nginx راقب وراثة add_header داخل كتل location.
  • تحقق بـcurl -sI بعد كل تغيير.

المصادر

SKYLINE Engineering

@skyline

The engineering team at SKYLINE Industrial Solutions. We publish field-tested guides drawn from real KSA and GCC deployments.

صفحة الكاتب
SKYLINE engineering services

Need this implemented for you?

Reading is free — building it right takes a team. SKYLINE engineers ship Cybersecurity for Aramco vendors, banks, hospitals and government agencies across Saudi Arabia. Talk to us before you start.

Aramco Approved Contractor ISO 9001 · ISO 27001 SAMA CSF aligned NCA ECC ready 247+ KSA clients

Comments

0 total · 0 threads
Be the first to leave a comment.