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
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
El movimiento Secure-by-Design es el futuro del desarrollo de software seguro. Conozca los elementos clave que las empresas deben tener en cuenta cuando piensan en una iniciativa Secure-by-Design.
DigitalOcean reduce su deuda de seguridad con Secure Code Warrior
El uso por parte de DigitalOcean de la formación Secure Code Warrior ha reducido significativamente la deuda de seguridad, permitiendo a los equipos centrarse más en la innovación y la productividad. La mejora de la seguridad ha reforzado la calidad de sus productos y su ventaja competitiva. De cara al futuro, SCW Trust Score les ayudará a seguir mejorando las prácticas de seguridad y a continuar impulsando la innovación.
Recursos para empezar
La puntuación de confianza revela el valor de las iniciativas de mejora de la seguridad mediante el diseño
Nuestra investigación ha demostrado que la formación en código seguro funciona. Trust Score, que utiliza un algoritmo basado en más de 20 millones de puntos de datos de aprendizaje procedentes del trabajo de más de 250 000 alumnos en más de 600 organizaciones, revela su eficacia a la hora de reducir las vulnerabilidades y cómo hacer que la iniciativa sea aún más eficaz.
.png)
Seguridad reactiva frente a seguridad preventiva: Prevenir es mejor que curar
La idea de introducir la seguridad preventiva en el código y los sistemas heredados al mismo tiempo que en las aplicaciones más recientes puede parecer desalentadora, pero un planteamiento basado en el diseño seguro, aplicado mediante la mejora de las competencias de los desarrolladores, puede aplicar las mejores prácticas de seguridad a esos sistemas. Es la mejor oportunidad que tienen muchas organizaciones de mejorar su seguridad.
Ventajas de la evaluación comparativa de las competencias de seguridad de los desarrolladores
La creciente atención que se presta al código seguro y a los principios del diseño seguro exige que los desarrolladores reciban formación en ciberseguridad desde el principio del proceso de desarrollo de software, con herramientas como Secure Code Warrior's Trust Score, que ayudan a medir y mejorar sus progresos.
Impulsando iniciativas de seguridad por diseño para empresas con éxito significativo
Nuestro último documento de investigación, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise, es el resultado de un análisis profundo de iniciativas reales de Secure-by-Design a nivel empresarial y de la derivación de enfoques de mejores prácticas basados en hallazgos basados en datos.
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.
