Signal R-Un inciso entre el 3-1 y 3-2

Tras esta cita mía por twitter, para informar de las alusiones en el anterior post a Luis

Está mañana se monta un bonita conversación que por favor no dejes de leer y sobre todo vuelve y sigue leyendo.

https://twitter.com/luisruizpavon/status/436770399620456448

Según el equipo de SignalR no debemos de validar en el servidor y si en cada cliente, copio cita literal de la documentación.

Safely handling input from clients

To ensure that a malicious user does not send script to other users, you must encode all input from clients that is intended for broadcast to other clients. You should encode messages on the receiving clients rather than the server, because your SignalR application may have many different types of clients. Therefore, HTML-encoding works for a web client, but not for other types of clients. For example, a web client method to display a chat message would safely handle the user name and message by calling the html() function.

chat.client.addMessageToPage = function (name, message) {
    // Html encode display name and message. 
    var encodedName = $('<div />').text(name).html();
    var encodedMsg = $('<div />').text(message).html();
    // Add the message to the page. 
    $('#discussion').append('<li><strong>' + encodedName
        + '</strong>:  ' + encodedMsg + '</li>');
};

Lo primero es que me parece un ejemplo malísimo de sanitización, puesto que convertir a texto lo que el usuario me está demandando como texto enriquecido/html es cuando poco saltarte a la torera lo que el usuario espera de tu aplicación, que no es otra cosa que un chat con video,link,imagenes, etc….

Ahora si para curarte lo que haces es matar todas esas funcionalidades como que ….

Es por eso por lo que en el anterior post SignalR 3 de 1 escribí este párrafo.

Es más las herramientas AntiXss de MVC y he buscado y probado alguna que otra o son muy restrictivas o bien alguna que otra cosa se comen el ataque y por tanto siempre estás con el miedo en el cuerpo.

En este caso el ejemplo es eso muy restrictivo, aunque se sigue comiendo el constructor.constructor(alert(1)) y sigo diciendo lo mismo. Que depende de donde hagas el binding será o no peligroso.

Os pongo un ejemplo, absurdo pero que a cualquiera se le puede ocurrir ponerlo en marcha con un dato que dependa de una entrada.

image

Ahora solo tienes que pulsar en cada una de las entradas de tu chat capado de funcionalidades y sanitizado para comerte otro ataque de Fernandito.

Evidentemente que tu eres muy malo, como desarrollador y es por eso por lo que has dejado una puerta abierta que otro está aprovechando, pero nadie te está informando de todos los posibles errores que puedes cometer y como dije es tu obligación y no de SignalR. Solo que me siento contento de haberlo dicho tan claro y tan alto (SIGNALR NO TIENE NINGUNA PROTECCIÓN ANTIXSS Y MVC LA QUE TIENE NO ES BUENA).

Si ya habéis leído la conversación de twitter, yo abogo por hacer esto en el servidor y no en el cliente y os cuento el porque.

El UsuarioA tiene la app en un teléfono y el UsuarioB en un pagina web, según nos recomienda el equipo deberías de sanititzar en el teléfono y en la web y dejar que te entre a tu servidor cualquier tipo de código.

Y en un principio te puede parecer lógico, pero que ocurre si tu chat también tiene la posibilidad de enviar a terceros usuarios fuera de tu organización los mensajes recibidos por correo electrónico, siguiendo con la propuesta del equipo tu estás expandiendo código malicioso sin darte cuenta y que dependerá que el tercer usuario se vea afectado según que aplicación lo está recibiendo.

La preguntas que te deberías de hacer es

1-¿Ese tercero está protegido?

2-¿Conoces las herramientas que utiliza esa otra persona?

3-¿Vas a sanitizar en tres puntos Telefono,Web y Servidor(antes de enviar el mensaje?

No ves más lógico hacerlo en un punto y curarte en salud, pero que ocurre que hacer una librería AntiXss y prevenir todos los casos como poco es costosa y muy difícil de mantener. Y yo en el caso del equipo de SignalR hubiese hecho lo mismo, solo les puedo reprochar que en la página web y al principio en rojo y muy grande ponga

“CUIDADO QUE NO ESTAMOS CUBRIENDO TODOS ESTOS POSIBLES PROBLEMAS”

Conclusiones

Simplemente es una aclaración y que me importa bastante poco lo que me diga una fuente y me da lo mismo su procedencia sin previo análisis de lo que puede ocurrir.

Ya habéis visto que ni siquiera la propuesta es buena (simplemente es un ejemplo dirán algunos,xDDDD).

Y yo respondo si, pero uno que van a copiar seguro miles de personas.

Así que utiliza SignalR como buena herramienta que es y protégete de AntiXss siempre y en el servidor, ya os he puesto un ejemplo donde la propuesta del equipo se queda sin fundamentos.

 

2 comentarios sobre “Signal R-Un inciso entre el 3-1 y 3-2”

  1. «Así que utiliza SignalR como buena herramienta que es y protégete de AntiXss siempre y en el servidor, ya os he puesto un ejemplo donde la propuesta del equipo se queda sin fundamentos.»

    Pedro, una cosa.

    Me pierdo un poco o bastante leyéndote últimamente, porque entre tanta historia, palabros y bits todos mezclados en un tutti frutti estoy algo perdido, pero si en verdad has encontrado algo que no es correcto o no está bien, o tienes algo que sugerir, esto de escribirlo en tu blog está genial, y discutirlo en Twitter, pues bueno, no es la plataforma para eso pero bien también, sin problemas… sin embargo, harías un gran favor a la comunidad si expusieras todo esto al equipo de trabajo de SignalR de Microsoft.

    Yo no lo voy a hacer porque no me he enterado al final mucho de la historia, pero me quedo con tu última frase y sobre todo el «…donde la propuesta del equipo se queda sin fundamentos».

    Un saludete.

  2. El problema principal que le veo en satinizar en servidor una aplicación con distintos tipos de clientes es que constructor.constructor(alert(‘skynet’)) es una vulnerabilidad en un cliente web, pero no lo será en un cliente de escritorio p. ej.
    Y porque la interpretación de los datos depende del contexto.
    Y porque depende del escenario puede ser mejor satinizar en cliente o en servidor…

    Saludos!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *