¿Qué caracteres deben escaparse o reemplazarse para evitar ataques de devolución de llamada xss jsonp?

Question

¿Qué caracteres deben escaparse o reemplazarse para evitar ataques de devolución de llamada xss jsonp?

#1 de Conor Mancone (2 votos)

1

Tengo un servicio que le permite al usuario especificar un nombre de función de devolución de llamada que ajusta los datos que se devuelven para respaldar las devoluciones de llamada jsonp. Quiero asegurarme de que estoy cubriendo todas mis bases con respecto a la prevención de ataques XSS.

Nota, he leído la Lista de verificación de seguridad OWASP pero ninguna de las recomendaciones parece Dirigir directamente esta pregunta.

Estos son los métodos actualmente soportados para especificar la función jsonp donde el nombre de la función es cbFn y cbFn se declara solo, un método en un objeto, o al que se accede desde un objeto / matriz:

https://service.com/cbFn
https://service.com/?callback=cbFn
https://service.com/?callback=obj.cbFn
https://service.com/?callback=obj['cbFn']
https://service.com/?callback=obj[1]

Estos vuelven:

cbFn({data: 'data being returned'})
obj.cbFn({data: 'data being returned'})
obj['cbFn']({data: 'data being returned'})
obj[1]({data: 'data being returned'})

Sin embargo, las siguientes solicitudes también funcionan y son los problemas conocidos de XSS que quiero evitar:

// executes an anonymous function
https://service.com/?callback=(()=%3E{alert(1)})
// replaces the user's callback function with our own
https://service.com/?callback=cbFn=((data)=>{alert(data)})

¿Es suficiente simplemente reemplazar / eliminar los caracteres ()=> en el nombre de devolución de llamada para evitar vulnerabilidades de XSS? Quiero permitir el conjunto de caracteres de javascript válido completo para los nombres de funciones, por lo que restringir el rango de caracteres válido a /[$_\w]+/ (alfanumérico más $ y _) no parece ser una buena opción.

xss javascript

pregunta Geuis 25.08.2018 - 22:07

fuente

1 respuesta

Lea otras preguntas en las etiquetas xss javascript

Cómo determinar si el ejecutable de Windows 10 puede conectarse a mi red ¿Necesito Gateway Firewall para la red IoT? [cerrado]

score 2 · Answer 1

Parece que está preguntando desde el contexto del proveedor de servicios que protege a un cliente remoto, en cuyo caso la respuesta es simple:

Como proveedor de servicios, no puede protegerse contra XSS en absoluto, y tampoco debería molestarse

Ten en cuenta que normalmente soy grande en "defensa en profundidad" y en poner barreras de seguridad en cada paso del camino. Sin embargo, creo que este es uno de los pocos lugares en los que no merece la pena preocuparse por su preocupación. Hay dos razones por las que:

1. Bajo el uso normal, el cliente que ejecuta la aplicación tiene control total sobre la solicitud, por lo que no hay razón para esperar cargas útiles como esta

En realidad, no hay mucho más que decir sobre esto, porque esto no es lo que te preocupa. Pero solo para decirlo en voz alta: el propio cliente está proporcionando la devolución de llamada JSONP, y si eligen pedirle que devuelva el javascript real, entonces no hay muchas razones para que lo detenga (especialmente porque hacerlo sería tonto y dudo que alguien se moleste). La única vez que alguien puede solicitar una devolución de llamada "peligrosa" de su servidor es si el cliente remoto ha tenido una violación de XSS y un javascript malicioso se ha hecho cargo de su sistema. Sin embargo, si eso sucede:

2. El javascript malicioso tiene control total sobre el cliente remoto y no necesita que ejecutes javascript arbitrario de todas formas

Lo que es igualmente simple: si un atacante ha administrado un ataque XSS contra un cliente que usa su servicio, no tiene que inyectar javascript malicioso en la devolución de llamada. Solo pueden reemplazar el método de devolución de llamada en el cliente local con el suyo propio. De hecho, eso es mucho más fácil. Como resultado, no hay literalmente ninguna razón por la que alguien intente utilizar su servicio como un punto final de inyección XSS en el cliente remoto. En pocas palabras:

Si un atacante ha administrado un ataque XSS contra un cliente que usa su servicio, entonces ya ganó y no tiene ninguna razón para pasar las cargas útiles XSS a su servicio. Simplemente se reflejará en la página que ya han tomado.

Supongo que podría haber algún desarrollador por ahí que haya creado algún esquema loco (peligroso) en el que la entrada del usuario en su sitio se use para crear la devolución de llamada JSONP que se pasa a su servicio, y se convierte en una vulnerabilidad de primer orden XSS . Sin embargo, no hay una razón práctica por la que alguien pueda hacer algo así (habiendo usado muchos de estos tipos de servicios, tendría que esforzarse para configurar algo tan peligroso), tanto que no lo hago. cree que vale la pena dedicar una cantidad de tiempo a proteger a tus usuarios de ese nivel de estupidez. Es más probable que introduzcas accidentalmente efectos secundarios negativos en tus usuarios regulares que en proteger a alguien contra el nivel de planificación deficiente que se requeriría para que esta protección haga lo que quieras.