Introducción
La seguridad de los usuarios y sus datos personales durante el uso de una aplicación web es primordial. Si bien este principio rector ha sido reconocido incluso desde las primeras etapas del desarrollo web, los malos actores encuentran lagunas en las aplicaciones y pueden explotar a sus usuarios.
Muchos ataques "estándar" son bien conocidos y están documentados, y la protección contra ellos no es difícil. Para liberar al desarrollador de la implementación de prácticas de seguridad, los marcos como Spring Boot han abstraído varias medidas de seguridad y le permiten simplemente aplicar filtros de seguridad en sus aplicaciones para evitar ataques conocidos.
En esta breve guía, veremos qué es Cross-Site Scripting (XSS), cómo alguien podría realizar este ataque en su propia aplicación y cómo puede prevenirlo fácilmente con Spring Boot.
¿Qué es Cross-Site Scripting (XSS)?
Cross-Site Scripting es un exploit muy conocido y ampliamente difundido, en el que un mal actor inyecta un script en una aplicación web.
Por lo general, se aplica una política del mismo origen a las aplicaciones web, que restringe las secuencias de comandos en una página web para acceder a los datos de las fuentes si sus orígenes no coinciden. Bajo la política del mismo origen, si una página de un sitio web de confianza puede acceder a datos que interactúan con el usuario (como cookies, por ejemplo), otras páginas del mismo origen también pueden hacerlo. Esta forma de control de acceso parecía suficiente para proteger la integridad de los datos en las aplicaciones web en ese momento.
Cross-Site Scripting elude la política del mismo origen, inyectando un script malicioso en la página de un sitio web de confianza. Dado que el script se ejecuta desde un sitio web de confianza, se ejecuta como un script de confianza. No había una forma clara de diferenciar entre scripts maliciosos y scripts no maliciosos, por lo que la ejecución de código arbitrario era posible con Cross-Site Scripting. Esto va desde la inserción de alertas molestas hasta ataques de ingeniería social, la recopilación silenciosa de información del usuario o la redirección de los usuarios a páginas de phishing que parecen ser partes de sitios web confiables.
Muchos Los sitios web son susceptibles a los ataques Cross-Site Scripting, y sigue siendo un ataque común en la actualidad, aunque este tipo de exploit se conoce desde los años 90.
Prevención de XSS en una aplicación Spring Boot con política de seguridad de contenido (CSP)
Spring Boot se toma la seguridad en serio, y el módulo de seguridad de Spring implementa prácticas de seguridad flexibles y poderosas que permiten a los desarrolladores minimizar su preocupación cuando se trata de seguridad, que a menudo requiere una comprensión de bajo nivel de los principios de la forma en que se intercambian los mensajes en una web. solicitud.
Por defecto, Spring Boot implementa varios encabezados de seguridad:
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
¡La protección X-XSS está incluida por defecto! Este encabezado de seguridad intenta detectar XSS intenta y los bloquea. Sin embargo, este no es un proceso a prueba de fallas, y los navegadores tienen diferentes implementaciones de detectores. Algunos navegadores, como Chrome, tienen incluso eliminó su XSS Auditor. Además, la detección automática funciona para Ataques XSS reflejados, mientras que también existen otro tipo de ataques.
Una alternativa más moderna a X-XSS-Protection es la Política de seguridad de contenido (CSP), que se ocupan principalmente de las políticas en las que se pueden cargar los recursos, desde qué orígenes y en qué puntos finales. A partir de 2022, CSP es la mejor medida de prevención contra XSS, Clickjacking y otros tipos de ataques. No todos los navegadores implementan CSP, por lo que no se incluye en los encabezados de seguridad de forma predeterminada.
Nota: Incluso con CSP implementado, siempre es el mejor curso de acción para validar cualquier entrada del usuario y asegúrese de que sea seguro procesar usando su sistema, para evitar la inyección de código.
En Spring Boot: para configurar medidas de seguridad web personalizadas, normalmente extenderá el WebSecurityConfigurerAdapter clase y anular la configure() método:
@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.headers()
.contentSecurityPolicy("csp-directives");
}
}
Cuando las directivas de política de seguridad de contenido (suministradas como ;-cadena separada) dependen de su caso de uso y en qué fuentes desea confiar:
Content-Security Policy: directive1; directive2; directive3; ... directiveN;
Por ejemplo, una aplicación web puede enumerar sitios web confiables desde los cuales se pueden cargar scripts con:
script-src https://trusted.com;
O puede omitir la confianza en cualquier sitio web de terceros:
script-src self;
De manera similar, una aplicación puede confiar en los complementos:
object-src https://trusted.com
Hay una amplia variedad de directivas que puede suministrar, que incluyen:
default-src– Reserva predeterminadachild-src– Fuentes de trabajadores web válidasframe-src– Fuentes válidas paras ysimg-src– Fuentes válidas para imágenesmedia-src– Fuentes válidas para,yetiquetasscript-src– Fuentes de script válidas (ayuda a prevenir XSS)style-src– Fuentes válidas paraelementosbase-uri– Restringe los recursos accesibles desde elelementosframe-ancestors– Padres válidos de,,, etc elementos- etc.
Consulte nuestra guía práctica y práctica para aprender Git, con las mejores prácticas, los estándares aceptados por la industria y la hoja de trucos incluida. Deja de buscar en Google los comandos de Git y, de hecho, aprenden ella!
Por ejemplo, aquí hay un conjunto seguro de directivas de políticas:
script-src 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' http: https:;
object-src 'none';
base-uri 'none';
require-trusted-types-for 'script';
report-uri https://csp.example.com;
Agreguemos estos a nuestra aplicación Spring Boot:
@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.headers()
.contentSecurityPolicy("script-src 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' http: https:; object-src 'none'; base-uri 'none'; require-trusted-types-for 'script'; report-uri https://csp.example.com;");
}
}
Puede utilizar el CSP-Evaluador para evaluar si sus directivas CSP son válidas y seguro, y señalará qué directivas son fácilmente explotables. Aquí hay una directiva CSP que permite las API de Google:
default-src 'self';
object-src 'none';
frame-src 'self' data:;
script-src 'self' 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' https://storage.googleapis.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data:;
font-src 'self' data:;
base-uri 'self'
Conclusión
En esta breve guía, hemos analizado qué es Cross-Site Scripting (XSS) y cómo funciona a un nivel holístico. Luego, exploramos algunas medidas de prevención de XSS que se pueden implementar fácilmente con Spring Boot para hacer que sus aplicaciones sean seguras y establecer un Política de seguridad de contenido (CSP).
Finalmente, hemos explorado las directivas de CSP y echamos un vistazo a un par de políticas seguras diferentes.
