ما أوجه الاختلاف في بروتوكول WebSocket الجديد

Eiji Kitamura

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

ما هي التغييرات التي تم إجراؤها منذ WebSocket HyBi 00؟

• تم تغيير تنسيق إطار البروتوكول. كان HyBi 00 يستخدم "0x00" للرأس و"0xff" للذيل في كل إطار. يستخدم HyBi 10 الآن تنسيقًا جديدًا على النحو التالي:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-------+-+-------------+-------------------------------+
     |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
     |I|S|S|S|  (4)  |A|     (7)     |             (16/63)           |
     |N|V|V|V|       |S|             |   (if payload len==126/127)   |
     | |1|2|3|       |K|             |                               |
     +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
     |     Extended payload length continued, if payload len == 127  |
     + - - - - - - - - - - - - - - - +-------------------------------+
     |                               |Masking-key, if MASK set to 1  |
     +-------------------------------+-------------------------------+
     | Masking-key (continued)       |          Payload Data         |
     +-------------------------------- - - - - - - - - - - - - - - - +
     :                     Payload Data continued ...                :
     + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
     |                     Payload Data continued ...                |
     +---------------------------------------------------------------+

تم حلّ المشاكل المتعلّقة بالأمان

• تمت إضافة Sec-WebSocket-Key وSec-WebSocket-Accept بدلاً من مفاتيح HyBi 00 الثلاثة. يمنح المتصفّح رقمًا عشوائيًا إلى Sec-WebSocket-Key. بعد ذلك، يستخدم الخادم مع GUID الخاص ببروتوكول WebSocket‏ (258EAFA5-E914-47DA-95CA-C5AB0DC85B11) وSHA1 / BASE64 وما إلى ذلك لعرض Sec-WebSocket-Accept حتى يتمكّن المتصفّح من تأكيد فهمه لبروتوكول WebSocket. ويؤدي ذلك إلى منع هجمات البروتوكولات المتعددة.
• أصبح الآن مطلوبًا إخفاء الإطار في كل إطار. ويمنع ذلك تسميم ذاكرة التخزين المؤقت على الخادم الوكيل. تتم إضافة Sec-WebSocket-Origin لمنع الوصول من النصوص البرمجية التي لا يعرفها مقدّم الخدمة.
• تتم إضافة Sec-WebSocket-Origin بدلاً من مفتاح Origin الخاص بـ HyBi 00 لمنع الوصول من النصوص البرمجية التي لا يعرفها مقدّم الخدمة. يُرجى العِلم أنّه سيتم عرض "Origin" فقط في HyBi 11.

التغييرات في JS API

• يمكن أن يكون subprotocol الآن صفيفًا، ما يسمح بتوقيع طريقة new WebSocket(String url, Array subprotocol)
• سمة .protocol [سلسلة]
• سمة .binaryType [Blob|ArrayBuffer]
• .extension [سلسلة]
• تمت إضافة رمز الحالة والسبب (سبب إغلاق الاتصال) إلى CloseEvent. تم أيضًا تغيير الدالة close() لقبول هاتين الوسيطتين وفقًا لذلك.

الإضافات

• تمت إضافة Sec-WebSocket-Extensions. الإضافات المُقترَحة هي:
• تجعل ميزة deflate-frame الإطارات مضغوطة من المصدر ويتم استخراجها في الوجهة.
• x-google-mux لتفعيل ميزة "البث المتعدّد"، ولكنّها لا تزال في مرحلة مبكرة.

هل هناك توافق بين HyBi 00 وHyBi 10 في كلّ من تنفيذ الخادم والمتصفّح؟

• يمكن لعمليات تنفيذ الخادم إتاحة كل من HyBi 00 وHyBi 10 من خلال الاطّلاع على عنوان HTTP الخاص بإجراء المصادقة. ومع ذلك، لا يُنصح بتوفير التوافق مع HyBi 00 لأنّه معروف بأنّه يتضمّن ثغرات أمنية.
• تتشابه واجهة برمجة تطبيقات WebSocket JavaScript API إلى حدّ كبير بين الإصدارَين القديم والجديد. مع ذلك، كما ذُكر أعلاه، لا ننصح باستخدام HyBi 00 لأنّه من المعروف أنّه عرضة للاختراق.

ما هو المتصفّح المتوافق مع HyBi 10؟

• يتوافق الإصدار 14 من Chrome مع بروتوكول HyBi 10، على الرغم من أنّ التغييرات المذكورة أعلاه في واجهة برمجة التطبيقات WebSocket JavaScript API لا تزال في الطريق. من المخطّط أيضًا أن يكون متوافقًا مع HyBi 10.