コーダーがセキュリティを征服:共有して学ぶ-クロスサイトスクリプティング (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 .
クロスサイトスクリプティング (XSS) は、ブラウザーの信頼とユーザーの無知を利用して、データを盗んだり、アカウントを乗っ取ったり、ウェブサイトを改ざんしたりします。この脆弱性は、あっという間にひどいものになってしまいます。XSS の仕組み、どのような被害が及ぶ可能性があるか、そしてそれを防ぐ方法を見ていきましょう。
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Secure Code Warrior le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al código inseguro.
Reservar una demostración
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
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 para descargar el PDF de este recurso.
Secure Code Warrior le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al código inseguro.
Mostrar informeReservar una demostración
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
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は、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Secure Code Warrior le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al código inseguro.
Reservar una demostración[Descargar]Recursos para empezar
Temas y contenidos de la formación en código seguro
Nuestro contenido, líder en el sector, evoluciona constantemente para adaptarse al entorno de desarrollo de software en constante cambio, teniendo siempre en cuenta las funciones de nuestros clientes. Abarca todo tipo de temas, desde la inteligencia artificial hasta la inyección de XQuery, y está diseñado para satisfacer las necesidades de diversos perfiles, desde arquitectos e ingenieros hasta gestores de productos y responsables de control de calidad. Echemos un vistazo al contenido que ofrece nuestro catálogo, clasificado por temas y funciones.
La Cámara de Comercio establece el estándar para la seguridad impulsada por desarrolladores a gran escala
Kamer van Koophandel comparte cómo ha integrado la codificación segura en el desarrollo diario mediante certificaciones basadas en roles, evaluaciones comparativas de Trust Score y una cultura de responsabilidad compartida en materia de seguridad.
%20(1).avif)
.avif)
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.
Recursos para empezar
Cybermon ha vuelto: la misión de IA para derrotar al jefe ya está disponible bajo demanda.
Ahora se puede jugar a «Cybermon 2025 Beat the Boss» en SCW durante todo el año. Introduzca retos de seguridad avanzados de IA/LLM y refuerce a gran escala el desarrollo seguro de la IA.
Explicación de la Ley de Resiliencia Cibernética: su significado para el desarrollo de software seguro desde el diseño
Descubra qué exige la Ley de Resiliencia Cibernética (CRA) de la UE, a quién se aplica y cómo puede prepararse el equipo de ingeniería para las prácticas de seguridad desde el diseño, la prevención de vulnerabilidades y el desarrollo de las capacidades de los desarrolladores.
Enable 1: Criterios de éxito predefinidos y medibles
Enabler 1 es la primera parte de la serie Enablers of Success, compuesta por diez partes, y presenta cómo madurar un programa a largo plazo vinculando la codificación segura con resultados empresariales como la reducción de riesgos y la velocidad.
