¿Por qué no existe una política del mismo origen para WebSockets? ¿Por qué puedo conectarme a ws: // localhost?

Me gustaría usar WebSockets para la comunicación entre procesos para mi aplicación (Daemon <-> WebGUI y Daemon <-> FatClient, etc.). Durante la prueba, intenté conectarme a mi servidor de socket web que se ejecuta localmente (ws: // localhost: 1234) a través del cliente JavaScript WebSocket en websocket.org ( http://www.websocket.org/echo.html ).

Mi pregunta ahora es:
¿Por qué es esto posible? ¿No hay una política de origen cruzado implementada en los navegadores (aquí: FF29 en Linux)?

Estoy preguntando porque si websocket.org fuera malvado, podría intentar comunicarse con mi servidor WS local y redirigir cada mensaje que recibe de localhost a cualquier otro servidor:

Local WebSocket Server Navegador Evil Web Server
en ws: // localhost: 1234 en http: //evil.tld
        | | |
        | | ------ [GET /] ---------> |
        | | <----- [HTML + EvilJS] ---- |
        | <------ [conectar ws: // ..] ---- | |
        | <---- [alguna comunicación] -> | |
        | | ---- [delantero malvado] ----> |
        | | |

No he probado todo el caso de uso, pero la conexión a ws: // localhost del JS entregado por websocket.org definitivamente funciona.

Para abordar el "¿Por qué?" En parte, la razón por la que los navegadores no aplican la Política del mismo origen (de la cual CORS es una relajación) para WebSockets a diferencia de las llamadas AJAX, es porque los WebSockets se introdujeron después de que se estableció el valor de las solicitudes de origen cruzado y porque ' no están sujetos a SOP para empezar, la razón histórica de las verificaciones del lado del cliente CORS no se aplica.

Para AJAX, en los días de una Política de origen único general, los servidores nunca esperaban que un navegador autenticado enviara una solicitud desde un dominio ¹ diferente , por lo que no necesitaban asegurarse de que la solicitud provenía de una ubicación confiable ² , solo marque el cookie de sesión. Las relajaciones posteriores como CORS tuvieron que tener verificaciones del lado del cliente para evitar exponer las aplicaciones existentes a abusos al violar esta suposición (efectivamente haciendo un ataque CSRF ).

Si la Web se estuviera inventando hoy, sabiendo lo que sabemos ahora, no se requerirían ni SOP ni CORS para AJAX y es posible que toda la validación quede en manos del servidor.

WebSockets, al ser una tecnología más nueva, está diseñado para admitir escenarios de dominio cruzado desde el principio. Cualquiera que escriba la lógica del servidor debe ser consciente de la posibilidad de solicitudes de origen cruzado y realizar la validación necesaria, sin la necesidad de tomar precauciones estrictas en el lado del navegador al estilo CORS.

¹ Esta es una simplificación. Las solicitudes de recursos GET de origen cruzado (incluidas las etiquetas <img>, <link> y <script>) y las solicitudes POST de envío de formularios siempre se permitieron como una característica fundamental de la Web. Hoy en día, las llamadas AJAX de origen cruzado cuyas solicitudes tienen las mismas propiedades también están permitidas y se conocen como solicitudes simples de origen cruzado . Sin embargo, no se permite acceder a los datos devueltos de tales solicitudes en código a menos que lo permitan explícitamente los encabezados CORS del servidor. Además, estas solicitudes POST "simples" son la razón principal por la que los tokens anti-CSRF son necesarios para que los servidores se protejan de sitios web maliciosos.

² De hecho, ni siquiera estaba disponible una forma segura de verificar el origen de la solicitud, ya que el Refererencabezado se puede falsificar, por ejemplo, mediante una vulnerabilidad de redireccionamiento abierto. Esto también muestra cuán mal se entendían las vulnerabilidades CSRF en ese entonces.

oberstet respondió a la pregunta . ¡Gracias! Lamentablemente, no puedo marcarlo como "correcto" porque era un comentario. El navegador envía el encabezado "origen" que puede ser verificado por la aplicación.

En Java [1]:

@Anular
public void onOpen (WebSocket clientSocket, ClientHandshake apretón de manos) {
    String clientOrigin = handshake.getFieldValue ("origen");

    if (clientOrigin == null ||! clientOrigin.equals (WEBSOCKET_ALLOWED_ORIGIN_HEADER)) {
        logger.log (Level.WARNING, "El cliente no envió el encabezado de origen correcto:" + clientOrigin);        

        clientSocket.close ();
        regreso;
    }

    // ...
}

[1] usando https://github.com/TooTallNate/Java-WebSocket

Los WebSockets pueden comunicarse entre dominios y no están limitados por el SOP (Política del mismo origen).

El mismo problema de seguridad que describió puede ocurrir sin WebSockets.

El malvado JS puede:

• Cree una etiqueta de secuencia de comandos / imagen con una URL a evil.tld y coloque los datos en la cadena de consulta.
• Cree una etiqueta de formulario, coloque los datos en los campos e invoque la acción "enviar" del formulario, haciendo un HTTP POST, que puede ser de dominio cruzado. AJAX está limitado por el SOP, pero HTTP POST normal no lo está. Verifique el problema de seguridad web XSRF.

Si algo inyecta javascript en su página, o obtiene javascript malicioso, su seguridad ya está rota.