javascript - nodejs - ¿Por qué no hay una política de origen igual para WebSockets? ¿Por qué me puedo conectar a ws:// localhost?
websocket nodejs (3)
Los WebSockets pueden cruzar la comunicación de dominio, y no están limitados por el SOP (Política de Mismo Origen).
El mismo problema de seguridad que describió puede suceder sin WebSockets.
El malvado JS puede:
- Cree una etiqueta de script / imagen con una URL para evil.tld y coloque 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á. Compruebe el problema de seguridad web de XSRF.
Si algo inyecta javascript en su página, o si obtiene javascript malicioso, su seguridad ya está rota.
Me gustaría usar WebSockets para la comunicación entre procesos para mi aplicación (Daemon <-> WebGUI y Daemon <-> FatClient, etc.). Durante las pruebas, traté de conectarme a mi servidor de socket web en ejecución local (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)?
Lo estoy preguntando porque si websocket.org era malo, podría tratar de comunicarse con mi servidor WS local y redirigir todos los mensajes que reciba del servidor local a cualquier otro servidor:
Local WebSocket Server Browser Evil Web Server at ws://localhost:1234 at http://evil.tld | | | | |------[GET /]--------->| | |<-----[HTML+EvilJS]----| |<------[connect ws://..]----| | |<----[some communication]-->| | | |----[evil forward]---->| | | |
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 cual los navegadores no aplican la Política de Mismo Origen (de la cual CORS es una relajación) para WebSockets en oposición a 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 Para empezar, no está sujeto a SOP, la razón histórica para los controles CORS del lado del cliente 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 1 , y por lo tanto no necesitaban asegurarse de que la solicitud provenía de una ubicación confiable 2 . Las relajaciones posteriores como CORS tuvieron que tener controles del lado del cliente para evitar exponer las aplicaciones existentes al abuso al violar esta suposición (realizar un ataque CSRF de forma efectiva).
Si la Web se estuviera inventando hoy, sabiendo lo que sabemos ahora, no se necesitarían SOP ni CORS para AJAX y es posible que toda la validación se deje al servidor.
WebSockets, al ser una tecnología más nueva, está diseñada para admitir escenarios entre dominios desde el primer momento. Cualquier persona que escriba la lógica del servidor debe tener en cuenta la posibilidad de solicitudes de origen cruzado y realizar la validación necesaria, sin la necesidad de precauciones severas del lado del navegador a la CORS.
1 Esto es una simplificación. Las solicitudes GET de origen cruzado para recursos (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. En la actualidad, las llamadas AJAX de origen cruzado cuyas solicitudes tienen las mismas propiedades también se permiten y se conocen como solicitudes cruzadas de origen . Sin embargo, no se permite el acceso a los datos devueltos de tales solicitudes en el código a menos que esté explícitamente permitido por los encabezados CORS del servidor. Además, son estas solicitudes POST "simples" las principales razones por las cuales los tokens anti-CSRF son necesarios para que los servidores se protejan de los sitios web maliciosos.
2 De hecho, una forma segura de verificar el origen de la solicitud ni siquiera estaba disponible, ya que el encabezado Referer puede ser falso, por ejemplo, usando una vulnerabilidad de redirección abierta. Esto también muestra cuán poco se entendían las vulnerabilidades CSRF en ese momento.
oberstet respondió la pregunta . ¡Gracias! Desafortunadamente no puedo marcarlo como "correcto" porque fue un comentario. El navegador envía el encabezado "origen" que la aplicación puede verificar.
En Java [1]:
@Override public void onOpen(WebSocket clientSocket, ClientHandshake handshake) { String clientOrigin = handshake.getFieldValue("origin"); if (clientOrigin == null || !clientOrigin.equals(WEBSOCKET_ALLOWED_ORIGIN_HEADER)) { logger.log(Level.WARNING, "Client did not sent correct origin header: " + clientOrigin); clientSocket.close(); return; } // ... }