¿Por qué no hay soporte para TCP Sockets en JavaScript?

7

Sé que ahora hay WebSockets, pero ¿cuál es el problema de proporcionar una API de socket para permitir interactuar con los protocolos existentes?

Quiero decir, después de todo, puedo usar un objeto flash oculto para hacer lo mismo ya. ¿Hay un vector de ataque que me falta?

    
pregunta Simon Farshid 22.09.2015 - 03:06
fuente

3 respuestas

14
  

... pero ¿cuál es el problema con proporcionar una API de socket para permitir la interacción con los protocolos existentes?

Esto no es una restricción del idioma en sí, sino de su uso dentro de la caja de arena dentro del navegador. Solo imagine que un script en algún lugar de Internet se carga en el navegador y podría acceder desde dentro del navegador a todas las computadoras a las que puede acceder el navegador con protocolos arbitrarios. Fácilmente podría hacer un mal uso de esto para enviar correo no deseado a través de un servidor de correo interno de la compañía o atacar / mal usar otros recursos internos y externos.

Lo que significa que debe haber algunas restricciones establecidas y los diferentes entornos de entornos de pruebas para los diferentes tiempos de ejecución de idiomas proporcionan diferentes tipos de restricciones:

  • Con flash, el host de destino debe permitir el acceso explícito al proporcionar un archivo de política de socket apropiado. Esto es similar al mecanismo dentro de HTML5 CORS .
  • Los applets de Java que no son de confianza están limitados a la comunicación con el host que proporciona el applet.
  • Y con JavaScript dentro del navegador, puedes hablar con casi todos los sitios, pero estás limitado por el protocolo que puedes usar, es decir, HTTP (restringido por CORS) y WebSockets.
respondido por el Steffen Ullrich 22.09.2015 - 07:06
fuente
3

No estoy seguro de qué acceso a la API de socket proporciona un objeto Flash, pero existen muy buenas razones para no permitir sockets TCP o UDP (mucho menos cualquier otro tipo de JavaScript).

El más grande, probablemente, es que básicamente estás proporcionando una manera de evitar los cortafuegos si lo haces. Todos los servicios en su máquina que escuchan en sockets de red de bucle invertido, normalmente inaccesibles por atacantes externos, ahora pueden ser atacados desde el navegador. Ahora se puede acceder o atacar a cada máquina en su red, normalmente aislada de Internet por su puerta de enlace y firewall, mediante un código de Internet.

También hay otras razones. El escaneo de puertos y los ataques DDOS se vuelven mucho más fáciles cuando los navegadores pueden hacerlo sin un complemento ( sí, los navegadores pueden intentar iniciar DDOS en servidores HTTP (S), pero podrían ser mucho más eficientes con sockets de nivel inferior) ). Los gusanos de red (especialmente aquellos a los que solo una pequeña parte de las máquinas son vulnerables) pueden propagarse mucho más rápido cuando todos los que ven un anuncio en un sitio web popular comienzan a enviar ataques, en lugar de solo aquellos que realmente se infectan.

Los websockets existen para proporcionar una forma de comunicación de socket con cosas que explícitamente desean comunicarse con un navegador que ejecuta código no confiable. El servidor de Internet típico está endurecido de manera similar, esperando clientes maliciosos de todas las franjas. El problema proviene de los servicios que no esperan tráfico malicioso, ya que solo los clientes de confianza pueden acceder a ellos. Los zócalos controlados por JS lo romperían totalmente.

    
respondido por el CBHacking 22.09.2015 - 06:43
fuente
0

Los navegadores equivalentes a un socket TCP típico son las spec de la API de WebSockets.

Si desea sockets en JavaScript, eche un vistazo a la socket en node.js

    
respondido por el jas- 22.09.2015 - 03:13
fuente

Lea otras preguntas en las etiquetas