الخلط بين الوسطاء الضارين والخبيث باستخدام الأمان المشدَّد لنقل البيانات باستخدام بروتوكول HTTPS وHTTP

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

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

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

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

الوسطاء

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

يمكنك مشاهدة هذه القفزات أثناء التنفيذ في مسار التتبع. يبدو المسار من جهاز الكمبيوتر إلى 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 المعدَّلة بشكل ضار كاستجابة صالحة، إذ لا تتوفر أي آلية يمكنها ضمان أن البيانات التي يتم استقبالها هي _exactly _البيانات المرسلة. إذا قرر أحدهم قلب خدمة الإنترنت لدي لإجراء ضحك، لن يحالفني الحظ أكثر أو أقلّ.

هل هذا خط آمن؟

إنّ التبديل من 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

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

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

وتعني إعادة التوجيه الشفافة إلى بروتوكول HTTPS أنّ الغالبية العظمى من الأوقات التي يزور فيها المستخدمون موقعك الإلكتروني، سيستخدمون اتصالاً آمنًا. مع ذلك، يؤدي ذلك إلى ترك فرصة صغيرة للهجوم: يكون اتصال HTTP الأولي مفتوحًا على نطاق واسع، ومعرّضًا لعمليات إزالة طبقة المقابس الآمنة والهجمات ذات الصلة. بما أن الشخص الوسيط لديه إمكانية الوصول الكامل إلى طلب 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: يحتوي على تفاصيل) ستلاحظ أن هذا الموقع تحديدًا قد طلب الدخول عبر 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 هو الطريقة الوحيدة لضمان وصول البيانات التي ترسلها إلى المستلم المقصود بشكل سليم عن بُعد. يجب إعداد اتصالات آمنة لمواقعك الإلكترونية وتطبيقاتك اليوم. إنها عملية مباشرة إلى حد ما، وستساعد في الحفاظ على أمان بيانات عملائك. بعد إنشاء قناة مشفرة، يجب أن تعيد توجيه المستخدمين بشفافية إلى هذا الاتصال الآمن بغض النظر عن كيفية وصولهم إلى موقعك عن طريق إرسال استجابة 301 HTTP. ثم تأكد من أن جميع معلومات الجلسة الحساسة للمستخدمين لا تستخدم هذا الاتصال الآمن فقط عن طريق إضافة الكلمة الرئيسية الآمنة عند إعداد ملفات تعريف الارتباط. بعد تنفيذ كل ذلك، تأكَّد من أنّ المستخدمين لن يسقطوا عن طريق الخطأ مطلقًا من خلال حمايتهم من خلال التأكّد من أنّ المتصفِّح الذي يستخدمونه يفعل الإجراء الصحيح من خلال إرسال عنوان Strict-Transport-Security.

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

المراجِع