Coders Conquer Security: Compartir y aprender - Cross-Site Scripting

Publicado el 06 de diciembre de 2018
por Jaap Karan Singh
ESTUDIO DE CASO

Coders Conquer Security: Compartir y aprender - Cross-Site Scripting

Publicado el 06 de diciembre de 2018
por Jaap Karan Singh
Ver recurso
Ver recurso

Puede que los navegadores web sean nuestra puerta de entrada a todo lo bueno que hay en Internet, pero lamentablemente no todo son buenas noticias. El comportamiento inherente de los navegadores web puede ser un catalizador de las vulnerabilidades de seguridad. Los navegadores empezaron confiando en las marcas que veían y las ejecutaban sin cuestionarlas. Eso está muy bien hasta que esa funcionalidad se explota con fines desagradables... y, naturalmente, los atacantes acaban encontrando formas de explotar esta tendencia para promover sus fines malvados.

Cross-site scripting (XSS) utiliza la confianza de los navegadores y la ignorancia de los usuarios para robar datos, apoderarse de las cuentas y desfigurar los sitios web; es una vulnerabilidad que puede ponerse muy fea, muy rápidamente.

Echemos un vistazo a cómo funciona el XSS, qué daño se puede hacer y cómo prevenirlo:

¿Cómo funciona el XSS?

El XSS se produce cuando una entrada no fiable (a menudo datos) se presenta como salida en una página pero se interpreta erróneamente como código ejecutable. Un atacante puede colocar código ejecutable malicioso (etiquetas HTML, JavaScript, etc.) dentro de un parámetro de entrada, que -cuando se devuelve al navegador- se ejecuta en lugar de mostrarse como datos.

Como se ha mencionado anteriormente, la vulnerabilidad apareció debido al comportamiento de funcionamiento básico de los navegadores, donde es difícil distinguir los datos del código ejecutable. El modelo de funcionamiento de la web es el siguiente:

  1. El usuario visita una página web
  2. La página indica al navegador qué archivos debe cargar y qué debe ejecutar
  3. El navegador ejecuta lo que está en la página, sin preguntas

Esta funcionalidad ha dado lugar a algunas de las experiencias más impresionantes e interactivas que disfrutamos en la web. La otra cara de la moneda es que también ha dado lugar a costosos exploits y vulnerabilidades.

Cuando los atacantes añaden su script malicioso a un sitio vulnerable, éste se ejecuta sin más. No hay una investigación más profunda, ni medidas de detección.

El código javascript personalizado podría ejecutarse en los navegadores de sus usuarios

Hay tres tipos de XSS:

  • XSS almacenado
  • XSS reflejado
  • DOM XSS

El XSS almacenado ocurre cuando un atacante puede almacenar persistentemente el script malicioso en un campo de datos de la aplicación (por ejemplo, en un campo que almacena el número de teléfono móvil del usuario). Este script malicioso se envía entonces al navegador del usuario cada vez que ese campo de datos se muestra en la aplicación.

Este tipo de ataque se ve a menudo en sitios de foros o motores de comentarios. Un atacante introduce el script malicioso en un comentario, y bam - cada usuario que ve ese comentario ejecuta el script sin saberlo.

El XSS reflejado ocurre cuando la entrada del usuario se refleja en el navegador del usuario tal cual. Un ejemplo es un cuadro de búsqueda que muestra al usuario "Has buscado..." mientras obtiene los resultados de la búsqueda.

Ahora, imagina que la búsqueda funciona colocando el término de búsqueda en la URL como parámetros de consulta. Un atacante malicioso podría enviar a la víctima un enlace con el script malicioso incrustado en esos mismos parámetros y, a decir verdad, la mayoría de los usuarios de la web apenas lo notarían.

La víctima hace clic en el enlace y es redirigida a un sitio de phishing donde, sin saberlo, introduce su contraseña para el sitio. No se dan cuenta de que un atacante acaba de robar la clave de su cuenta.

DOM XSS es una variedad relativamente nueva de esta vulnerabilidad. Se aprovecha de las complejas estructuras de plantillas que se encuentran en muchos marcos de interfaz de usuario como Angular y React.

Estas plantillas permiten contenido dinámico y aplicaciones de interfaz de usuario ricas. Si se utilizan de forma incorrecta, pueden ser utilizadas para ejecutar ataques XSS.

Así que, ahí lo tienes. Ya tienes el alcance del XSS en pocas palabras. Profundicemos en cómo se puede utilizar de forma destructiva.

¿Por qué es tan peligroso el XSS?

El XSS puede utilizarse para redirigir a los usuarios a sitios maliciosos, robar cookies y buscar datos de sesión. Básicamente, todo lo que JavaScript puede hacer, los ataques XSS también son capaces de hacerlo.

Aquí hay tres ejemplos de ataques XSS:

  1. Los usuarios del correo electrónico de Yahoo sufrieron el robo de sus cookies de sesión mediante XSS en 2015.
  2. El gusano Samy se distribuyó a través de una vulnerabilidad XSS en MySpace. Sigue siendo el malware que más rápido se ha propagado de todos los tiempos, afectando a un millón de usuarios en sólo 20 horas.
  3. eBay permitía incluir scripts maliciosos en las descripciones de los productos. Esto llevó a ataques XSS contra los usuarios de eBay.

Los ataques XSS son aparentemente sencillos y muy graves. Pueden conducir al robo de sesiones, credenciales de usuario o datos sensibles. El daño a la reputación y la disminución de los ingresos son los principales escollos de estos ataques. Incluso el simple hecho de desfigurar un sitio web puede acarrear consecuencias indeseables para una empresa.

Sin embargo, el XSS puede ser derrotado por un experto en seguridad como usted. La solución no es complicada y la industria ha recorrido un largo camino desde que el XSS se convirtió en un exploit de uso común.

Se puede vencer el XSS.

La clave para derrotar al XSS es entender el contexto. Específicamente, el contexto en el que la entrada del usuario será devuelta al cliente y dónde será devuelta. Dentro del código HTML, o dentro de un fragmento de JavaScript.

Si la entrada del usuario no tiene que ser enviada de vuelta al navegador, mucho mejor. Pero si es así, a menudo debe ser codificado en HTML. La codificación HTML de la salida le dirá al navegador que debe renderizar el contenido tal cual y no ejecutarlo.

La validación de la entrada también es importante. Sin embargo, la validación y las listas blancas no son soluciones infalibles. La codificación va un poco más allá y evita que los navegadores ejecuten un script malicioso. Cualquier cosa que no se capture con las estrategias de validación y listas blancas, la codificación la recogerá.

Muchos frameworks ahora codifican la salida HTML automáticamente.
Angular, ASP.NET MVC y React.js son frameworks donde se utiliza la codificación HTML por defecto. Tienes que decirle específicamente a estos frameworks que no codifiquen llamando a un método especial.

La mayoría de los otros frameworks, (es decir, Django y Spring) tienen bibliotecas estándar para la prevención de XSS que puedes incorporar fácilmente en tu código.

El mayor desafío es enseñarte a ti mismo a analizar todas las formas en que la entrada del usuario puede entrar en un sistema para que puedas mantener los ojos bien abiertos. Los parámetros de consulta pueden ser portadores de ataques, al igual que los parámetros de entrada. Siga el flujo de datos a través de su aplicación y no confíe en ningún dato que provenga del exterior.

Piense como una patrulla fronteriza. Detenga cada dato, inspecciónelo y no lo deje entrar si parece malicioso. A continuación, codifique al renderizar para asegurarse de que cualquier cosa mala que se haya pasado por alto no cause problemas.

Ejecute estas estrategias y sus usuarios estarán a salvo de los ataques mediante XSS. Echa un vistazo a la hoja de trucos de OWASP para obtener aún más consejos para mantener tus datos bajo control.

Frustre el XSS y aumente sus habilidades de seguridad.

El XSS se encuentra en el número siete de la lista OWASP Top 10 2017 de riesgos de seguridad web. Ha existido durante un tiempo, pero todavía puede aparecer y causar problemas con su aplicación si no se tiene cuidado.

La formación es muy importante para los desarrolladores en la construcción de una mentalidad de seguridad en primer lugar, ya que la elaboración de código. Y esa formación es siempre más eficaz cuando simula aplicaciones reales, en los lenguajes que los desarrolladores utilizan activamente. Teniendo esto en cuenta, ¿por qué no echa un vistazo a nuestros recursos de aprendizaje para aprender más sobre XSS? Después de eso, puede comenzar la formación y la práctica que le llevará a dominar el tema.

¿Cree que está preparado para encontrar y solucionar vulnerabilidades XSS ahora mismo? Desafíate a ti mismo en la plataforma Secure Code Warrior .

Ver recurso
Ver recurso

Autor

Jaap Karan Singh

¿Quieres más?

Sumérjase en nuestras últimas ideas sobre codificación segura en el blog.

Nuestra amplia biblioteca de recursos tiene como objetivo potenciar el enfoque humano de la mejora de la codificación segura.

Ver blog
¿Quieres más?

Obtenga las últimas investigaciones sobre la seguridad impulsada por los desarrolladores

Nuestra amplia biblioteca de recursos está repleta de recursos útiles, desde libros blancos hasta seminarios web, que le ayudarán a iniciarse en la codificación segura orientada a los desarrolladores. Explórela ahora.

Centro de recursos

Coders Conquer Security: Compartir y aprender - Cross-Site Scripting

Publicado el 06 de diciembre de 2018
Por Jaap Karan Singh

Puede que los navegadores web sean nuestra puerta de entrada a todo lo bueno que hay en Internet, pero lamentablemente no todo son buenas noticias. El comportamiento inherente de los navegadores web puede ser un catalizador de las vulnerabilidades de seguridad. Los navegadores empezaron confiando en las marcas que veían y las ejecutaban sin cuestionarlas. Eso está muy bien hasta que esa funcionalidad se explota con fines desagradables... y, naturalmente, los atacantes acaban encontrando formas de explotar esta tendencia para promover sus fines malvados.

Cross-site scripting (XSS) utiliza la confianza de los navegadores y la ignorancia de los usuarios para robar datos, apoderarse de las cuentas y desfigurar los sitios web; es una vulnerabilidad que puede ponerse muy fea, muy rápidamente.

Echemos un vistazo a cómo funciona el XSS, qué daño se puede hacer y cómo prevenirlo:

¿Cómo funciona el XSS?

El XSS se produce cuando una entrada no fiable (a menudo datos) se presenta como salida en una página pero se interpreta erróneamente como código ejecutable. Un atacante puede colocar código ejecutable malicioso (etiquetas HTML, JavaScript, etc.) dentro de un parámetro de entrada, que -cuando se devuelve al navegador- se ejecuta en lugar de mostrarse como datos.

Como se ha mencionado anteriormente, la vulnerabilidad apareció debido al comportamiento de funcionamiento básico de los navegadores, donde es difícil distinguir los datos del código ejecutable. El modelo de funcionamiento de la web es el siguiente:

  1. El usuario visita una página web
  2. La página indica al navegador qué archivos debe cargar y qué debe ejecutar
  3. El navegador ejecuta lo que está en la página, sin preguntas

Esta funcionalidad ha dado lugar a algunas de las experiencias más impresionantes e interactivas que disfrutamos en la web. La otra cara de la moneda es que también ha dado lugar a costosos exploits y vulnerabilidades.

Cuando los atacantes añaden su script malicioso a un sitio vulnerable, éste se ejecuta sin más. No hay una investigación más profunda, ni medidas de detección.

El código javascript personalizado podría ejecutarse en los navegadores de sus usuarios

Hay tres tipos de XSS:

  • XSS almacenado
  • XSS reflejado
  • DOM XSS

El XSS almacenado ocurre cuando un atacante puede almacenar persistentemente el script malicioso en un campo de datos de la aplicación (por ejemplo, en un campo que almacena el número de teléfono móvil del usuario). Este script malicioso se envía entonces al navegador del usuario cada vez que ese campo de datos se muestra en la aplicación.

Este tipo de ataque se ve a menudo en sitios de foros o motores de comentarios. Un atacante introduce el script malicioso en un comentario, y bam - cada usuario que ve ese comentario ejecuta el script sin saberlo.

El XSS reflejado ocurre cuando la entrada del usuario se refleja en el navegador del usuario tal cual. Un ejemplo es un cuadro de búsqueda que muestra al usuario "Has buscado..." mientras obtiene los resultados de la búsqueda.

Ahora, imagina que la búsqueda funciona colocando el término de búsqueda en la URL como parámetros de consulta. Un atacante malicioso podría enviar a la víctima un enlace con el script malicioso incrustado en esos mismos parámetros y, a decir verdad, la mayoría de los usuarios de la web apenas lo notarían.

La víctima hace clic en el enlace y es redirigida a un sitio de phishing donde, sin saberlo, introduce su contraseña para el sitio. No se dan cuenta de que un atacante acaba de robar la clave de su cuenta.

DOM XSS es una variedad relativamente nueva de esta vulnerabilidad. Se aprovecha de las complejas estructuras de plantillas que se encuentran en muchos marcos de interfaz de usuario como Angular y React.

Estas plantillas permiten contenido dinámico y aplicaciones de interfaz de usuario ricas. Si se utilizan de forma incorrecta, pueden ser utilizadas para ejecutar ataques XSS.

Así que, ahí lo tienes. Ya tienes el alcance del XSS en pocas palabras. Profundicemos en cómo se puede utilizar de forma destructiva.

¿Por qué es tan peligroso el XSS?

El XSS puede utilizarse para redirigir a los usuarios a sitios maliciosos, robar cookies y buscar datos de sesión. Básicamente, todo lo que JavaScript puede hacer, los ataques XSS también son capaces de hacerlo.

Aquí hay tres ejemplos de ataques XSS:

  1. Los usuarios del correo electrónico de Yahoo sufrieron el robo de sus cookies de sesión mediante XSS en 2015.
  2. El gusano Samy se distribuyó a través de una vulnerabilidad XSS en MySpace. Sigue siendo el malware que más rápido se ha propagado de todos los tiempos, afectando a un millón de usuarios en sólo 20 horas.
  3. eBay permitía incluir scripts maliciosos en las descripciones de los productos. Esto llevó a ataques XSS contra los usuarios de eBay.

Los ataques XSS son aparentemente sencillos y muy graves. Pueden conducir al robo de sesiones, credenciales de usuario o datos sensibles. El daño a la reputación y la disminución de los ingresos son los principales escollos de estos ataques. Incluso el simple hecho de desfigurar un sitio web puede acarrear consecuencias indeseables para una empresa.

Sin embargo, el XSS puede ser derrotado por un experto en seguridad como usted. La solución no es complicada y la industria ha recorrido un largo camino desde que el XSS se convirtió en un exploit de uso común.

Se puede vencer el XSS.

La clave para derrotar al XSS es entender el contexto. Específicamente, el contexto en el que la entrada del usuario será devuelta al cliente y dónde será devuelta. Dentro del código HTML, o dentro de un fragmento de JavaScript.

Si la entrada del usuario no tiene que ser enviada de vuelta al navegador, mucho mejor. Pero si es así, a menudo debe ser codificado en HTML. La codificación HTML de la salida le dirá al navegador que debe renderizar el contenido tal cual y no ejecutarlo.

La validación de la entrada también es importante. Sin embargo, la validación y las listas blancas no son soluciones infalibles. La codificación va un poco más allá y evita que los navegadores ejecuten un script malicioso. Cualquier cosa que no se capture con las estrategias de validación y listas blancas, la codificación la recogerá.

Muchos frameworks ahora codifican la salida HTML automáticamente.
Angular, ASP.NET MVC y React.js son frameworks donde se utiliza la codificación HTML por defecto. Tienes que decirle específicamente a estos frameworks que no codifiquen llamando a un método especial.

La mayoría de los otros frameworks, (es decir, Django y Spring) tienen bibliotecas estándar para la prevención de XSS que puedes incorporar fácilmente en tu código.

El mayor desafío es enseñarte a ti mismo a analizar todas las formas en que la entrada del usuario puede entrar en un sistema para que puedas mantener los ojos bien abiertos. Los parámetros de consulta pueden ser portadores de ataques, al igual que los parámetros de entrada. Siga el flujo de datos a través de su aplicación y no confíe en ningún dato que provenga del exterior.

Piense como una patrulla fronteriza. Detenga cada dato, inspecciónelo y no lo deje entrar si parece malicioso. A continuación, codifique al renderizar para asegurarse de que cualquier cosa mala que se haya pasado por alto no cause problemas.

Ejecute estas estrategias y sus usuarios estarán a salvo de los ataques mediante XSS. Echa un vistazo a la hoja de trucos de OWASP para obtener aún más consejos para mantener tus datos bajo control.

Frustre el XSS y aumente sus habilidades de seguridad.

El XSS se encuentra en el número siete de la lista OWASP Top 10 2017 de riesgos de seguridad web. Ha existido durante un tiempo, pero todavía puede aparecer y causar problemas con su aplicación si no se tiene cuidado.

La formación es muy importante para los desarrolladores en la construcción de una mentalidad de seguridad en primer lugar, ya que la elaboración de código. Y esa formación es siempre más eficaz cuando simula aplicaciones reales, en los lenguajes que los desarrolladores utilizan activamente. Teniendo esto en cuenta, ¿por qué no echa un vistazo a nuestros recursos de aprendizaje para aprender más sobre XSS? Después de eso, puede comenzar la formación y la práctica que le llevará a dominar el tema.

¿Cree que está preparado para encontrar y solucionar vulnerabilidades XSS ahora mismo? Desafíate a ti mismo en la plataforma Secure Code Warrior .

Nos gustaría contar con su permiso para enviarle información sobre nuestros productos y/o temas relacionados con la codificación segura. Siempre trataremos sus datos personales con el máximo cuidado y nunca los venderemos a otras empresas con fines de marketing.

Para enviar el formulario, habilite las cookies "Analytics". Siéntase libre de desactivarlas de nuevo una vez que haya terminado.