Por supuesto, esto es solo un ejemplo y soy consciente de la posibilidad de ocultar la carga útil en una carga útil aparentemente diseñada correctamente. Se trata de hacerlo más difícil para los malos.
No es meramente "posible". Es fácil. De hecho, bajo HTML5, es francamente trivial .
Con WebSockets, una conexión similar a HTTP puede canalizar contenido arbitrario entre el cliente Javascript lateral y una aplicación web del lado del servidor. Este es un objetivo de diseño explícito de la norma, no un accidente feliz. Si bien es posible que pueda bloquear WebSockets, es probable que esto rompa las aplicaciones web del mundo real. Peor aún, si el sitio del atacante se sirve a través de HTTPS (que también es fácil ), básicamente no puede bloquear WSS ya que esto requeriría que realice una Ataque MitM precisamente del tipo que TLS está diseñado para prevenir.
Podría emitir sus propios certificados raíz, instalarlos en todas las máquinas de sus clientes y MitM de esa manera. Pero ahora estás jugando paredes y escaleras con tus usuarios. Al romper WebSockets, les está dando un incentivo para que encuentren una manera de evitar su sistema.
El problema es que HTTP no es un protocolo "seguro" o restringido. Fue diseñado para facilitar el intercambio de documentos HTML. No fue diseñado para impedir usos no relacionados con el intercambio de documentos. Entonces, en la práctica, puede ser usado y abusado de muchas maneras, y evitar esto es patológicamente difícil.
Entonces, ¿qué puedes hacer? Bueno, depende de lo que estés tratando de hacer en primer lugar.
Si eres (digamos) una universidad, y estás tratando de evitar que los estudiantes consuman grandes cantidades de ancho de banda jugando juegos en línea, lanzando ilegalmente cosas, etc., luego rastrean su uso de ancho de banda y bloquean el N% superior (para N realista basada en la capacidad de su red).
Si usted es una empresa y está tratando de evitar que ciertos tipos de malware llamen a su casa, probablemente debería concentrarse en educar a sus usuarios sobre el malware, además de cualquier tipo de bloqueo no HTTP que esté realizando.
Si solo estás bloqueando el no HTTP porque no puedes pensar en una buena razón para permitirlo, debes preguntarte cuál es tu modelo de amenaza. ¿Qué ataques serán mitigados por este tipo de bloqueo? ¿Qué usos legítimos dejarán de funcionar? ¿Es probable que la política moleste a los usuarios hasta el punto de intentar evadirlos?