Video Summary and Transcription
La charla discute cómo mejorar la seguridad de las aplicaciones web utilizando Mozilla Observatory. Cubre temas como la evaluación de los encabezados de seguridad, el mantenimiento del historial de calificaciones y la implementación de políticas de seguridad de contenido. Se enfatiza la importancia de asegurar las cookies y habilitar la redirección de HTTP a HTTPS. También se destacan el uso de encabezados de referencia para controlar el comportamiento del navegador y la integridad de los sub-recursos para evitar la comprometición de archivos.
1. Introducción a Mozilla Observatory
Bienvenidos a React Day Berlin. Hoy hablaré sobre cómo mejorar la seguridad de las aplicaciones web utilizando Mozilla Observatory. Evalúa los encabezados de seguridad y el ranking. Vamos a Mozilla Observatory y veamos cómo se ve. Puedes omitir la publicación de resultados y forzar un nuevo escaneo. Da la puntuación Dplus y evalúa los encabezados de seguridad. Mantiene el historial de calificaciones. La política de seguridad de contenido permite un control detallado sobre los recursos cargados. Previene las vulnerabilidades de scripting entre sitios. Ten cuidado al implementarlo en sitios web existentes. Comienza con la política de seguridad de contenido solo para informes. Las cookies también son importantes.
Hola a todos. Bienvenidos a React Day Berlin. Mi nombre es Karan. Soy un desarrollador front-end en Fabric, que es una startup de e-commerce con sede en EE. UU. Hoy hablaré sobre cómo mejorar la security de tu aplicación web utilizando Mozilla Observatory. Mozilla Observatory es una herramienta que puedes usar para evaluar los encabezados de security de tu aplicación web y evaluar el ranking de security de tus sitios web. Aquí puedes ver todos los encabezados de security que Mozilla Observatory mide para tu aplicación y da la puntuación. Así que vamos a Mozilla Observatory y veamos cómo se ve. Este es el sitio aquí, hay tres opciones aquí. Puedes ver, puedes elegir omitir la publicación de tus resultados en los registros públicos de Mozilla. Mozilla en realidad guarda en caché tus resultados escaneados. Así que si quieres forzar un nuevo escaneo, puedes marcar esta casilla. Y si no quieres ejecutar ningún escáner de terceros puedes seleccionar este. Vamos a ingresar mi dominio y ver qué resultado nos da. Aquí puedes ver que ejecutará el Observatorio HTTP y me da la puntuación Dplus. Y aquí están todos los encabezados de security que ha evaluado. Y puedes ver el estado de aprobación y fallo y la puntuación de cada uno de los encabezados de security. Y la razón detrás de una puntuación particular también se muestra aquí. También mantiene el historial de calificaciones. Así que cada vez que hagas cualquier mejora en tu sitio web y vuelvas a escanear la puntuación, entonces podrás ver la puntuación mejorada de tu sitio web. Vamos a profundizar en cada uno de los encabezados de security y aprender más sobre cada uno de los encabezados de security. La política de security de contenido es un tema muy amplio. Así que solo hablaremos brevemente sobre ello. Básicamente, la política de security de contenido permite un control detallado sobre qué recursos de tu sitio se pueden cargar. Es la mejor manera de prevenir cualquier vulnerabilidad de scripting entre sitios, comúnmente conocida como ataques de acceso. El beneficio principal de CSP es que puedes deshabilitar el uso de JavaScript en línea inseguro, pero también tiene sus contras. Necesitas tener mucho cuidado al implementarlo en los sitios web existentes ya que puede romper las funcionalidades existentes. La mejor manera de implementar CSP es comenzar con la política de security de contenido solo para informes, que es un encabezado donde solo se informará de tus violaciones, pero no bloqueará ninguna ejecución de JavaScript. De esa manera puedes recopilar la información de todas las violaciones, solucionar eso primero, y realmente implementar la política de security de contenido.
2. Asegurando Cookies y Redirección
Debe estar asegurado utilizando la bandera segura y enviado solo a través de HTTPS. Defina un período de vencimiento mínimo para las cookies del identificador de sesión. Configure correctamente el servidor para solicitudes de origen cercano. Habilite la redirección de HTTP a HTTPS.
Cookies, debes haber oído hablar de ellas. Deberían estar aseguradas usando la bandera segura, por lo que deberían enviarse solo a través de HTTPS. Necesita ser cookies HTTP solamente. Eso no requiere ningún acceso de JavaScript, por lo que puede ser bloqueado para el acceso por cualquier JavaScript de terceros también.
También necesitas definir el período de vencimiento. Debería ser lo más mínimo posible. En particular, el identificador de sesión que almacenamos en las cookies debería expirar muy rápidamente cuando ya no sean necesarios. También podemos usar el mismo conjunto de cookies para bloquear las cookies de ser enviadas a cualquier solicitud de origen cercano. Si eres un desarrollador front-end, debes haber encontrado errores de curso, por lo que es muy importante configurar tu servidor correctamente para cualquier solicitud de origen cercano. No debería permitir ningún otro dominio que no necesite esos recursos particulares, por lo que debería estar configurado correctamente. Tampoco debería permitir el acceso a ningún patrón comodín patterns.
HSTCS, comúnmente conocido como security de transporte estricto HTTP le dice al navegador que cargue los recursos solo a través de HTTPS, y la redirección también es muy importante. Necesitas habilitar la redirección de HTTP a HTTPS en tu aplicación web.
3. Encabezados de Referencia e Integridad de Sub-recursos
Siempre que visite un recurso desde su aplicación, el navegador envía el referente al servidor web. Para controlar esto, utilice los encabezados de referencia. Hay diferentes directivas disponibles, como no-referente, mismo origen y origen estricto. La integridad de los sub-recursos evita que los atacantes alteren las bibliotecas de JavaScript alojadas en CDN. Al definir la integridad de su recurso utilizando el hash SHA, el navegador puede detectar modificaciones y prevenir la carga de archivos comprometidos.
Otro punto importante es la política de referencia, por lo que siempre que visite cualquier recurso desde su aplicación, el navegador enviará el referente al servidor web desde donde se originó la solicitud. Eso puede ser útil en algunos casos, pero también puede llevar a riesgos de privacidad. Para controlar eso, puedes usar los encabezados de referencia en tu aplicación. Hay algunas directivas que puedes usar. La primera es la directiva no-referente, que eliminará el referente de todas tus solicitudes enviadas a cualquier recurso. El mismo origen enviará la URL completa, pero solo para la solicitud del mismo origen. Y el origen estricto, lo que hará es que enviará el encabezado de origen, pero solo enviará la parte del host. Eliminará la parte real de la página desde donde solicitaste el recurso. Y el recomendado es el origen estricto cuando es de origen cruzado. Por lo tanto, enviará el referente completo en el mismo origen, pero una versión reducida del origen cuando estás haciendo una solicitud de origen cruzado.
Entonces, otro concepto importante es la integridad de los sub-recursos. Por lo tanto, evita que el atacante altere las bibliotecas de JavaScript alojadas en CDN que puedes estar utilizando en tu aplicación. Puedes estar utilizando jQuery desde CDN o cualquier biblioteca desde unpackage.com. Entonces, en cualquier caso, el CDN se ve comprometido y el contenido de ese archivo en particular cambia. Puede ejecutarse maliciosamente en tu aplicación y robar tus datos y realizar todo tipo de ataques en tus aplicaciones. Por lo tanto, para mitigar eso, necesitas definir la integridad de tu recurso. Así que siempre que estés utilizando cualquier etiqueta de script necesitas generar el hash SHA para ese recurso en particular. Así que siempre que el contenido de ese archivo en particular, digamos en el caso de este archivo code.jQuery.com slash este archivo jQuery min.js se modifica, entonces esta integridad no coincidirá con ese contenido modificado y el navegador omitirá la carga de este archivo en particular en el navegador. Entonces, el siguiente es xContentTypeOptions. Básicamente, le dice al navegador que no adivine el tipo de recurso. Y así, en algunos de los casos, lo que sucede es que cuando el tipo MIME no está definido en el recurso, el navegador lo entiende como un script y intenta ejecutarlo, y puede llevar a ataques de XSS. Por lo tanto, siempre es una buena práctica definir las xContentTypeOptions como no snip en tu aplicación web. Las últimas pero no menos importantes opciones son xFrameOptions y xXSSProtection. La política de seguridad de contenido realmente supera ambos de estos encabezados por lo que puede no ser útil en los navegadores más nuevos pero puede ser útil en los navegadores más antiguos. Así que xFrameOptions básicamente te permite restringir la carga de tu aplicación web en el iframe y xXSSProtection desactiva el uso de JavaScript en línea. Sí, eso fue todo. Gracias. Puedes conectarte a través de Twitter, LinkedIn y si quieres aprender más sobre seguridad, puedes visitar estos recursos de Mozilla. Gracias.
Comments