Mis colegas afirman que XSS es una vulnerabilidad en el lado del servidor. Siempre pensé que esto es una vulnerabilidad del lado del cliente. ¿Cuál de nosotros es correcto y por qué?
En un ataque de scripts entre sitios, el script malicioso se ejecuta en el cliente, pero el defecto real está en la aplicación. Eso no significa necesariamente que sea una vulnerabilidad estrictamente del servidor, ya que la falla podría estar en el JavaScript de la aplicación, pero en general, está de hecho en el código del lado del servidor y siempre en el código que entrega el servidor.
Hay mitigaciones en el lado del cliente, como XSS-Protection que ahora está integrada en los principales navegadores o complementos que impiden la ejecución de JavaScript, pero en última instancia XSS es una vulnerabilidad de la aplicación web y debe ser corregida por la aplicación desarrolladores
Debo mencionar que hay otra forma de XSS que no explota fallas en el cliente (el navegador) ni fallas en el servidor (la aplicación) sino fallas en el usuario. Esto a menudo se llama Self-XSS, y explota la disposición de un usuario inepto para ejecutar JavaScript que ha copiado y pegado desde Internet y en la consola de herramientas del desarrollador de su navegador, únicamente en base a la promesa que, contra toda esperanza, mágicamente permitirá que lea las publicaciones de su ex novia en Facebook a pesar de que ella no tiene amigos y lo ha bloqueado.
Se manifiesta en el lado del cliente, pero eso se debe a que la aplicación web lo permite. La aplicación no valida el código que envía al navegador. Y es por eso que es una vulnerabilidad del lado del servidor. Piensa en ello de esta manera. ¿Qué harías para solucionar el problema de XSS? ¿Arreglar el código del lado del servidor o arreglar el navegador?
Los ataques de scripts entre sitios (XSS) generalmente se pueden clasificar como uno de los siguientes:
El ataque en sí mismo está teniendo lugar en el cliente. Los tres tipos de ataques podrían manifestarse completamente en el navegador en el caso de una sola página o una aplicación sin conexión. Sin embargo, si los datos se almacenan en el servidor o se reflejan en el servidor, entonces el servidor está ayudando en la vulnerabilidad.
IE8 presentó X -XSS-Protection , que hizo que los ataques reflejados fueran más difíciles de explotar.
La terminología es un poco resbaladiza, pero generalmente un "error XSS" es una vulnerabilidad del lado del cliente de una vulnerabilidad del lado del servidor .
Los scripts entre sitios no son, en sí mismos, un problema de seguridad . El problema es que puede suceder sin el conocimiento del usuario final. La mayoría de los sitios no están codificados para que esto suceda, por supuesto: o bien no usan en absoluto scripts entre sitios, o dejan claro que esto es lo que están haciendo. Pero si los usuarios pueden publicar su propio contenido, entonces debe evitar que agreguen etiquetas de script arbitrarias a las páginas . De lo contrario, podrían deslizar cosas en la página que envía datos a quién sabe dónde.
Para evitar esto, debe analizar el contenido creado por el usuario y luego generar un HTML "limpio" para la visualización que no tenga las etiquetas que no desea (como las etiquetas de script). Algunos sitios aprovechan esta oportunidad para que los usuarios creen su contenido en un idioma que no sea HTML: Stack Exchange utiliza Markdown. Pero siempre que aún analices el contenido correctamente , también puedes utilizar HTML como idioma de entrada. No hay beneficios en el rendimiento si se realiza correctamente HTML a HTML, ya que pasa por el mismo tipo de ciclo de análisis / generación que otros lenguajes, pero es un lenguaje menos que los desarrolladores (y posiblemente los usuarios) pueden aprender. Sin embargo, tiene que resistir la tentación de simplemente reutilizar el contenido HTML como está o hacer algunas sustituciones de cadenas ligeras en lugar de un ciclo de análisis / generación.
Un "error XSS" es lo que sucede cuando las personas descubren cómo publicar HTML arbitrario en el sitio . Por lo general, esto sucede cuando los desarrolladores utilizan directamente la entrada HTML sin pasar por el ciclo de análisis / generación, pero a veces alguien encuentra una manera de engañar al generador del sitio para que les dé un código HTML que no fue diseñado. De cualquier manera, el resultado final es el mismo: una vez que un usuario puede publicar HTML arbitrario, puede realizar scripts entre sitios con él, y es por eso que lo llamamos un error XSS. Pero el error no está en el propio XSS: está en el código del lado del servidor que permitió la publicación de scripts arbitrarios en primer lugar.
En general, es una buena práctica filtrar tantas cosas como sea posible en el lado del servidor y no en el tamaño del cliente por las siguientes razones:
Un ataque XSS no es muy diferente de una inyección SQL. Ambos son causados por no controlar la entrada del usuario correctamente. Los ataques XSS generalmente se almacenan en su base de datos y se distribuyen a través de su sistema a sus clientes.
El filtrado de los ataques XSS se debe realizar en la entrada del usuario. Generalmente, no debe aceptar ningún tipo de entrada de Javascript. Si requiere absolutamente que sus clientes puedan ingresar Javascript, en el caso de que, por ejemplo, los sitios de programación, debe escapar primero.
Espero que haya ayudado. Recomiendo esta lectura para más información: enlace
He leído a algunas personas que se preocupan por no usar la URL o lo que sea para cargar información de usuario diferente o lo que sea (como las que se encuentran en el tutorial de Google - enlace )
Aunque es bueno tenerlo en cuenta, debe recordar que cada función y pieza de código en el lado del cliente pueden ejecutarse de manera arbitraria. La validación y protección para XSS proviene del servidor. Quiero decir, piénsalo, puedes abrir la consola misma.
La idea es la inyección de código malicioso del cliente que termina siendo una vulnerabilidad en el servidor. Esto puede hacer que los otros clientes reciban páginas web con scripts de mierda incrustados en ellos. Piense en un foro: si acaba de guardar y renderizar etiquetas en esa publicación, alguien que usted hizo podría estar ejecutando un código arbitrario para quien vea esa publicación en el foro.
Por ejemplo, si stackoverflow no se escapó correctamente, probablemente habrías sido redirigido a google.com con la siguiente información
window.location.href = ' enlace ' (Imagine que está rodeado de etiquetas de script, SE las formatea y es demasiado perezosa para escapar de ellas)
Es una vulnerabilidad del lado del servidor que puede ser explotada a través de aplicaciones del lado del cliente.
"Básicamente, un atacante al crear un correo electrónico con un formato especial puede incrustar JavaScript para que el script se ejecute en el navegador de la víctima cuando se vea el correo electrónico en el correo de Yahoo", dijo Pynnonen en un correo electrónico a Threatpost. "El atacante no necesitaba acceso especial. De hecho, el ataque puede llevarse a cabo sin siquiera registrarse en Yahoo Mail. Solo se necesita la dirección de correo electrónico de Yahoo de la víctima ".
En una descripción de la vulnerabilidad publicada el jueves, Pynnonen explicó cómo podría dar formato a un correo electrónico con atributos de datos maliciosos que podrían pasar el JavaScript malicioso a los filtros de Yahoo que se ejecutan al abusar de la forma en que Yahoo Mail muestra los enlaces a sitios incluidos en listas blancas como YouTube. . [enter preformatted text here][1]
Al contrario de lo que muchos otros creen, xss es tanto del lado del cliente como del lado del servidor.
Un xss persistente es del lado del servidor, ya que el servidor almacena el código que se ejecutará en el cliente. Cuando no es persistente, se considera del lado del cliente, ya que el cliente solo puede obtener el resultado a través de esa entrada
¿Tiene sentido?
Lea otras preguntas en las etiquetas web-application xss