نظرًا لكمية البيانات الشخصية التي تتدفق من خلال سلسلة عظيمة من القنوات التي تشكّل الإنترنت، فإنّ التشفير ليس شيئًا يمكننا أو ينبغي تجاهله بسهولة. توفّر المتصفّحات الحديثة العديد من الآليات التي يمكنك استخدامها لضمان أمان بيانات المستخدمين أثناء نقلها: ملفات تعريف الارتباط الآمنة وأمان النقل الصارم هما من بين أهم الآليات. تتيح لك هذه الأدوات حماية المستخدمين بسلاسة، وتحسين اتصالاتهم باستخدام بروتوكول 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 على تشفير القناة بالكامل من البداية إلى النهاية قبل إرسال أي بيانات، ما يجعل من المستحيل على الأجهزة التي تقع بين أنت ووجهتك قراءة البيانات أثناء نقلها أو تعديلها.
يستند الأمان الذي يوفّره بروتوكول 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 الكثير من الجهد، ويعود بفوائد كبيرة على موقعك الإلكتروني و مستخدميه. إنّ الأمر يستحق بعض الجهد.
الموارد
- تقدّم شركة StartSSL شهادات مجانية تم إثبات ملكيتها باستخدام النطاق. لا يمكن أن يكون هناك سعر أفضل من "مجاني". من الممكن بالطبع الانتقال إلى مستويات أعلى من التحقّق وبأسعار معقولة.
- اختبار خادم بروتوكول طبقة المقابس الآمنة: بعد إعداد بروتوكول HTTPS لخوادمك، تأكّد من أنّك أجريت الإعداد بشكل صحيح من خلال إجراء اختبار الخادم في SSL Labs. ستحصل على تقرير تفصيلي جيد يوضّح لك ما إذا كان التطبيق قيد التشغيل.
- ننصحك بقراءة مقالة Ars Technica الأخيرة "تأمين خادم الويب باستخدام بروتوكول بروتوكول أمان طبقة النقل (SSL)/بروتوكول أمان طبقة النقل (TLS)" للاطّلاع على مزيد من التفاصيل الأساسية حول أساسيات إعداد الخادم.
- ننصحك بالاطّلاع على مواصفات الأمان المشدَّد لنقل البيانات باستخدام بروتوكول HTTP
(RFC6797) للحصول على كل المَعلومات الفنية عن رأس
Strict-Transport-Securityالتي قد تحتاج إليها. - بعد أن تتعرّف على ما تفعله، يمكنك إعلام المستخدمين بأنّه لا يمكن الوصول إلى موقعك الإلكتروني إلا من خلال مجموعة محدّدة من الشهادات. هناك بعض الأعمال الجارية في IETF التي ستسمح لك بالاستعانة بعنوان
Public-Key-Pinsللقيام بذلك. لا يزال الوقت مبكرًا، ولكنّ هذا الموضوع مثير للاهتمام ويستحق المتابعة.