الخلاصة

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

وثقت الإطارات الأولى بحدودها

قدّمت مسودة IETF الصادرة في مايو 2010 قناة ثنائية الاتجاه للمتصفح بعد افتتاحية HTTP. كان تنسيق السلك صغيراً عمداً: يبدأ إطار النص بـ0x00 وينتهي بـ0xff، ويحمل شكل آخر طولاً. تكفي هذه الحدود لطرفين يطبقان WebSocket كما ينبغي.

لكنها لا تحكم كل جهاز موجود سلفاً على المسار. فقد يمرر وكيل اعتراض طلب Upgrade ثم يواصل البحث في البايتات التالية عن طلب HTTP جديد. انتقل الطرفان إلى نحو WebSocket، فيما بقي محلل الوسيط في النحو السابق.

لم يكن يلزم أن يكون الوكيل خبيثاً. يمكن للمتصفح والخادم الالتزام باتفاقهما بالكامل، بينما يمنح طرف ثالث البايتات التالية اسم بروتوكول خاطئاً، فينشئ أثراً في الذاكرة المخبئية لم يأذن به أي من الطرفين.

لم يسلب التحويل الثابت قدرة الاختيار

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

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

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

منح وكيل الاستجابة اسماً زائفاً

درست ورقة 2011 Talking to Yourself for Fun and Profit آليات مقابس المتصفح في وجود وكلاء شفافين، أو وكلاء اعتراض بتعبير أدق. كانت بعض الأجهزة تمرر الموافقة أو الترقية من غير فهم انتقال الحالة، ثم تقرأ البيانات التي يسيطر عليها المهاجم كطلب HTTP.

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

في تجربة إعلانية أجريت في مارس 2011، وجد الباحثون شروط تسميم للذاكرة المخبئية في نسبة صغيرة غير صفرية من مسارات Java وFlash المقاسة. وبين 47,338 افتتاحية لنموذج WebSocket قائم على Upgrade وصلت إلى الاختبار، نجحت ثماني حالات. تصف هذه الأرقام تلك العينة وذلك الزمن، ولا تقيس انتشار الوكلاء اليوم.

أما النتيجة الباقية فليست النسبة. لا يمكن لإضافة بادئة لا تشبه HTTP أن تثبت أن كل محلل معيب سيحترمها؛ فقد يتجاوزها محلل مجهول ويستأنف عند الحمولة. الضمان الأقوى هو حرمان البرنامج العدائي من تشكيل صورة الحمولة على السلك كما يريد.

انتقل المفتاح إلى كل إطار

جاء التحول الحاسم في المسودة -05 في فبراير 2011. صار لكل إطار عميل مفتاحه الخاص ذو 32 بت، يختار من مصدر قوي للإنتروبيا ولا يمكن استنتاجه من المفاتيح السابقة. تشرح RFC 4086 سبب الحذر: قد يبدو الخرج غير منتظم إحصائياً ويبقى قابلاً للتوقع إذا جاء من ساعة أو عداد أو فضاء بذور صغير.

حافظت RFC 6455 النهائية على التصميم لكل إطار. تشير بتّة MASK إلى وجود أربع ثمانيات للمفتاح، وتُجرى XOR بين ثمانية الحمولة i وثمانية المفتاح i mod 4. لا يتغير طول الحمولة، ولا يدخل المفتاح في حسابه.

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

أصبح الإطار ثابتاً عند بدء الإرسال

لا يكفي مفتاح جديد إن استطاع التطبيق استنتاجه من بداية معلومة لإطار طويل ثم تعديل الجزء الذي لم يرسل بعد. تكشف البداية التحويل الرباعي المتكرر، ويمكن عندئذ اختيار الذيل بحيث يبدو، بعد التقنيع، كطلب HTTP.

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

هذه قاعدة التزام وليست نصيحة مبهمة باستعمال العشوائية. قبل الإرسال يملك التطبيق اختيار المعنى؛ وبعد البدء تحوز آلية العميل سلسلة ثابتة. من دون تسليم السلطة هذا، يتحول رصد المقدمة إلى سيطرة على المؤخرة.

عبّر الاتجاه عن نموذج التهديد

يجب تقنيع كل إطار من العميل إلى الخادم، ويحظر على الخادم تقنيع إطار إلى العميل. يغلق الخادم الاتصال عند تلقي إطار عميل غير مقنّع، ويغلقه العميل عند تلقي إطار خادم مقنّع، ويمكن استخدام رمز خطأ البروتوكول 1002.

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

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

لم يجعل TLS القناع زائداً

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

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

أبقت وسائل HTTP الجديدة الالتزام القديم

أتاحت RFC 8441 بدء WebSocket بواسطة Extended CONNECT داخل تدفق HTTP/2. ولأن :protocol يوفر إشارة الانتقال، لا يعالج هذا المسار Sec-WebSocket-Key وSec-WebSocket-Accept الخاصين بـHTTP/1.1. لكنه لم يلغ التقنيع؛ تبقى اعتبارات أمن RFC 6455 نافذة عدا مناقشة SHA-1 الخاصة بالافتتاح في القسم 10.8.

نقلت RFC 9220 Extended CONNECT إلى HTTP/3 من غير استثناء أمني جديد. تغير الغلاف من تبديل اتصال HTTP/1.1 كاملاً، إلى تدفق مختار في HTTP/2، ثم إلى تدفق QUIC؛ وبقي إطار WebSocket يحمل الدليل الاتجاهي نفسه.

تكشف الاستمرارية أن القناع لم يكن ترقيعاً لتهجئة ترويسة Upgrade. لقد مثّل العلاقة بين اختيار التطبيق والتزام العميل والتباس الوسيط، وهي علاقة بقيت مع تغير النقل المحيط.

ما يثبته المفتاح العلني وما لا يثبته

لا يثبت المفتاح الجديد هوية، ولا قبول Origin، ولا تفويض عملية، ولا سلامة البيانات خارج نقل محمي. رؤية المفتاح في الالتقاط أمر عادي؛ أما إعادة استخدامه أو إمكان توقعه فدليل على انهيار الافتراض.

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

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

المصادر وحدود الأدلة

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