إحباط هجمات الوسيط الضارة باستخدام بروتوكول HTTPS والأمان المشدَّد لنقل البيانات باستخدام بروتوكول HTTP

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

أهمية ذلك بالنسبة إليك ضع في اعتبارك هذا:

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

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

الوسطاء

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

يمكنك الاطّلاع على هذه القفزات أثناء تنفيذها باستخدام traceroute. يبدو المسار من جهاز الكمبيوتر الخاص بي إلى HTML5Rocks على النحو التالي:

$ traceroute html5rocks.com
traceroute to html5rocks.com (173.194.71.102), 30 hops max, 60 byte packets
 1  router1-lon.linode.com (212.111.33.229)  0.453 ms
 2  212.111.33.233 (212.111.33.233)  1.067 ms
 3  217.20.44.194 (217.20.44.194)  0.704 ms
 4  google1.lonap.net (193.203.5.136)  0.804 ms
 5  209.85.255.76 (209.85.255.76)  0.925 ms
 6  209.85.253.94 (209.85.253.94)  1.226 ms
 7  209.85.240.28 (209.85.240.28)  48.714 ms
 8  216.239.47.12 (216.239.47.12)  22.575 ms
 9  209.85.241.193 (209.85.241.193)  36.033 ms
10  72.14.233.180 (72.14.233.180)  43.222 ms
11  72.14.233.170 (72.14.233.170)  43.242 ms
12  *
13  lb-in-f102.1e100.net (173.194.71.102)  44.523 ms

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

والأسوأ من ذلك أنّ هذا النوع من الاعتراض لا يمكن رصده تقريبًا. تبدو استجابة HTTP المعدَّلة بشكل ضارّ تمامًا مثل الاستجابة الصالحة، إذ لا تتوفّر أي آلية تتيح لك التأكّد من أنّ البيانات التي تم تلقّيها هي _بالضبط_ البيانات التي تم إرسالها. إذا قرر شخص ما قلب الإنترنت رأسًا على عقب من أجل الضحك، فإنني أكون أكثر أو أقل حظًا.

هل هذا الخط آمن؟

إنّ التبديل من بروتوكول HTTP الذي يعرض النص العادي إلى اتصال HTTPS آمن هو أفضل طريقة لحماية موقعك الإلكتروني من الوسطاء. تشفّر اتصالات HTTPS القناة بالكامل من البداية إلى النهاية قبل إرسال أي بيانات، ما يجعل من المستحيل على الأجهزة الموجودة بينك وبين وجهتك قراءة البيانات أو تعديلها أثناء نقلها.

يوفّر "مربّع البحث" في Chrome قدرًا كبيرًا من التفاصيل حول حالة الاتصال.
يوفّر المربّع المتعدّد الاستخدامات في Chrome قدرًا كبيرًا من التفاصيل حول حالة الاتصال.

يعتمد الأمان الذي يوفّره بروتوكول HTTPS على مفهوم مفاتيح التشفير العامة والخاصة. إنّ المناقشة المتعمّقة للتفاصيل تتجاوز (لحسن الحظ) نطاق هذه المقالة، ولكنّ الفرضية الأساسية واضحة إلى حدّ ما: لا يمكن فك تشفير البيانات المشفّرة باستخدام مفتاح عام معيّن إلا باستخدام المفتاح الخاص المقابل. عندما يبدأ المتصفّح عملية تأكيد اتصال HTTPS لإنشاء قناة آمنة، يقدّم الخادم شهادة تمنح المتصفّح كل المعلومات اللازمة لإثبات هويته من خلال التأكّد من أنّ الخادم يملك المفتاح الخاص المناسب. يتم تشفير جميع الاتصالات من تلك النقطة فصاعدًا بطريقة تثبت أن الطلبات يتم تسليمها إلى خادم المصادقة ويتم تلقي الردود منه.

وبالتالي، يمنحك بروتوكول HTTPS بعض التأكيد على أنّك تتواصل مع الخادم الذي تعتقد أنّك تتواصل معه، وأنّه لا أحد آخر يستمع إلى المحادثة أو يتلاعب بالبيانات أثناء نقلها. هذا النوع من التشفير هو شرط أساسي للأمان على الويب. إذا لم يتم عرض تطبيقك حاليًا عبر HTTPS، سيكون عرضة للهجمات. إصلاح طريقة الدفع. يوفّر موقع Ars Technica دليلاً رائعًا للحصول على شهادة وتثبيتها (مجانًا)، وأنصحك بالاطّلاع عليه لمعرفة التفاصيل الفنية. سيختلف الإعداد من مزود إلى آخر ومن خادم إلى آخر، ولكن عملية طلب الشهادة هي نفسها في كل مكان.

آمن تلقائيًا

بعد طلب الشهادة وتثبيتها، احرص على أن يستفيد المستخدمون من جهودك: انقل المستخدمين الحاليين إلى اتصالات HTTPS بشكل شفاف من خلال إعادة توجيه HTTP، وتأكَّد من أنّه لا يتم تسليم ملفات تعريف الارتباط إلا عبر اتصالات آمنة.

تفضَّل من هنا

عندما يزور مستخدم الصفحة http://example.com/، أعِد توجيهه إلى الصفحة https://example.com/ من خلال إرسال استجابة 301 Moved Permanently مع عنوان Location مناسب:

$ curl -I http://mkw.st/
HTTP/1.1 301 Moved Permanently
Server: nginx/1.3.7
...
Keep-Alive: timeout=20
Location: https://mkw.st/

يمكنك إعداد هذا النوع من إعادة التوجيه بسهولة في خوادم مثل Apache أو Nginx. على سبيل المثال، تبدو إعدادات Nginx التي تعيد التوجيه من http://example.com/ إلى https://example.com/ على النحو التالي:

server {
    listen [YOUR IP ADDRESS HERE]:80;
    server_name example.com www.example.com;
    location "/" {
        rewrite ^(.*) https://www.example.com$1 permanent;
    }
}

تتيح لنا ملفات تعريف الارتباط توفير تجارب تسجيل دخول سلسة للمستخدمين عبر بروتوكول HTTP عديم الحالة. يتم إرسال البيانات المخزّنة في ملفات تعريف الارتباط، بما في ذلك المعلومات الحساسة مثل معرّفات الجلسات، مع كل طلب، ما يسمح للخادم بمعرفة المستخدم الذي يستجيب له في الوقت الحالي. بعد التأكّد من أنّ المستخدمين يصلون إلى موقعنا الإلكتروني عبر بروتوكول HTTPS، علينا أيضًا التأكّد من أنّ البيانات الحسّاسة المخزّنة في ملفات تعريف الارتباط لا يتم نقلها إلا عبر اتصال آمن، ولا يتم إرسالها مطلقًا بشكل واضح.

يتضمن إعداد ملف تعريف الارتباط بشكل عام عنوان HTTP يشبه ما يلي:

set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT

يمكنك توجيه المتصفّح إلى حصر استخدام ملف تعريف الارتباط بالجلسات الآمنة من خلال إضافة كلمة رئيسية واحدة:

Set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT; secure

لن يتم إرسال ملفات تعريف الارتباط التي تم ضبطها باستخدام الكلمة الرئيسية secure عبر بروتوكول HTTP مطلقًا.

إغلاق النافذة المفتوحة

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

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

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

ستلاحظ المتصفحات التي تتيح استخدام هذا العنوان (حاليًا Firefox وChrome وOpera: يتضمّن موقع caniuse التفاصيل) أنّ هذا الموقع الإلكتروني تحديدًا قد طلب الوصول عبر HTTPS فقط، ما يعني أنّه بغض النظر عن كيفية وصول المستخدم إلى الموقع الإلكتروني، ستتم زيارته عبر HTTPS. حتى إذا كتبت http://example.com/ في المتصفّح، سيتم توجيهها إلى HTTPS بدون إجراء اتصال HTTP. والأفضل من ذلك، إذا رصد المتصفّح شهادة غير صالحة (قد تكون محاولة لانتحال هوية الخادم)، لن يُسمح للمستخدمين بمواصلة التصفّح عبر HTTP، فإما أن يكون الاتصال آمنًا أو لا يتم إجراؤه، وهذا أمر ممتاز.

ستنتهي صلاحية حالة HSTS للخادم في المتصفّح بعد max-age ثانية (أي بعد شهر تقريبًا في هذا المثال). اضبط هذه القيمة على رقم مرتفع بشكل معقول.

يمكنك أيضًا التأكّد من أنّ جميع النطاقات الفرعية للأصل محمية من خلال إضافة التوجيه includeSubDomains إلى العنوان:

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

انطلِق بأمان

HTTPS هو الطريقة الوحيدة للتأكد من أنّ البيانات التي ترسلها تصل إلى المستلم المقصود سليمة. يجب إعداد اتصالات آمنة لمواقعك الإلكترونية وتطبيقاتك اليوم. إنّها عملية بسيطة إلى حدّ ما، وستساعدك في الحفاظ على أمان بيانات عملائك. بعد إنشاء قناة مشفّرة، عليك إعادة توجيه المستخدمين بشكل شفاف إلى هذا الاتصال الآمن بغض النظر عن طريقة وصولهم إلى موقعك الإلكتروني، وذلك من خلال إرسال استجابة HTTP ‏301. بعد ذلك، تأكَّد من أنّ جميع معلومات الجلسات الحساسة الخاصة بالمستخدمين تستخدم فقط هذا الاتصال الآمن من خلال إضافة الكلمة الرئيسية secure عند إعداد ملفات تعريف الارتباط. بعد تنفيذ كل هذه الخطوات، تأكَّد من أنّ المستخدمين لن يواجهوا أي مشاكل، وذلك من خلال حمايتهم والتأكّد من أنّ المتصفّح يتّخذ الإجراءات الصحيحة عبر إرسال عنوان Strict-Transport-Security.

لا يتطلّب إعداد HTTPS الكثير من العمل، وله فوائد كبيرة لموقعك الإلكتروني ومستخدميه. الأمر يستحق بعض الجهد.

الموارد