أمان نقل بروتوكول نقل النص الفائق الصارم

**أمان النقل الصارم لـ HTTP** ( **HSTS** )هو آلية سياسة تساعد في حماية مواقع الويب من هجمات الوسيط مثل هجمات خفض مستوى البروتوكول  واختطاف ملفات تعريف الارتباط . وتسمح هذه الآلية لخوادم الويب بالإعلان أن متصفحات الويب (أو غيرها من عملاء المستخدم المتوافقين) يجب أن تتفاعل معها تلقائيًا باستخدام اتصالات HTTPS فقط، التي توفر أمان طبقة النقل (TLS/SSL)، على عكس HTTP غير الآمن المستخدم بمفرده. HSTS هو بروتوكول ضمن مسار معايير IETF ومحدد في .

يتم إرسال سياسة HSTS من الخادم إلى وكيل المستخدم عبر حقل ترويسة استجابة HTTP يُسمى `` . تُحدد سياسة HSTS فترة زمنية يَجب خِلالها على وكيل المستخدم الوصول إلى الخادم بطريقة آمنة فقط. [ 2 ] : §5.2 غالبًا ما لا تقبل المواقع الويب التي تستخدم HSTS النص العادي HTTP الواضح، إما عن طريق رفض الاتصالات عبر HTTP أو عن طريق إعادة توجيه المستخدمين بشكل منهجي إلى HTTPS (على الرغم من أن هذا غير مطلوب من قبل المواصفة). ونتيجة لذلك، فإن وكيل المستخدم غير القادر على تنفيذ TLS لن يَكون قَادِرًا على الاتصال بالموقع.

تنطبق الحماية فقط أن يكون المستخدم قد زار الموقع مرة واحدة على الأقل، بالاعتماد على مبدأ " الثقة عند الاستخدام الأول ". وتعمل هذه الحماية من خلال أنه عندما يُدخل المستخدم عنوان URL HTTP (وليس HTTPS) إلى الموقع أو تحديده، سيقوم العميل، مثل متصفح الويب، بالترقية تلقائيًا إلى HTTPS دون إجراء طلب HTTP، وبالتالي منع حدوث أي هجوم HTTP man-in-the-middle.

## تاريخ المواصفات
نُشرت مواصفة HSTS كـ  في 19 نوفمبر 2012 بعد أن تمت موافقة عليها في 2 أكتوبر 2012 من قبل IESG لنشرها كمواصفة مقترحة RFC . وقد قدم المؤلفون المواصفة في الأصل كمسودة الإنترنت في 17 يونيو/حزيران 2010. ومع تحويلها إلى مسودة إنترنت، تم تعديل اسم المواصفة من "أمان النقل الصارم" (STS) إلى "أمان النقل الصارم HTTP"، لأن المواصفة تنطبق فقط على HTTP . ومع ذلك، فإن حقل ترويسة استجابة HTTP المحدد في مواصفة HSTS لا يزال يحمل الاسم "Strict-Transport-Security".

آخر ما يُسمى "نسخة المجتمع" من المواصفة التي كانت تُعرف آنذاك باسم "STS" نُشرت في 18 ديسمبر 2009، مع مراجعات استنادًا إلى ملاحظات المجتمع.

نُشرت المسودة الأصلية للمواصفة من قبل جيف هودجز من شركة PayPal ، وكولين جاكسون، وآدم بارث في 18 سبتمبر 2009.

تستند مواصفة HSTS إلى عمل أصلي قام به جاكسون وبارث كما هو موصوف في ورقتهما البحثية "ForceHTTPS: حماية مواقع الويب عالية الأمان من هجمات الشبكة".

بالإضافة إلى ذلك، تُعد HSTS تحقيقًا لجانب واحد من رؤية شاملة لتحسين أمان الويب، قدمها جيف هودجز وآندي ستينجروبل في ورقتهما لعام 2010 بعنوان" *الحاجة إلى إطار عمل متماسك لسياسة أمان الويب"* .

## نظرة عامة على آلية HSTS
يقوم الخادم بتنفيذ سياسة HSTS عن طريق إرسال ترويسة عبر اتصال HTTPS (ترويسات HSTS عبر HTTP يتم تجاهلها). على سبيل المثال، يمكن للخادم إرسال ترويسة تجعل الطلبات المستقبلية إلى المجال للعام القادم (يتم تحديد الحد الأقصى للعمر بالثواني؛ 31,536,000 يساوي سنة واحدة غير كبيسة) HTTPS فقط: `Strict-Transport-Security: max-age=31536000` .

عندما تصدر تطبيق ويب سياسة HSTS لوكلاء المستخدم، يتصرف وكلاء المستخدم المتوافقون كم يلي:

# تحويل أي روابط غير آمنة تشير إلى تطبيق الويب تلقائيًا إلى روابط آمنة (على سبيل المثال، سيتم تعديل `` إلى ``  قبل الوصول إلى الخادم).
# إذا تعذر ضمان أمان الاتصال (مثل عدم ثقة بشهادة TLS الخاصة بالخادم)، يجب على وكيل المستخدم إنهاء الاتصال ولا ينبغي له السماح للمستخدم بالوصول إلى تطبيق الويب. [ 2 ] : §12.1 

تساعد سياسة HSTS في حماية مستخدمي تطبيقات الويب من بعض الهجمات الشبكية السلبية ( التنصت ) والنشطة. [ 2 ] : §2.4 قدرة المهاجم الذي يقوم بهجوم رجل في الوسط على اعتراض الطلبات والاستجابات بين المستخدم وخادم تطبيق الويب تقل بشكل كبير أثناء تفعيل سياسة HSTS في متصفح المستخدم لذلك التطبيق.

## قابلية التطبيق
أهم ثغرة أمنية يمكن لـ HSTS إصلاحها هي هجمات رجل في الوسط التي تُعرف بـ SSL، والتي قدمها علنًا Moxie Marlinspike في محاضرته BlackHat Federal عام 2009 بعنوان "حيل جديدة لهزيمة SSL في التطبيق العملي". تعمل هجمة إزالة تشفير SSL (و TLS ) عن طريق تحويل اتصال HTTPS الآمن بشكل شفاف إلى اتصال HTTP عادي. يمكن للمستخدم رؤية أن الاتصال غير آمن، لكن الأهم أنه لا توجد طريقة لمعرفة ما إذا كان يجب أن يكون الاتصال آمنًا أم لا. في وقت محاضرة Marlinspike، لم تكن العديد من المواقع الإلكترونية تستخدم TLS/SSL،لذلك لم يكن وسيلة لمعرفة (دون معرفة مسبقة) ما إذا كان استخدام HTTP العادي ناتجًا عن هجوم، أو ببساطة لأن الموقع الإلكتروني لم يطبق TLS/SSL. بالإضافة إلى ذلك، لا يتم تقديم أي تحذيرات للمستخدم أثناء عملية تخفيض الإصدار، مما يجعل الهجوم خفيًا إلى حد ما بالنسبة للجميع باستثناء الأكثر يقظة. أداة sslstrip من Marlinspike تقوم بأتمتة الهجوم بالكامل.&#x5B; *[[ويكيبيديا:بحاجة لمصدر|<span title="This claim needs references to reliable sources. (July 2020)">بحاجة لمصدر</span>]]* &#x5D;

تعالج HSTS هذه المشكلة بإبلاغ المتصفح بأن الاتصالات بالموقع يجب أن تستخدم دائمًا TLS/SSL. يمكن للمهاجم إزالة ترويسة HSTS إذا كانت هذه هي أول زيارة للمستخدم. تحاول متصفحات Google Chrome وMozilla Firefox وInternet Explorer وMicrosoft Edge الحد من هذه المشكلة من خلال تضمين قائمة "مُحمّلة مسبقًا" لمواقع HSTS. للأسف، لا يمكن لهذا الحل أن يشمل جميع مواقع على الإنترنت. انظر القيود أدناه.

يمكن أن تساعد HSTS أيضًا في منع سرقة بيانات تسجيل الدخول المعتمدة على ملفات تعريف الارتباط باستخدام أدوات منتشرة على نطاق واسع مثل Firesheep .

نظرًا لأن HSTS محددة بزمن، فهي حساسة للهجمات التي تتضمن تغيير وقت جهاز الضحية، مثل استخدام حزم NTP الزائفة.

## القيود
يظل الطلب الأول غير محمي من الهجمات النشطة إذا استخدم بروتوكولًا غير آمن مثل HTTP العادي أو إذا تم الحصول على عنوان URI للطلب الأول عبر قناة غير آمنة . [ 2 ] : §14.6 وينطبق الأمر نفسه على الطلب الأول بعد فترة النشاط المحددة في قيمة `` في سياسة HSTS (ينبغي على المواقع تعيين لعدة أيام أو أشهر حسب نشاط وسلوك المستخدم).

### الحلول مع قائمة التحميل المسبق
يعالج كل من Google Chrome وMozilla Firefox وInternet Explorer / Microsoft Edge هذا القيد من خلال تنفيذ "قائمة HSTS المحمّلة مسبقًا"، وهي قائمة تحتوي على مواقع معروفة تدعم HSTS. يتم توزيع هذه القائمة مع المتصفح بحيث يستخدم HTTPS للطلب الأول إلى المواقع المدرجة أيضًا. كما ذُكر سابقًا، لا يمكن أن تتوسع هذه القوائم المحمّلة مسبقًا لتشمل كامل الويب. وقد يتم تحقيق حل محتمل من خلال استخدام سجلات DNS لإعلان عن سياسة HSTS، والوصول إليها بشكل آمن عبر DNSSEC ، مع إمكانية استخدام بصمات الشهادات للتحقق من الصلاحية (وهذا يتطلب تشغيل مُحلل تحقق لتجنب مشكلات الميل الأخير ).

أشار جوناد علي إلى أن HSTS غير فعالة ضد استخدام النطاقات الزائفة؛ فمن خلال استخدام هجمات تعتمد على DNS، من الممكن لمهاجم رجل في الوسط أن يقدم حركة المرور من نطاق وهمي لا يوجد في قائمة HSTS المحمّلة مسبقًا،  ويمكن تحقيق ذلك من خلال هجمات انتحال DNS،  أو ببساطة اسم مجال يشبه بشكل مضلل اسم المجال الحقيقي مثل *www.example.org* بدلاً من *www.example.com* .

حتى مع وجود قائمة HSTS المحمّلة مسبقًا، لا يمكن لـ HSTS منع الهجمات المتقدمة ضد TLS نفسه، مثل هجمات BEAST أو CRIME التي قدمها Juliano Rizzo وThai Duong. الهجمات ضد TLS نفسه مستقلة عن تنفيذ سياسة HSTS. كما أنها لا تستطيع الحماية من الهجمات على الخادم نفسه - فإذا تم اختراقه، فسوف يقدّم أي محتوى عبرTLS بدون مشاكل.

### قضايا الخصوصية
يمكن استخدام HSTS لوضع علامات شبه دائمة على المتصفحات الزائرة ببيانات تعريف قابلة للاسترجاع ( ملفات تعريف الارتباط الفائقة ) يمكن أن تستمر داخل وضع التصفح الخاص " المتخفي" وخارجه. من خلال إنشاء صفحة ويب تُجري عدة طلبات HTTP إلى نطاقات محددة، على سبيل المثال، إذا تم استخدام عشرين طلب متصفح إلى عشرين نطاقًا مختلفًا، فمن الناحية النظرية يمكن التمييز بين أكثر من مليون زائر (2 20 ) بسبب الطلبات الناتجة التي تصل عبر HTTP مقابل HTTPS؛ حيث يكون الأخير عبارة عن "بتات" ثنائية مسجلة مسبقًا تم إنشاؤها مسبقًا عبر رؤوس HSTS.

## دعم المتصفح
بديل=Settings page Security within Chromium 45, showing the status of the security policy for the domain "en.wikipedia.org".|حدود|يسار|428x428بك| صفحة الإعدادات لأمان النقل الصارم HTTPS ضمن Chromium 45، والتي تُظهر حالة سياسة الأمان للنطاق "en.wikipedia.org".

* كروميوم وجوجل كروم منذ الإصدار 4.0.211.0 
* Firefox منذ الإصدار 4؛  مع Firefox 17، قامت Mozilla بدمج قائمة من المواقع التي تدعم HSTS.
* أوبرا منذ الإصدار 12 
* Safari منذ OS X Mavericks (الإصدار 10.9، أواخر عام 2013) 
* Internet Explorer 11 على Windows 8.1 وWindows 7 مع تثبيت KB3058515 (تم إصداره كتحديث لنظام Windows في يونيو 2015) 
* Microsoft Edge وInternet Explorer 11 على Windows 10 
* متصفح BlackBerry 10 و WebView منذ نظام التشغيل BlackBerry OS 10.3.3.

## أفضل ممارسات النشر
اعتمادًا على النَشر الفِعلي، هناك تهديدات معينة (مثل هجمات حقن ملفات تعريف الارتباط) يمكن تجنبها من خلال اتباع أفضل الممارسات.

* يجب على مضيفي HSTS الإعلان عن سياسة HSTS في اسم النطاق الأعلى الخاص بهم. على سبيل المثال، يجب على مضيف HSTS على  أن يُرسل أيضًا ترويسة HSTS على  . ويجب أن تحدد الترويسة التوجيه `includeSubDomains` . [ 2 ] : §6.1.2 
* بالإضافة إلى نشر HSTS، يجب على المضيف في  تضمين طلب لمورد من  للتأكد من أن HSTS لنطاق المستوى الأعلى قد تم تعيينها وتحمي المستخدم من هجمات حقن ملفات تعريف الارتباط المحتملة التي ينفذها مهاجم من نوع MITM يقوم بحقن مرجع إلى النطاق الأعلى (أو حتى  )، والذي يمكن للمهاجم الرد عليه بعد ذلك. [ 2 ] : §11.4 

## انظر أيضًا

*  - a discussion of overall HSTS security considerations
* Content Security Policy
* .app TLD – a Google-operated TLD included in the HSTS preload-list by default
* .dev TLD – a Google-operated TLD included in the HSTS preload-list by default
* HTTP Public Key Pinning

## المراجع



## الروابط الخارجية

* مجموعة عمل IETF WebSec
* الأمن الآن 262: إجراءات أمنية صارمة للنقل
* 
* اختبار HSTS وتثبيت المفتاح العام للمتصفح عبر الإنترنت
* إرسال التحميل المسبق لـ HSTS لمتصفحات Google Chrome وMozilla Firefox وSafari وIE 11 وEdge
* قائمة Chromium HSTS المحملة مسبقًا
* أمان النقل الصارم على مستندات الويب الخاصة بشبكة MDN

تصنيف:بروتوكول طبقة المنافذ الآمنة
تصنيف:تعمية
تصنيف:معايير أمن الحاسوب
تصنيف:أمن الحاسوب
تصنيف:أمن المعلومات
تصنيف:معايير الإنترنت