Socket.IO Client Security

Question

Socket.IO Client Security

#1 de rook (2 votos)
#2 de Rob W (2 votos)
#3 de jfriend00 (0 votos)

4

Soy nuevo en Node.js y Socket.IO. Según la documentación, el código del lado del cliente es algo así como:

<script src="/socket.io/socket.io.js"></script>
<script>
  var socket = io('http://localhost:3000');
  socket.on('news', function (data) {
    console.log(data);
    socket.emit('my other event', { my: 'data' });
  });
</script>

Es simple y fácil, pero a pesar de que está perfectamente bien para las pruebas locales, no estoy seguro de si es realmente seguro en una página en vivo, ya que está exponiendo la información del evento del servidor.

¿Cómo oculto la información confidencial en una página como esta?

node.js websocket

pregunta Cemre 18.10.2014 - 20:44

fuente

3 respuestas

Lea otras preguntas en las etiquetas node.js websocket

¿Gitolite proporciona un vector de ataque para la vulnerabilidad de shellshock? cambiando la distribución de forma segura, ¿existe una estrategia para obtener una imagen ISO de distro sin control?

score 2 · Answer 1

Socket.io crea un WebSocket , y WebSockets sigue las reglas normales de la Política del Mismo Origen. Sin embargo, es posible convertir un WebSocket en un recurso de origen cruzado utilizando el encabezado HTTP Access-control-allow-origin , que comúnmente se conoce como CORS. Si, por algún motivo, se utilizara CORS para crear un WebSocket de origen cruzado, es posible que este WebSocket pueda ser secuestrado por un dominio no confiable .

Además, un WebSocket es como cualquier otra API, ya que expone la lógica de la aplicación a los atacantes. Asegúrese de abordar las vulnerabilidades comunes de las aplicaciones web, como las que se encuentran en Top 10 de OWASP . De particular preocupación es Referencia de objetos directa insegura , Injection Attacks , y Roto Autenticación y gestión de sesiones .

score 2 · Answer 2

Hay dos soluciones genéricas para este problema. Ambas soluciones se basan en el enfoque de no publicar información en el público que no debería ser pública. Esto implica que tiene que implementar algún tipo de mecanismo de autenticación en su aplicación, por ejemplo. un formulario de inicio de sesión que crea una nueva sesión (y nuevas claves de sesión temporal). No hace falta decir que también debes usar https / wss en lugar de http / ws .

El primer método es publicar solo eventos públicos y obtener datos de eventos privados a través de un canal separado (por ejemplo, una nueva solicitud HTTP). Esto es lo que hace Stack Exchange con las notificaciones en vivo de la bandeja de entrada: los sockets solo se usan para notificar a los suscriptores nuevos mensajes de la bandeja de entrada, mientras que el contenido real solo se obtiene a través de http (s) cuando el usuario hace clic en la burbuja de notificación.

El segundo método es autenticar la conexión Socket.IO antes de almacenar el lado del servidor de socket. En Socket.IO, puede pasar información adicional con el protocolo de enlace a través de la opción query . En el servidor, lea este valor y solo permita a los usuarios crear el socket después de la autenticación exitosa ( ejemplo ^{la respuesta aceptada es para socket.io 0.9, busque aquí para socket.io 1.x}). Esta clave debe ser tratada como una cookie de sesión. Cuando el usuario cierra la sesión, el socket asociado con esta clave debe ser destruido y el token invalidado. Lo ideal es que esta clave se use solo una vez (es decir, se invalide después del primer uso), pero no funciona bien en la práctica si la conexión no es confiable y debe volver a conectarse a Socket.IO.

Como alternativa al rechazo del socket (método 2), también puede aceptar el socket y usar los detalles de autenticación para controlar si un usuario puede suscribirse a un evento o unirse a una sala. El cliente solo recibirá un evento si lo envía al servidor, por lo tanto, si no lo envía (por ejemplo, porque el usuario no está en la sala donde se transmite el evento), entonces no hay fuga de información.

score 0 · Answer 3

Al igual que con todas las preguntas de seguridad, debe describir cuáles son sus objetivos de seguridad. A salvo de quien? ¿A salvo de qué tipos de acceso? ¿Qué tan seguro está de un acceso no deseado? ¿Qué niveles de autenticación y cifrado está dispuesto a agregar para evitar que los espectadores no deseados de la información?

El esquema que has configurado anteriormente permite lo siguiente:

Cualquier agente puede conectarse a su servidor con un websocket y suscribirse a los eventos de "noticias". Por lo tanto, cualquier información que se transmita con el mensaje news está disponible para cualquiera.
En realidad, cualquier agente puede conectarse a su servidor con un websocket y leer todos los mensajes que transmite a todos los sockets conectados. Esto no se limita solo al evento news . Si su servidor envía los datos a cualquier socket web conectado al azar, cualquier agente aleatorio puede conectarse a través de websockets y leer esa información.
En cuanto a los datos enviados de otra manera (de su cliente al servidor), esa información solo está disponible para alguien que indague en la conexión (en su ISP, en transporte a través de Internet al centro de datos donde El servidor se encuentra dentro del centro de datos antes de que llegue a su servidor oa cualquier persona con acceso físico a su servidor. Estos datos no están disponibles para agentes externos sin acceso al transporte en el que fluyen los paquetes.

La respuesta corta sobre cómo hacer que los datos sean más seguros es casi lo mismo que la mayoría de las preguntas de seguridad.

Asegure el acceso, requiriendo algún tipo de inicio de sesión seguro antes de conceder el acceso.
Asegure el transporte con cifrado (como SSL respaldado por certificados apropiados).
Solo envíe información que requiera seguridad en los canales que ya han implementado la seguridad adecuada.

En Internet, no existe tal cosa como una API basada en el servidor o un acceso de websocket al que SOLO se pueda acceder desde sus propias páginas web. El acceso desde sus páginas web es solo el acceso desde un punto final aleatorio a Internet y generalmente no hay diferencia en el acceso entre una página de navegador, un pirata informático con sus propias herramientas de conectividad o algún servidor malicioso en Internet que intenta acceder a su sitio . Por lo general, no puedes notar la diferencia. Existen algunos trucos para hacer que el acceso de terceros sea más problemático (por ejemplo, incluir credenciales siempre cambiantes en cada página web que se debe usar), pero sin los tres inquilinos de seguridad anteriores, no es realmente seguro.