Conceptos centrales de la serie de seguridad Spring
El proceso de verificación de la identidad del usuario que solicita un recurso resuelve el problema de "¿quién lo solicitó?".
El proceso de confirmar si el usuario actual tiene permiso para acceder a los recursos resuelve el problema de "¿Puede realizar esta operación?"
Falsificación de solicitudes entre sitios
La solicitud es falsificada por un sitio web externo y enviada al servidor empresarial de destino en lugar de ser enviada al servidor de destino por el usuario. Esta solicitud falsa se llama CSRF.
Modo de token de sincronización, para solicitudes de publicación (para evitar obtener, lo que provocará una fuga de token), agregue un token de sincronización a los parámetros de la solicitud (generalmente encabezados) y el servidor verifica la coherencia de la propiedad del token entrante. para determinar si es la solicitud correcta. El token de solicitud se obtiene de la cookie, pero el sitio externo no puede obtener el token debido a la misma política de origen. Este problema se puede resolver muy bien.
Generalmente presente dentro de una sesión de usuario. ¿Por qué no en galletas? Ésta es una solución temprana. Algunos de los primeros sistemas almacenaban tokens en cookies, pero había lagunas, como la protección CSRF de Ruby on Rails, donde el sistema perdía la protección de vencimiento del token en caso de emergencia. En el desarrollo de aplicaciones web, almacenar información crítica en segundo plano es una forma segura. Los tokens pueden caducar con la sesión, lo que puede gestionarse mediante recuperación activa o actualización pasiva.
SameSite es un atributo del protocolo HTTP, consúltelo. Esta es una solución de emergencia para prevenir ataques CSRF. Puede establecer los siguientes valores diferentes en la cookie de sesión:
Si la cookie se pierde, las solicitudes de la información de sesión almacenada en la cookie ingresarán a la operación de inicio de sesión autorizada. Al utilizar el atributo SameSite para evitar ataques, debe prestar atención a algunos escenarios de experiencia del usuario. Por ejemplo, la dirección que envía correos electrónicos en modo estricto perderá el estado de inicio de sesión y el usuario deberá iniciar sesión nuevamente, lo que puede provocar un error. mala experiencia.
Desde el nivel de la aplicación, generalmente es para usuarios de navegadores, y la protección CSRF debe deshabilitarse en escenarios sin navegador. En la definición de CSRF, depende del navegador y se confunde fácilmente con ataques de intermediario.
Se debe prestar especial atención a escenarios específicos como inicio de sesión, cierre de sesión y multipartito, y se debe enfatizar la protección CSRF.
Hay algunos encabezados en el protocolo HTTP para el procesamiento de seguridad. Este módulo explica los encabezados de seguridad clave en Spring Security. Referencia adicional: Encabezados de respuesta HTTP seguros, desarrollador.mozilla.org.
Encabezado que controla el almacenamiento en caché del navegador del contenido de navegación del usuario. Spring Security desactiva el almacenamiento en caché de forma predeterminada, lo que puede evitar la fuga de información confidencial. Por ejemplo, si un usuario inicia sesión en una cuenta para ver información confidencial y luego cierra la sesión, un usuario malintencionado volverá a iniciar sesión a través del navegador para ver información confidencial.
Si se debe utilizar el rastreo de contenido para procesar encabezados de control cuando el tipo de contenido no existe. Para optimizar la experiencia, el navegador determina automáticamente el tipo de contenido de respuesta y luego lo representa. Deshabilitar el rastreo puede prevenir ataques XSS. Porque un usuario malintencionado puede crear un documento js postscript y utilizarlo para realizar un ataque XSS.
Http Strict Transport Security, HTST (http estricta seguridad de transporte). Muchos usuarios están acostumbrados a ingresar nombres de dominio sin el protocolo https. El intermediario puede interceptar el http y robar la respuesta https, provocando un ataque de intermediario al usuario. El encabezado de Strict Transport Security le indicará al navegador que lo configure en una dirección de transporte de Strict Security.
Referencia RFC6797
La fijación de clave pública HTTP (HPKP) se utiliza para indicar a los clientes web que asocien una clave pública criptográfica específica con el servidor web para reducir el riesgo de ataques MITM utilizando certificados falsificados. Ya abandonado.
Si su sitio web puede integrarse en otros sitios web. Se utiliza para evitar el clickjacking.
Para detener las operaciones cuando se detecta un ataque de secuencias de comandos entre dominios, los navegadores modernos pueden usar Content-Security-Policy para proteger los navegadores que no admiten CSP, lo cual es muy efectivo. Los encabezados de tablas no son totalmente compatibles y solo los admiten unos pocos navegadores, como IE y Safari.
CSP es un mecanismo para entregar políticas de seguridad a los clientes. Cada política de seguridad representa un conjunto de directivas de seguridad, cada una de las cuales restringe la presentación de recursos. Política de seguridad de contenido, Política de seguridad de contenido, solo informe
El encabezado Referrer marca la fuente original del recurso y Referrer-Policy controla principalmente cuánta información de referencia se incluye en la solicitud.
Proporciona a los desarrolladores un mecanismo para deshabilitar, habilitar y modificar selectivamente las API fijadas o las funciones del navegador.
Proporciona una forma de borrar los datos del lado del navegador a través de encabezados, como configurar encabezados para borrar los datos del lado del navegador al cerrar sesión.