انتقل إلى المحتوى

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

هذه المقالة يتيمة. ساعد بإضافة وصلة إليها في مقالة متعلقة بها
غير مفحوصة
يرجى مراجعة هذه المقالة وإزالة وسم المقالات غير المراجعة، ووسمها بوسوم الصيانة المناسبة.
من ويكيبيديا، الموسوعة الحرة

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

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

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

تاريخ المواصفات

[عدل]

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

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

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

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

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

نظرة عامة على آلية HSTS

[عدل]

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

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

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

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

قابلية التطبيق

[عدل]

أهم ثغرة أمنية يمكن لـ HSTS إصلاحها هي هجمات رجل في الوسط التي تُعرف بـ SSL، والتي قدمها علنًا Moxie Marlinspike في محاضرته BlackHat Federal عام 2009 بعنوان "حيل جديدة لهزيمة SSL في التطبيق العملي". [9] [10] تعمل هجمة إزالة تشفير SSL (و TLS ) عن طريق تحويل اتصال HTTPS الآمن بشكل شفاف إلى اتصال HTTP عادي. يمكن للمستخدم رؤية أن الاتصال غير آمن، لكن الأهم أنه لا توجد طريقة لمعرفة ما إذا كان يجب أن يكون الاتصال آمنًا أم لا. في وقت محاضرة Marlinspike، لم تكن العديد من المواقع الإلكترونية تستخدم TLS/SSL،لذلك لم يكن وسيلة لمعرفة (دون معرفة مسبقة) ما إذا كان استخدام HTTP العادي ناتجًا عن هجوم، أو ببساطة لأن الموقع الإلكتروني لم يطبق TLS/SSL. بالإضافة إلى ذلك، لا يتم تقديم أي تحذيرات للمستخدم أثناء عملية تخفيض الإصدار، مما يجعل الهجوم خفيًا إلى حد ما بالنسبة للجميع باستثناء الأكثر يقظة. أداة sslstrip من Marlinspike تقوم بأتمتة الهجوم بالكامل.[بحاجة لمصدر][ بحاجة لمصدر ]

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

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

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

القيود

[عدل]

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

الحلول مع قائمة التحميل المسبق

[عدل]

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

أشار جوناد علي إلى أن HSTS غير فعالة ضد استخدام النطاقات الزائفة؛ فمن خلال استخدام هجمات تعتمد على DNS، من الممكن لمهاجم رجل في الوسط أن يقدم حركة المرور من نطاق وهمي لا يوجد في قائمة HSTS المحمّلة مسبقًا، [21] ويمكن تحقيق ذلك من خلال هجمات انتحال DNS، [22] أو ببساطة اسم مجال يشبه بشكل مضلل اسم المجال الحقيقي مثل 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. [23]

دعم المتصفح

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

أفضل ممارسات النشر

[عدل]

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

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

انظر أيضًا

[عدل]
  • RFC 6797 - 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

المراجع

[عدل]
  1. ^ "Strict-Transport-Security". مركز مطوري موزيلا (بالإنجليزية الأمريكية). موزيلا. Archived from the original on 2020-03-20. Retrieved 2018-01-31.
  2. ^ "[websec] Protocol Action: 'HTTP Strict Transport Security (HSTS)' to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)". 2 أكتوبر 2012. مؤرشف من الأصل في 2017-01-29. اطلع عليه بتاريخ 2012-10-02.
  3. ^ Hodges، Jeff (30 يونيو 2010). "Re: [HASMAT] "STS" moniker (was: IETF BoF @IETF-78 Maastricht: HASMAT...)". مؤرشف من الأصل في 2017-02-02. اطلع عليه بتاريخ 2010-07-22.
  4. ^ "Strict Transport Security -06". 18 ديسمبر 2009. مؤرشف من الأصل في 2017-02-21. اطلع عليه بتاريخ 2009-12-23.
  5. ^ "Strict Transport Security -05". 18 سبتمبر 2009. مؤرشف من الأصل في 2020-02-24. اطلع عليه بتاريخ 2009-11-19.
  6. ^ "ForceHTTPS: Protecting High-Security Web Site from Network Attacks". أبريل 2008. مؤرشف من الأصل في 2020-02-28. اطلع عليه بتاريخ 2009-11-19.
  7. ^ Hodges، Jeff؛ Steinguebl, Andy (29 أكتوبر 2010). "The Need for Coherent Web Security Policy Framework(s)". مؤرشف من الأصل في 2017-08-14. اطلع عليه بتاريخ 2012-11-21.
  8. ^ ا ب "Strict-Transport-Security". مركز مطوري موزيلا (بالإنجليزية الأمريكية). موزيلا. Archived from the original on 2020-03-20. Retrieved 2018-01-31."Strict-Transport-Security". MDN Web Docs. Mozilla. Archived from the original on 20 March 2020. Retrieved 31 January 2018.
  9. ^ Marlinspike، Moxie (2009). "New Tricks For Defeating SSL In Practice" (PDF). مؤتمر القبعات السوداء. Washington, DC. مؤرشف (PDF) من الأصل في 2014-12-30. اطلع عليه بتاريخ 2012-03-15.
  10. ^ Defeating SSL Using Sslstrip على يوتيوب
  11. ^ Langley، Adam (8 يوليو 2010). "Strict Transport Security". The Chromium Projects. مؤرشف من الأصل في 2019-09-01. اطلع عليه بتاريخ 2010-07-22.
  12. ^ Keeler، David (1 نوفمبر 2012). "Preloading HSTS". Mozilla Security Blog. مؤرشف من الأصل في 2020-02-24. اطلع عليه بتاريخ 2014-02-06.
  13. ^ Bell, Mike؛ Walp, David (16 فبراير 2015). "HTTP Strict Transport Security comes to Internet Explorer". مؤرشف من الأصل في 2015-11-15. اطلع عليه بتاريخ 2015-02-16.
  14. ^ Hodges، Jeff (31 أكتوبر 2010). "Firesheep and HSTS (HTTP Strict Transport Security)". مؤرشف من الأصل في 2016-06-23. اطلع عليه بتاريخ 2011-03-08.
  15. ^ Selvi، Jose (17 أكتوبر 2014). "Bypassing HTTP Strict Transport Security" (PDF). مؤتمر القبعات السوداء. Amsterdam. مؤرشف (PDF) من الأصل في 2014-10-22. اطلع عليه بتاريخ 2014-10-22.
  16. ^ "Chromium HSTS Preloaded list". cs.chromium.org. مؤرشف من الأصل في 2020-02-18. اطلع عليه بتاريخ 2019-07-10.
  17. ^ Langley، Adam (8 يوليو 2010). "Strict Transport Security". The Chromium Projects. مؤرشف من الأصل في 2019-09-01. اطلع عليه بتاريخ 2010-07-22.Langley, Adam (8 July 2010). "Strict Transport Security". The Chromium Projects. Archived from the original on 1 September 2019. Retrieved 22 July 2010.
  18. ^ ا ب Keeler، David (1 نوفمبر 2012). "Preloading HSTS". Mozilla Security Blog. مؤرشف من الأصل في 2020-02-24. اطلع عليه بتاريخ 2014-02-06.Keeler, David (1 November 2012). "Preloading HSTS". Mozilla Security Blog. Archived from the original on 24 February 2020. Retrieved 6 February 2014.
  19. ^ Bell, Mike؛ Walp, David (16 فبراير 2015). "HTTP Strict Transport Security comes to Internet Explorer". مؤرشف من الأصل في 2015-11-15. اطلع عليه بتاريخ 2015-02-16.Bell, Mike; Walp, David (16 February 2015). "HTTP Strict Transport Security comes to Internet Explorer". Archived from the original on 15 November 2015. Retrieved 16 February 2015.
  20. ^ Butcher, Simon (11 سبتمبر 2011). "HTTP Strict Transport Security". مؤرشف من الأصل في 2019-04-26. اطلع عليه بتاريخ 2012-03-27.
  21. ^ Ali، Junade (20 أكتوبر 2017). "Performing & Preventing SSL Stripping: A Plain-English Primer". Cloudflare Blog. مؤرشف من الأصل في 2019-12-14. اطلع عليه بتاريخ 2017-12-07.
  22. ^ Maksutov، A. A.؛ Cherepanov، I. A.؛ Alekseev، M. S. (2017). "Detection and prevention of DNS spoofing attacks". 2017 Siberian Symposium on Data Science and Engineering (SSDSE). ص. 84–87. DOI:10.1109/SSDSE.2017.8071970. ISBN:978-1-5386-1593-5. S2CID:44866769.
  23. ^ "The HSTS super cookie forcing you to choose: "privacy or security?" -". sophos.com. 2 فبراير 2015. مؤرشف من الأصل في 2020-02-11. اطلع عليه بتاريخ 2015-12-01.
  24. ^ The Chromium Developers (17 نوفمبر 2010). "Strict Transport Security - The Chromium Projects". مؤرشف من الأصل في 2020-03-20. اطلع عليه بتاريخ 2010-11-17.
  25. ^ Hodges، Jeff (18 سبتمبر 2009). "fyi: Strict Transport Security specification". مؤرشف من الأصل في 2020-02-29. اطلع عليه بتاريخ 2009-11-19.
  26. ^ Opera Software ASA (23 أبريل 2012). "Web specifications support in Opera Presto 2.10". مؤرشف من الأصل في 2018-06-20. اطلع عليه بتاريخ 2012-05-08.
  27. ^ agl__. (تغريدة) https://web.archive.org/web/20190509013208/https://twitter.com/agl__/status/414112266938617856. مؤرشف من الأصل في 2019-05-09. اطلع عليه بتاريخ 2013-12-20. {{استشهاد ويب}}: الوسيط |title= غير موجود أو فارغ (مساعدة) Missing or empty |date= (help)
  28. ^ "HTTP Strict Transport Security comes to Internet Explorer 11 on Windows 8.1 and Windows 7". windows.com. مؤرشف من الأصل في 2019-11-27. اطلع عليه بتاريخ 2015-06-12.
  29. ^ "Internet Explorer Web Platform Status and Roadmap". مؤرشف من الأصل في 2015-06-29. اطلع عليه بتاريخ 2014-04-14.
  30. ^ "Project Spartan and the Windows 10 January Preview Build - IEBlog". 22 يناير 2015. مؤرشف من الأصل في 2019-11-29. اطلع عليه بتاريخ 2015-01-23.


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

[عدل]

قالب:SSL/TLS


مجلوبة من «https://ar.wikipedia.org/w/index.php?title=أمان_نقل_بروتوكول_نقل_النص_الفائق_الصارم&oldid=70945303»