Los programadores conquistan la seguridad: comparta y aprenda: secuencias de comandos entre sitios (XSS)
El cross-site scripting (XSS) ha sido un problema para los profesionales de la seguridad desde principios de la década de 2000 y, lamentablemente, décadas después, todavía se registra como una de las amenazas a nivel de código más comunes. Este tipo de vulnerabilidad de software nos ha plagado durante demasiado tiempo, y recientemente hemos recibido una alerta de CISA - como parte de su movimiento Secure-by-Design - busca frustrarlo de una vez por todas. Su misión global es eliminar las clases de vulnerabilidad a gran escala, y este énfasis en la seguridad impulsada por los desarrolladores es algo que realmente puede hacer avanzar la balanza y marcar la diferencia, pero va a requerir el compromiso de las empresas inteligentes que preparan a sus desarrolladores para lograr el éxito en materia de seguridad.
Entonces, ¿qué es XSS exactamente?
Los navegadores web pueden ser nuestra puerta de entrada a todas esas cosas geniales en línea, pero lamentablemente, no todo son buenas noticias. El comportamiento inherente de los navegadores web puede ser un catalizador para las vulnerabilidades de seguridad. Los navegadores comenzaron confiando de manera característica en el marcado que veían y ejecutándolo sin lugar a dudas. Todo eso está muy bien hasta que esa funcionalidad es explotada con fines poco fiables... y, naturalmente, los atacantes acaban encontrando formas de aprovechar esta tendencia para perseguir sus fines perversos.
Las secuencias de comandos entre sitios utilizan 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ño se puede causar y cómo prevenirlo:
¿Cómo funciona XSS?
El XSS se produce cuando una entrada que no es de confianza (a menudo datos) se representa como salida en una página, pero se interpreta erróneamente como código ejecutable. Un atacante puede colocar código ejecutable malintencionado (etiquetas HTML, JavaScript, etc.) dentro de un parámetro de entrada y, cuando lo devuelve al navegador, se ejecuta en lugar de mostrarse como datos.
Como se mencionó 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 operativo de la web es el siguiente:
- El usuario visita una página web
- La página le dice al navegador qué archivos cargar y qué ejecutar
- El navegador ejecuta lo que está en la página, sin hacer preguntas
Esta funcionalidad ha dado lugar a algunas de las experiencias interactivas más increíbles que disfrutamos en la web. La otra cara de la moneda es que también ha provocado vulnerabilidades y exploits costosos.
Cuando los atacantes añaden su script malicioso a un sitio vulnerable, este se ejecuta sin lugar a dudas. No existe una investigación más profunda ni medidas de detección.
Hay tres tipos de XSS:
- XSS almacenado
- XSS reflejado
- DOM XSS
XSS almacenado se produce cuando un atacante puede almacenar de forma persistente 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). Luego, este script incompleto se envía 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 la secuencia de comandos maliciosa en un comentario y, ¡pum! Todos los usuarios que ven ese comentario sin saberlo ejecutan la secuencia de comandos.
XSS reflejado se produce cuando la entrada del usuario se refleja en el navegador del usuario tal como está. Un ejemplo es un cuadro de búsqueda que muestra al usuario la frase «Has buscado...» mientras obtiene los resultados de la búsqueda.
Ahora, imagine que la búsqueda funciona colocando el término de búsqueda en la URL como parámetros de consulta. Un atacante malintencionado 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 suplantación de identidad donde, sin saberlo, introduce la contraseña del 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. Aprovecha 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 enriquecidas. Si se utilizan de forma incorrecta, se pueden utilizar para ejecutar ataques XSS.
Así que, ahí lo tienes. Tienes el alcance del XSS en pocas palabras. Vamos a profundizar en cómo se puede usar de forma destructiva.
¿Por qué es tan peligroso el XSS?
El XSS se puede utilizar para redirigir a los usuarios a sitios maliciosos, robar cookies y buscar datos de sesión. Básicamente, los ataques XSS también son capaces de hacer cualquier cosa que pueda hacer JavaScript.
Estos son tres ejemplos de ataques XSS:
- Usuarios de correo electrónico de Yahoo les robaron las cookies de sesión usando XSS en 2015.
- El Gusano Samy se distribuyó a través de una vulnerabilidad de XSS en MySpace. Sigue siendo el malware de más rápida propagación de todos los tiempos y afecta a un millón de usuarios en solo 20 horas.
- eBay permitió incluir scripts malintencionados en las descripciones de los productos. Esto llevó a Ataques XSS contra los usuarios de eBay.
Los ataques XSS son engañosamente simples y muy graves. Pueden provocar el robo de sesiones, credenciales de usuario o datos confidenciales. El daño a la reputación y la disminución de los ingresos son los principales escollos de estos ataques. Incluso la simple desfiguración de un sitio web puede tener consecuencias indeseables para una empresa.
Sin embargo, XSS puede ser derrotado por un guerrero de seguridad inteligente como tú. La solución no es complicada y la industria ha recorrido un largo camino desde que XSS se convirtió en un exploit de uso común.
Puedes derrotar a XSS.
La clave para derrotar al XSS es entender el contexto. Concretamente, el contexto en el que la entrada del usuario se devolverá al cliente y en el que se devolverá. Dentro del código HTML o dentro de un fragmento de código de JavaScript.
Si la entrada del usuario no tiene que devolverse al navegador, mucho mejor. Pero si lo es, a menudo debería estar codificado en HTML. La codificación HTML de la salida indicará al navegador que renderice el contenido tal como está y no que lo ejecute.
La validación de los datos introducidos también es importante. Sin embargo, la validación y la creación de listas blancas no son soluciones infalibles. La codificación va unos pasos más allá e impide que los navegadores ejecuten un script malicioso. Lo que no se detecte con las estrategias de validación y creación de listas blancas, la codificación se recuperará.
Muchos marcos ahora codifican automáticamente la salida HTML.
Angular, ASP.NET MVC, y React.js son marcos en los que se utiliza la codificación HTML predeterminada. Debe indicar específicamente a estos marcos que no se codifiquen llamando a un método especial.
La mayoría de los demás marcos, (p. ej. Django y primavera) tienen bibliotecas estándar para la prevención de XSS que puede incorporar fácilmente en su código.
El mayor desafío es aprender a analizar todas las formas en que las entradas de los usuarios pueden entrar en un sistema, de modo que puedas mantener los ojos bien abiertos. Los parámetros de consulta pueden provocar ataques, al igual que los parámetros de las publicaciones. Siga el flujo de datos en toda la aplicación y no confíe en ningún dato que provenga del exterior.
Piensa como la patrulla fronteriza. Detenga todos los datos, inspecciónelos y no permita que ingresen si parecen maliciosos. Luego, codifique al renderizar para asegurarse de que cualquier información mala que se haya omitido aún no cause problemas.
Ejecute estas estrategias y sus usuarios estarán a salvo de los ataques mediante XSS. Eche un vistazo al Hoja de trucos de OWASP para obtener aún más consejos para mantener sus datos bajo control.
Impida el XSS y mejore sus habilidades de seguridad.
XSS ocupa el puesto número siete en la lista de los 10 principales riesgos de seguridad web de 2017 de OWASP. Existe desde hace tiempo, pero puede seguir apareciendo y causar problemas con tu aplicación si no tienes cuidado.
La formación es muy importante para los desarrolladores a la hora de desarrollar una mentalidad en la que la seguridad sea lo primero a la hora de crear código. Además, esa formación siempre es más eficaz cuando simula aplicaciones reales, en los lenguajes que los desarrolladores utilizan activamente. Con eso en mente, ¿por qué no echas un vistazo a nuestro Recursos de aprendizaje para obtener más información sobre XSS? Después de eso, puede comenzar el entrenamiento y la práctica que conduzcan a su dominio.
¿Cree que está listo para encontrar y corregir las vulnerabilidades de XSS ahora mismo? Ponte a prueba en la plataforma Secure Code Warrior.
Las secuencias de comandos entre sitios (XSS) utilizan 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ño puede causar y cómo evitarlo.
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserva una demostración
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
El cross-site scripting (XSS) ha sido un problema para los profesionales de la seguridad desde principios de la década de 2000 y, lamentablemente, décadas después, todavía se registra como una de las amenazas a nivel de código más comunes. Este tipo de vulnerabilidad de software nos ha plagado durante demasiado tiempo, y recientemente hemos recibido una alerta de CISA - como parte de su movimiento Secure-by-Design - busca frustrarlo de una vez por todas. Su misión global es eliminar las clases de vulnerabilidad a gran escala, y este énfasis en la seguridad impulsada por los desarrolladores es algo que realmente puede hacer avanzar la balanza y marcar la diferencia, pero va a requerir el compromiso de las empresas inteligentes que preparan a sus desarrolladores para lograr el éxito en materia de seguridad.
Entonces, ¿qué es XSS exactamente?
Los navegadores web pueden ser nuestra puerta de entrada a todas esas cosas geniales en línea, pero lamentablemente, no todo son buenas noticias. El comportamiento inherente de los navegadores web puede ser un catalizador para las vulnerabilidades de seguridad. Los navegadores comenzaron confiando de manera característica en el marcado que veían y ejecutándolo sin lugar a dudas. Todo eso está muy bien hasta que esa funcionalidad es explotada con fines poco fiables... y, naturalmente, los atacantes acaban encontrando formas de aprovechar esta tendencia para perseguir sus fines perversos.
Las secuencias de comandos entre sitios utilizan 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ño se puede causar y cómo prevenirlo:
¿Cómo funciona XSS?
El XSS se produce cuando una entrada que no es de confianza (a menudo datos) se representa como salida en una página, pero se interpreta erróneamente como código ejecutable. Un atacante puede colocar código ejecutable malintencionado (etiquetas HTML, JavaScript, etc.) dentro de un parámetro de entrada y, cuando lo devuelve al navegador, se ejecuta en lugar de mostrarse como datos.
Como se mencionó 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 operativo de la web es el siguiente:
- El usuario visita una página web
- La página le dice al navegador qué archivos cargar y qué ejecutar
- El navegador ejecuta lo que está en la página, sin hacer preguntas
Esta funcionalidad ha dado lugar a algunas de las experiencias interactivas más increíbles que disfrutamos en la web. La otra cara de la moneda es que también ha provocado vulnerabilidades y exploits costosos.
Cuando los atacantes añaden su script malicioso a un sitio vulnerable, este se ejecuta sin lugar a dudas. No existe una investigación más profunda ni medidas de detección.
Hay tres tipos de XSS:
- XSS almacenado
- XSS reflejado
- DOM XSS
XSS almacenado se produce cuando un atacante puede almacenar de forma persistente 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). Luego, este script incompleto se envía 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 la secuencia de comandos maliciosa en un comentario y, ¡pum! Todos los usuarios que ven ese comentario sin saberlo ejecutan la secuencia de comandos.
XSS reflejado se produce cuando la entrada del usuario se refleja en el navegador del usuario tal como está. Un ejemplo es un cuadro de búsqueda que muestra al usuario la frase «Has buscado...» mientras obtiene los resultados de la búsqueda.
Ahora, imagine que la búsqueda funciona colocando el término de búsqueda en la URL como parámetros de consulta. Un atacante malintencionado 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 suplantación de identidad donde, sin saberlo, introduce la contraseña del 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. Aprovecha 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 enriquecidas. Si se utilizan de forma incorrecta, se pueden utilizar para ejecutar ataques XSS.
Así que, ahí lo tienes. Tienes el alcance del XSS en pocas palabras. Vamos a profundizar en cómo se puede usar de forma destructiva.
¿Por qué es tan peligroso el XSS?
El XSS se puede utilizar para redirigir a los usuarios a sitios maliciosos, robar cookies y buscar datos de sesión. Básicamente, los ataques XSS también son capaces de hacer cualquier cosa que pueda hacer JavaScript.
Estos son tres ejemplos de ataques XSS:
- Usuarios de correo electrónico de Yahoo les robaron las cookies de sesión usando XSS en 2015.
- El Gusano Samy se distribuyó a través de una vulnerabilidad de XSS en MySpace. Sigue siendo el malware de más rápida propagación de todos los tiempos y afecta a un millón de usuarios en solo 20 horas.
- eBay permitió incluir scripts malintencionados en las descripciones de los productos. Esto llevó a Ataques XSS contra los usuarios de eBay.
Los ataques XSS son engañosamente simples y muy graves. Pueden provocar el robo de sesiones, credenciales de usuario o datos confidenciales. El daño a la reputación y la disminución de los ingresos son los principales escollos de estos ataques. Incluso la simple desfiguración de un sitio web puede tener consecuencias indeseables para una empresa.
Sin embargo, XSS puede ser derrotado por un guerrero de seguridad inteligente como tú. La solución no es complicada y la industria ha recorrido un largo camino desde que XSS se convirtió en un exploit de uso común.
Puedes derrotar a XSS.
La clave para derrotar al XSS es entender el contexto. Concretamente, el contexto en el que la entrada del usuario se devolverá al cliente y en el que se devolverá. Dentro del código HTML o dentro de un fragmento de código de JavaScript.
Si la entrada del usuario no tiene que devolverse al navegador, mucho mejor. Pero si lo es, a menudo debería estar codificado en HTML. La codificación HTML de la salida indicará al navegador que renderice el contenido tal como está y no que lo ejecute.
La validación de los datos introducidos también es importante. Sin embargo, la validación y la creación de listas blancas no son soluciones infalibles. La codificación va unos pasos más allá e impide que los navegadores ejecuten un script malicioso. Lo que no se detecte con las estrategias de validación y creación de listas blancas, la codificación se recuperará.
Muchos marcos ahora codifican automáticamente la salida HTML.
Angular, ASP.NET MVC, y React.js son marcos en los que se utiliza la codificación HTML predeterminada. Debe indicar específicamente a estos marcos que no se codifiquen llamando a un método especial.
La mayoría de los demás marcos, (p. ej. Django y primavera) tienen bibliotecas estándar para la prevención de XSS que puede incorporar fácilmente en su código.
El mayor desafío es aprender a analizar todas las formas en que las entradas de los usuarios pueden entrar en un sistema, de modo que puedas mantener los ojos bien abiertos. Los parámetros de consulta pueden provocar ataques, al igual que los parámetros de las publicaciones. Siga el flujo de datos en toda la aplicación y no confíe en ningún dato que provenga del exterior.
Piensa como la patrulla fronteriza. Detenga todos los datos, inspecciónelos y no permita que ingresen si parecen maliciosos. Luego, codifique al renderizar para asegurarse de que cualquier información mala que se haya omitido aún no cause problemas.
Ejecute estas estrategias y sus usuarios estarán a salvo de los ataques mediante XSS. Eche un vistazo al Hoja de trucos de OWASP para obtener aún más consejos para mantener sus datos bajo control.
Impida el XSS y mejore sus habilidades de seguridad.
XSS ocupa el puesto número siete en la lista de los 10 principales riesgos de seguridad web de 2017 de OWASP. Existe desde hace tiempo, pero puede seguir apareciendo y causar problemas con tu aplicación si no tienes cuidado.
La formación es muy importante para los desarrolladores a la hora de desarrollar una mentalidad en la que la seguridad sea lo primero a la hora de crear código. Además, esa formación siempre es más eficaz cuando simula aplicaciones reales, en los lenguajes que los desarrolladores utilizan activamente. Con eso en mente, ¿por qué no echas un vistazo a nuestro Recursos de aprendizaje para obtener más información sobre XSS? Después de eso, puede comenzar el entrenamiento y la práctica que conduzcan a su dominio.
¿Cree que está listo para encontrar y corregir las vulnerabilidades de XSS ahora mismo? Ponte a prueba en la plataforma Secure Code Warrior.
El cross-site scripting (XSS) ha sido un problema para los profesionales de la seguridad desde principios de la década de 2000 y, lamentablemente, décadas después, todavía se registra como una de las amenazas a nivel de código más comunes. Este tipo de vulnerabilidad de software nos ha plagado durante demasiado tiempo, y recientemente hemos recibido una alerta de CISA - como parte de su movimiento Secure-by-Design - busca frustrarlo de una vez por todas. Su misión global es eliminar las clases de vulnerabilidad a gran escala, y este énfasis en la seguridad impulsada por los desarrolladores es algo que realmente puede hacer avanzar la balanza y marcar la diferencia, pero va a requerir el compromiso de las empresas inteligentes que preparan a sus desarrolladores para lograr el éxito en materia de seguridad.
Entonces, ¿qué es XSS exactamente?
Los navegadores web pueden ser nuestra puerta de entrada a todas esas cosas geniales en línea, pero lamentablemente, no todo son buenas noticias. El comportamiento inherente de los navegadores web puede ser un catalizador para las vulnerabilidades de seguridad. Los navegadores comenzaron confiando de manera característica en el marcado que veían y ejecutándolo sin lugar a dudas. Todo eso está muy bien hasta que esa funcionalidad es explotada con fines poco fiables... y, naturalmente, los atacantes acaban encontrando formas de aprovechar esta tendencia para perseguir sus fines perversos.
Las secuencias de comandos entre sitios utilizan 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ño se puede causar y cómo prevenirlo:
¿Cómo funciona XSS?
El XSS se produce cuando una entrada que no es de confianza (a menudo datos) se representa como salida en una página, pero se interpreta erróneamente como código ejecutable. Un atacante puede colocar código ejecutable malintencionado (etiquetas HTML, JavaScript, etc.) dentro de un parámetro de entrada y, cuando lo devuelve al navegador, se ejecuta en lugar de mostrarse como datos.
Como se mencionó 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 operativo de la web es el siguiente:
- El usuario visita una página web
- La página le dice al navegador qué archivos cargar y qué ejecutar
- El navegador ejecuta lo que está en la página, sin hacer preguntas
Esta funcionalidad ha dado lugar a algunas de las experiencias interactivas más increíbles que disfrutamos en la web. La otra cara de la moneda es que también ha provocado vulnerabilidades y exploits costosos.
Cuando los atacantes añaden su script malicioso a un sitio vulnerable, este se ejecuta sin lugar a dudas. No existe una investigación más profunda ni medidas de detección.
Hay tres tipos de XSS:
- XSS almacenado
- XSS reflejado
- DOM XSS
XSS almacenado se produce cuando un atacante puede almacenar de forma persistente 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). Luego, este script incompleto se envía 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 la secuencia de comandos maliciosa en un comentario y, ¡pum! Todos los usuarios que ven ese comentario sin saberlo ejecutan la secuencia de comandos.
XSS reflejado se produce cuando la entrada del usuario se refleja en el navegador del usuario tal como está. Un ejemplo es un cuadro de búsqueda que muestra al usuario la frase «Has buscado...» mientras obtiene los resultados de la búsqueda.
Ahora, imagine que la búsqueda funciona colocando el término de búsqueda en la URL como parámetros de consulta. Un atacante malintencionado 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 suplantación de identidad donde, sin saberlo, introduce la contraseña del 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. Aprovecha 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 enriquecidas. Si se utilizan de forma incorrecta, se pueden utilizar para ejecutar ataques XSS.
Así que, ahí lo tienes. Tienes el alcance del XSS en pocas palabras. Vamos a profundizar en cómo se puede usar de forma destructiva.
¿Por qué es tan peligroso el XSS?
El XSS se puede utilizar para redirigir a los usuarios a sitios maliciosos, robar cookies y buscar datos de sesión. Básicamente, los ataques XSS también son capaces de hacer cualquier cosa que pueda hacer JavaScript.
Estos son tres ejemplos de ataques XSS:
- Usuarios de correo electrónico de Yahoo les robaron las cookies de sesión usando XSS en 2015.
- El Gusano Samy se distribuyó a través de una vulnerabilidad de XSS en MySpace. Sigue siendo el malware de más rápida propagación de todos los tiempos y afecta a un millón de usuarios en solo 20 horas.
- eBay permitió incluir scripts malintencionados en las descripciones de los productos. Esto llevó a Ataques XSS contra los usuarios de eBay.
Los ataques XSS son engañosamente simples y muy graves. Pueden provocar el robo de sesiones, credenciales de usuario o datos confidenciales. El daño a la reputación y la disminución de los ingresos son los principales escollos de estos ataques. Incluso la simple desfiguración de un sitio web puede tener consecuencias indeseables para una empresa.
Sin embargo, XSS puede ser derrotado por un guerrero de seguridad inteligente como tú. La solución no es complicada y la industria ha recorrido un largo camino desde que XSS se convirtió en un exploit de uso común.
Puedes derrotar a XSS.
La clave para derrotar al XSS es entender el contexto. Concretamente, el contexto en el que la entrada del usuario se devolverá al cliente y en el que se devolverá. Dentro del código HTML o dentro de un fragmento de código de JavaScript.
Si la entrada del usuario no tiene que devolverse al navegador, mucho mejor. Pero si lo es, a menudo debería estar codificado en HTML. La codificación HTML de la salida indicará al navegador que renderice el contenido tal como está y no que lo ejecute.
La validación de los datos introducidos también es importante. Sin embargo, la validación y la creación de listas blancas no son soluciones infalibles. La codificación va unos pasos más allá e impide que los navegadores ejecuten un script malicioso. Lo que no se detecte con las estrategias de validación y creación de listas blancas, la codificación se recuperará.
Muchos marcos ahora codifican automáticamente la salida HTML.
Angular, ASP.NET MVC, y React.js son marcos en los que se utiliza la codificación HTML predeterminada. Debe indicar específicamente a estos marcos que no se codifiquen llamando a un método especial.
La mayoría de los demás marcos, (p. ej. Django y primavera) tienen bibliotecas estándar para la prevención de XSS que puede incorporar fácilmente en su código.
El mayor desafío es aprender a analizar todas las formas en que las entradas de los usuarios pueden entrar en un sistema, de modo que puedas mantener los ojos bien abiertos. Los parámetros de consulta pueden provocar ataques, al igual que los parámetros de las publicaciones. Siga el flujo de datos en toda la aplicación y no confíe en ningún dato que provenga del exterior.
Piensa como la patrulla fronteriza. Detenga todos los datos, inspecciónelos y no permita que ingresen si parecen maliciosos. Luego, codifique al renderizar para asegurarse de que cualquier información mala que se haya omitido aún no cause problemas.
Ejecute estas estrategias y sus usuarios estarán a salvo de los ataques mediante XSS. Eche un vistazo al Hoja de trucos de OWASP para obtener aún más consejos para mantener sus datos bajo control.
Impida el XSS y mejore sus habilidades de seguridad.
XSS ocupa el puesto número siete en la lista de los 10 principales riesgos de seguridad web de 2017 de OWASP. Existe desde hace tiempo, pero puede seguir apareciendo y causar problemas con tu aplicación si no tienes cuidado.
La formación es muy importante para los desarrolladores a la hora de desarrollar una mentalidad en la que la seguridad sea lo primero a la hora de crear código. Además, esa formación siempre es más eficaz cuando simula aplicaciones reales, en los lenguajes que los desarrolladores utilizan activamente. Con eso en mente, ¿por qué no echas un vistazo a nuestro Recursos de aprendizaje para obtener más información sobre XSS? Después de eso, puede comenzar el entrenamiento y la práctica que conduzcan a su dominio.
¿Cree que está listo para encontrar y corregir las vulnerabilidades de XSS ahora mismo? Ponte a prueba en la plataforma Secure Code Warrior.
Haga clic en el enlace de abajo y descargue el PDF de este recurso.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Ver informeReserva una demostración
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
El cross-site scripting (XSS) ha sido un problema para los profesionales de la seguridad desde principios de la década de 2000 y, lamentablemente, décadas después, todavía se registra como una de las amenazas a nivel de código más comunes. Este tipo de vulnerabilidad de software nos ha plagado durante demasiado tiempo, y recientemente hemos recibido una alerta de CISA - como parte de su movimiento Secure-by-Design - busca frustrarlo de una vez por todas. Su misión global es eliminar las clases de vulnerabilidad a gran escala, y este énfasis en la seguridad impulsada por los desarrolladores es algo que realmente puede hacer avanzar la balanza y marcar la diferencia, pero va a requerir el compromiso de las empresas inteligentes que preparan a sus desarrolladores para lograr el éxito en materia de seguridad.
Entonces, ¿qué es XSS exactamente?
Los navegadores web pueden ser nuestra puerta de entrada a todas esas cosas geniales en línea, pero lamentablemente, no todo son buenas noticias. El comportamiento inherente de los navegadores web puede ser un catalizador para las vulnerabilidades de seguridad. Los navegadores comenzaron confiando de manera característica en el marcado que veían y ejecutándolo sin lugar a dudas. Todo eso está muy bien hasta que esa funcionalidad es explotada con fines poco fiables... y, naturalmente, los atacantes acaban encontrando formas de aprovechar esta tendencia para perseguir sus fines perversos.
Las secuencias de comandos entre sitios utilizan 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ño se puede causar y cómo prevenirlo:
¿Cómo funciona XSS?
El XSS se produce cuando una entrada que no es de confianza (a menudo datos) se representa como salida en una página, pero se interpreta erróneamente como código ejecutable. Un atacante puede colocar código ejecutable malintencionado (etiquetas HTML, JavaScript, etc.) dentro de un parámetro de entrada y, cuando lo devuelve al navegador, se ejecuta en lugar de mostrarse como datos.
Como se mencionó 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 operativo de la web es el siguiente:
- El usuario visita una página web
- La página le dice al navegador qué archivos cargar y qué ejecutar
- El navegador ejecuta lo que está en la página, sin hacer preguntas
Esta funcionalidad ha dado lugar a algunas de las experiencias interactivas más increíbles que disfrutamos en la web. La otra cara de la moneda es que también ha provocado vulnerabilidades y exploits costosos.
Cuando los atacantes añaden su script malicioso a un sitio vulnerable, este se ejecuta sin lugar a dudas. No existe una investigación más profunda ni medidas de detección.
Hay tres tipos de XSS:
- XSS almacenado
- XSS reflejado
- DOM XSS
XSS almacenado se produce cuando un atacante puede almacenar de forma persistente 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). Luego, este script incompleto se envía 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 la secuencia de comandos maliciosa en un comentario y, ¡pum! Todos los usuarios que ven ese comentario sin saberlo ejecutan la secuencia de comandos.
XSS reflejado se produce cuando la entrada del usuario se refleja en el navegador del usuario tal como está. Un ejemplo es un cuadro de búsqueda que muestra al usuario la frase «Has buscado...» mientras obtiene los resultados de la búsqueda.
Ahora, imagine que la búsqueda funciona colocando el término de búsqueda en la URL como parámetros de consulta. Un atacante malintencionado 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 suplantación de identidad donde, sin saberlo, introduce la contraseña del 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. Aprovecha 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 enriquecidas. Si se utilizan de forma incorrecta, se pueden utilizar para ejecutar ataques XSS.
Así que, ahí lo tienes. Tienes el alcance del XSS en pocas palabras. Vamos a profundizar en cómo se puede usar de forma destructiva.
¿Por qué es tan peligroso el XSS?
El XSS se puede utilizar para redirigir a los usuarios a sitios maliciosos, robar cookies y buscar datos de sesión. Básicamente, los ataques XSS también son capaces de hacer cualquier cosa que pueda hacer JavaScript.
Estos son tres ejemplos de ataques XSS:
- Usuarios de correo electrónico de Yahoo les robaron las cookies de sesión usando XSS en 2015.
- El Gusano Samy se distribuyó a través de una vulnerabilidad de XSS en MySpace. Sigue siendo el malware de más rápida propagación de todos los tiempos y afecta a un millón de usuarios en solo 20 horas.
- eBay permitió incluir scripts malintencionados en las descripciones de los productos. Esto llevó a Ataques XSS contra los usuarios de eBay.
Los ataques XSS son engañosamente simples y muy graves. Pueden provocar el robo de sesiones, credenciales de usuario o datos confidenciales. El daño a la reputación y la disminución de los ingresos son los principales escollos de estos ataques. Incluso la simple desfiguración de un sitio web puede tener consecuencias indeseables para una empresa.
Sin embargo, XSS puede ser derrotado por un guerrero de seguridad inteligente como tú. La solución no es complicada y la industria ha recorrido un largo camino desde que XSS se convirtió en un exploit de uso común.
Puedes derrotar a XSS.
La clave para derrotar al XSS es entender el contexto. Concretamente, el contexto en el que la entrada del usuario se devolverá al cliente y en el que se devolverá. Dentro del código HTML o dentro de un fragmento de código de JavaScript.
Si la entrada del usuario no tiene que devolverse al navegador, mucho mejor. Pero si lo es, a menudo debería estar codificado en HTML. La codificación HTML de la salida indicará al navegador que renderice el contenido tal como está y no que lo ejecute.
La validación de los datos introducidos también es importante. Sin embargo, la validación y la creación de listas blancas no son soluciones infalibles. La codificación va unos pasos más allá e impide que los navegadores ejecuten un script malicioso. Lo que no se detecte con las estrategias de validación y creación de listas blancas, la codificación se recuperará.
Muchos marcos ahora codifican automáticamente la salida HTML.
Angular, ASP.NET MVC, y React.js son marcos en los que se utiliza la codificación HTML predeterminada. Debe indicar específicamente a estos marcos que no se codifiquen llamando a un método especial.
La mayoría de los demás marcos, (p. ej. Django y primavera) tienen bibliotecas estándar para la prevención de XSS que puede incorporar fácilmente en su código.
El mayor desafío es aprender a analizar todas las formas en que las entradas de los usuarios pueden entrar en un sistema, de modo que puedas mantener los ojos bien abiertos. Los parámetros de consulta pueden provocar ataques, al igual que los parámetros de las publicaciones. Siga el flujo de datos en toda la aplicación y no confíe en ningún dato que provenga del exterior.
Piensa como la patrulla fronteriza. Detenga todos los datos, inspecciónelos y no permita que ingresen si parecen maliciosos. Luego, codifique al renderizar para asegurarse de que cualquier información mala que se haya omitido aún no cause problemas.
Ejecute estas estrategias y sus usuarios estarán a salvo de los ataques mediante XSS. Eche un vistazo al Hoja de trucos de OWASP para obtener aún más consejos para mantener sus datos bajo control.
Impida el XSS y mejore sus habilidades de seguridad.
XSS ocupa el puesto número siete en la lista de los 10 principales riesgos de seguridad web de 2017 de OWASP. Existe desde hace tiempo, pero puede seguir apareciendo y causar problemas con tu aplicación si no tienes cuidado.
La formación es muy importante para los desarrolladores a la hora de desarrollar una mentalidad en la que la seguridad sea lo primero a la hora de crear código. Además, esa formación siempre es más eficaz cuando simula aplicaciones reales, en los lenguajes que los desarrolladores utilizan activamente. Con eso en mente, ¿por qué no echas un vistazo a nuestro Recursos de aprendizaje para obtener más información sobre XSS? Después de eso, puede comenzar el entrenamiento y la práctica que conduzcan a su dominio.
¿Cree que está listo para encontrar y corregir las vulnerabilidades de XSS ahora mismo? Ponte a prueba en la plataforma Secure Code Warrior.
Tabla de contenido
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserva una demostraciónDescargarRecursos para empezar
Temas y contenido de formación sobre código seguro
Nuestro contenido líder en la industria siempre está evolucionando para adaptarse al cambiante panorama del desarrollo de software teniendo en cuenta su función. Se ofrecen temas que abarcan desde la IA hasta la inyección de XQuery para distintos puestos, desde arquitectos e ingenieros hasta directores de productos y control de calidad. Obtenga un adelanto de lo que ofrece nuestro catálogo de contenido por tema y función.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Recursos para empezar
Cybermon está de vuelta: las misiones de IA de Beat the Boss ya están disponibles bajo demanda
Cybermon 2025 Beat the Boss ya está disponible durante todo el año en SCW. Implemente desafíos de seguridad avanzados de IA y LLM para fortalecer el desarrollo seguro de la IA a gran escala.
Explicación de la Ley de Ciberresiliencia: qué significa para el desarrollo de software seguro por diseño
Descubra qué exige la Ley de Ciberresiliencia (CRA) de la UE, a quién se aplica y cómo los equipos de ingeniería pueden prepararse con prácticas de diseño seguras, prevención de vulnerabilidades y desarrollo de capacidades para desarrolladores.
Habilitador 1: Criterios de éxito definidos y medibles
Enabler 1 da inicio a nuestra serie Enablers of Success, de 10 partes, mostrando cómo vincular la codificación segura con los resultados empresariales, como la reducción del riesgo y la velocidad para lograr la madurez del programa a largo plazo.
