الشهادة خلف القفل كانت قد أعلنت بالفعل عن الصفحة التي لم تطلقها بعد

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

تسمى هذه الآلية Certificate Transparency، ولا علاقة لها بالاختراق. إنها سجل عام ودائم لشهادات HTTPS موجود منذ عام 2018، قابل للبحث فيه مجانا، ويحتوي بالفعل على السجل الكامل لكل اسم مضيف وضعه هذا الموقع، أو أي موقع آخر، خلف شهادة تعمل دون تحذير من المتصفح. لم يتحقق تقريبا أي مشغل من مدخلته الخاصة في هذا السجل من قبل. هذه هي الفجوة الحقيقية التي تستحق الإغلاق هنا، ليست ثغرة بالمعنى المعتاد، بل سجل كان عاما طوال الوقت ولم يُعامَل قط على هذا الأساس.

ما الذي تتحول إليه الشهادة بصمت، لحظة إصدارها

منذ عام 2018، يجب أن تُسجَّل الشهادة الموثوقة علنا، تلك التي تجعل Chrome وSafari يعرضان قفلا بسيطا بدلا من تحذير، في أحد سجلات Certificate Transparency، وإلا لن يثق بها هذان المتصفحان. أضافت Apple المتطلب نفسه لـSafari لاحقا في العام نفسه. لم يكن الهدف من هذا استهداف المواقع الإباحية أو أدلة الإعلانات المبوبة تحديدا؛ بل بُني لمنع أي شخص من إصدار شهادة مزيفة سرا لنطاق شخص آخر واعتراض حركة بياناته. الأثر الجانبي هو أن السجل يحفظ أيضا كل شهادة حقيقية يحصل عليها موقع لنفسه، ولم يُصمَّم هذا السجل أبدا ليبقى خاصا.

يسرد السجل، بالاسم، كل مضيف تغطيه الشهادة فعلا. شهادة صادرة لـadmin.example.com تُظهر هذا الاسم بالضبط، بنص واضح، إلى الأبد. لا يهم إن كانت الصفحة خلف هذا الاسم مرتبطة يوما من قائمة الموقع، أو مذكورة في خريطة الموقع، أو مفهرسة في محرك بحث. سجّلتها جهة إصدار الشهادات لحظة إصدارها، سواء كانت Let's Encrypt أو Cloudflare أو مدير الشهادات التلقائي المدمج في معظم لوحات الاستضافة، لأن جميعها تخضع لقواعد المتصفحات نفسها.

التحقق من هذا لا يكلف شيئا ويستغرق أقل من دقيقة. أداة مجانية تسمى crt.sh تتيح لأي شخص كتابة نطاق ورؤية كل شهادة سُجِّلت له على الإطلاق، دون حساب، ودون تسجيل. كتابة نطاق منافس تعمل تماما كما كتابة النطاق الخاص بالمرء، وهذا بالضبط ما يحوّل سجلا تقنيا روتينيا إلى خطر تجاري. يمكن لأي مشغل يقرأ هذا أن يفتح تلك الصفحة الآن ويرى، للمرة الأولى، ما كشفه نطاقه بالفعل للعالم.

هناك استثناء حقيقي واحد، وهو مهم لكل ما يلي: الشهادة الشاملة، التي تغطي نمطا كاملا مثل ‎*.example.com‎ بدلا من اسم محدد، تسجل في السجل ذلك النمط فقط. أسماء المضيفين المحددة التي تستخدمها فعليا، مثل newcity.example.com أو staging.example.com، لا تظهر بالاسم في السجل. أما الشهادة المخصصة لنطاق فرعي واحد محدد فتظهر دائما بالاسم. هذا الفارق تحديدا هو الورقة الفعلية التي يملكها المشغل، وسيعود الحديث عنه لاحقا.

ما الذي يُسلَّم فعليا لشخص غريب، بثلاث طرق ملموسة

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

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

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

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

ما الذي لا يوقف شيئا من هذا، وما الذي ينفع فعلا

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

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

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

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

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

ما الذي يجب التحقق منه فعلا هذا الأسبوع

الخطوة الأولى لا تكلف شيئا وتستغرق خمس دقائق: فتح crt.sh، وكتابة نطاق هذا الموقع، وقراءة القائمة الكاملة لكل ما يظهر. أي مدخلة غير معروفة تستحق سؤالا مباشرا لمن يدير الاستضافة: هل لا يزال هذا يعمل، وإن كان كذلك، فلماذا يعرف الإنترنت العام عنوانه اليوم.

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

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

بالنسبة لكل صفحة دخول أو مراجعة أو فوترة داخلية تعمل اليوم بالفعل، السؤال ليس ما إذا كان اسمها يصعب تخمينه. السؤال هو ما إذا كانت هناك كلمة مرور حقيقية، وحيثما أمكن تقييد بعنوان، أمامها بغض النظر عن الاسم، لأن هذا هو ما يصمد فعلا بمجرد أن يصبح الاسم نفسه عاما بالفعل، وهو على الأرجح، بعد التحقق من crt.sh، كذلك بالفعل.