Los programadores conquistan la seguridad: Compartir y aprender - Cross-Site Scripting (XSS)
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:
- El usuario visita una página web
- La página indica al navegador qué archivos debe cargar y qué debe ejecutar
- 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.
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:
- Los usuarios del correo electrónico de Yahoo sufrieron el robo de sus cookies de sesión mediante XSS en 2015.
- 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.
- 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 .
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.
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
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.
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:
- El usuario visita una página web
- La página indica al navegador qué archivos debe cargar y qué debe ejecutar
- 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.
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:
- Los usuarios del correo electrónico de Yahoo sufrieron el robo de sus cookies de sesión mediante XSS en 2015.
- 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.
- 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 .
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:
- El usuario visita una página web
- La página indica al navegador qué archivos debe cargar y qué debe ejecutar
- 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.
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:
- Los usuarios del correo electrónico de Yahoo sufrieron el robo de sus cookies de sesión mediante XSS en 2015.
- 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.
- 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 .
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
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.
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:
- El usuario visita una página web
- La página indica al navegador qué archivos debe cargar y qué debe ejecutar
- 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.
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:
- Los usuarios del correo electrónico de Yahoo sufrieron el robo de sus cookies de sesión mediante XSS en 2015.
- 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.
- 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
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ónDescargarRecursos para empezar
Modelado de amenazas con IA: convertir a cada desarrollador en un modelador de amenazas
Saldrá mejor equipado para ayudar a los desarrolladores a combinar ideas y técnicas de modelado de amenazas con las herramientas de IA que ya utilizan para reforzar la seguridad, mejorar la colaboración y crear software más resistente desde el principio.
.png)
.png)
El poder de la marca en AppSec DevSec DevSecOps (¿Qué hay en un acrónimo?)
En AppSec, el impacto duradero de un programa exige algo más que tecnología: necesita una marca fuerte. Una identidad poderosa garantiza que sus iniciativas resuenen e impulsen un compromiso sostenido dentro de su comunidad de desarrolladores.
Recursos para empezar
¡Adopte RÁPIDAMENTE la IA Agéntica en el Desarrollo de Software! (Spoiler: Probablemente no deberías.)
¿Va el mundo de la ciberseguridad demasiado rápido con la IA agéntica? El futuro de la seguridad de la IA ya está aquí, y es hora de que los expertos pasen de la reflexión a la realidad.
Resolver la crisis de visibilidad: cómo Trust Agent salva la distancia entre aprendizaje y código
Trust Agent de Secure Code Warrior resuelve la crisis de la codificación segura, validando la competencia de los desarrolladores en cada commit. Descubre a todos los colaboradores y automatiza la gobernanza en su flujo de trabajo de desarrollo.
Recuperar el pensamiento crítico en el desarrollo seguro de software mejorado con IA
El debate sobre la IA no gira en torno al uso, sino a la aplicación. Descubra cómo equilibrar la necesidad de aumentar la productividad de la IA con una seguridad sólida confiando en desarrolladores que conozcan a fondo su código.
Asistentes de codificación de IA: La máxima productividad conlleva mayores riesgos
En nuestro último libro blanco, nuestros cofundadores Pieter Danhieux y el Dr. Matias Madou, Ph.D., exploran el arma de doble filo que son los Asistentes de Codificación de IA y cómo pueden ser una adición bienvenida y una importante responsabilidad de seguridad al mismo tiempo.
Codificación orientada al desarrollador.
Con seguridad.
Póngase en contacto con nosotros hoy mismo y haga de la seguridad del software una parte intrínseca de su proceso de desarrollo.
