Blog

Los programadores conquistan la seguridad: Compartir y aprender - Cross-Site Scripting (XSS)

Jaap Karan Singh
Publicado el 25 de septiembre de 2024

Las secuencias de comandos en sitios cruzados (XSS) han sido una pesadilla para los profesionales de la seguridad desde principios de la década de 2000 y, lamentablemente, décadas después, siguen siendo una de las amenazas más comunes a nivel de código. Esta clase de vulnerabilidad de software nos ha acosado durante demasiado tiempo, y una reciente alerta de CISA -como parte de su movimiento Secure-by-Design- pretende frustrarla de una vez por todas. Están en una misión global para eliminar las clases de vulnerabilidad a escala, y este foco en la seguridad impulsada por el desarrollador es algo que realmente puede mover la aguja y marcar la diferencia, pero va a requerir el compromiso de las empresas inteligentes que establecen sus desarrolladores para el éxito de la seguridad.

¿Qué es exactamente el XSS?

Puede que los navegadores web sean nuestra puerta de acceso 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 vulnerabilidades de seguridad. Los navegadores empezaron confiando en las marcas que veían y ejecutándolas sin cuestionarlas. Todo eso está muy bien hasta que esa funcionalidad se explota con fines desagradables... y, naturalmente, los atacantes acaban encontrando formas de aprovechar esta tendencia para promover sus malvados fines.

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

Veamos cómo funciona el XSS, qué daños puede causar 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

El cross-site scripting (XSS) utiliza la confianza de los navegadores y la ignorancia de los usuarios para robar datos, apoderarse de cuentas y desfigurar 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 puede causar y cómo prevenirlo.

¿Quiere saber más?

Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.

Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.

Reservar una demostración
Compartir en:
Autor
Jaap Karan Singh
Publicado el 25 de septiembre de 2024

Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.

Compartir en:

Las secuencias de comandos en sitios cruzados (XSS) han sido una pesadilla para los profesionales de la seguridad desde principios de la década de 2000 y, lamentablemente, décadas después, siguen siendo una de las amenazas más comunes a nivel de código. Esta clase de vulnerabilidad de software nos ha acosado durante demasiado tiempo, y una reciente alerta de CISA -como parte de su movimiento Secure-by-Design- pretende frustrarla de una vez por todas. Están en una misión global para eliminar las clases de vulnerabilidad a escala, y este foco en la seguridad impulsada por el desarrollador es algo que realmente puede mover la aguja y marcar la diferencia, pero va a requerir el compromiso de las empresas inteligentes que establecen sus desarrolladores para el éxito de la seguridad.

¿Qué es exactamente el XSS?

Puede que los navegadores web sean nuestra puerta de acceso 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 vulnerabilidades de seguridad. Los navegadores empezaron confiando en las marcas que veían y ejecutándolas sin cuestionarlas. Todo eso está muy bien hasta que esa funcionalidad se explota con fines desagradables... y, naturalmente, los atacantes acaban encontrando formas de aprovechar esta tendencia para promover sus malvados fines.

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

Veamos cómo funciona el XSS, qué daños puede causar 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

Rellene el siguiente formulario para descargar el informe

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.

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

Las secuencias de comandos en sitios cruzados (XSS) han sido una pesadilla para los profesionales de la seguridad desde principios de la década de 2000 y, lamentablemente, décadas después, siguen siendo una de las amenazas más comunes a nivel de código. Esta clase de vulnerabilidad de software nos ha acosado durante demasiado tiempo, y una reciente alerta de CISA -como parte de su movimiento Secure-by-Design- pretende frustrarla de una vez por todas. Están en una misión global para eliminar las clases de vulnerabilidad a escala, y este foco en la seguridad impulsada por el desarrollador es algo que realmente puede mover la aguja y marcar la diferencia, pero va a requerir el compromiso de las empresas inteligentes que establecen sus desarrolladores para el éxito de la seguridad.

¿Qué es exactamente el XSS?

Puede que los navegadores web sean nuestra puerta de acceso 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 vulnerabilidades de seguridad. Los navegadores empezaron confiando en las marcas que veían y ejecutándolas sin cuestionarlas. Todo eso está muy bien hasta que esa funcionalidad se explota con fines desagradables... y, naturalmente, los atacantes acaban encontrando formas de aprovechar esta tendencia para promover sus malvados fines.

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

Veamos cómo funciona el XSS, qué daños puede causar 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 .

Acceso a recursos

Haga clic en el siguiente enlace y descargue el PDF de este recurso.

Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.

Ver el informeReservar una demostración
Compartir en:
¿Quiere saber más?

Compartir en:
Autor
Jaap Karan Singh
Publicado el 25 de septiembre de 2024

Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.

Compartir en:

Las secuencias de comandos en sitios cruzados (XSS) han sido una pesadilla para los profesionales de la seguridad desde principios de la década de 2000 y, lamentablemente, décadas después, siguen siendo una de las amenazas más comunes a nivel de código. Esta clase de vulnerabilidad de software nos ha acosado durante demasiado tiempo, y una reciente alerta de CISA -como parte de su movimiento Secure-by-Design- pretende frustrarla de una vez por todas. Están en una misión global para eliminar las clases de vulnerabilidad a escala, y este foco en la seguridad impulsada por el desarrollador es algo que realmente puede mover la aguja y marcar la diferencia, pero va a requerir el compromiso de las empresas inteligentes que establecen sus desarrolladores para el éxito de la seguridad.

¿Qué es exactamente el XSS?

Puede que los navegadores web sean nuestra puerta de acceso 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 vulnerabilidades de seguridad. Los navegadores empezaron confiando en las marcas que veían y ejecutándolas sin cuestionarlas. Todo eso está muy bien hasta que esa funcionalidad se explota con fines desagradables... y, naturalmente, los atacantes acaban encontrando formas de aprovechar esta tendencia para promover sus malvados fines.

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

Veamos cómo funciona el XSS, qué daños puede causar 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 .

Índice

Ver recurso
¿Quiere saber más?

Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.

Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.

Reservar una demostraciónDescargar
Compartir en:
Centro de recursos

Recursos para empezar

Más entradas
Centro de recursos

Recursos para empezar

Más entradas