Django App Security: un tutorial de Pydantic, Parte 4

Esta es la cuarta parte de una serie sobre el uso de pydantic para proyectos basados ​​en Django. Antes de continuar, repasemos: yoEn la primera parte de la serie, nos enfocamos en el uso de pydantic de sugerencias de tipo Python Optimice la gestión de la configuración de Django. En el segundo tutorial Usamos Docker al crear una aplicación web basada en este concepto. Orientación de nuestro desarrollo y producción. entornos. El tercer elemento descrito Alojando nuestra aplicación en Heroku.

Escrito con un principio de diseño centrado en la seguridad, una desviación de las bibliotecas de Python como Flask y FastAPI, Django tiene soporte integrado para identificar muchas trampas de seguridad comunes. Usando un ejemplo de una aplicación web en funcionamiento que se ejecuta y está expuesta a Internet, usaremos Django para mejorar la seguridad de la aplicación.

Para participar, asegúrese de implementar primero nuestra aplicación web de muestra como se describe en la primera entrega de esta serie de tutoriales. Luego evaluaremos, fortaleceremos y verificaremos la seguridad de nuestra aplicación Django, lo que dará como resultado un sitio que admita estrictamente HTTPS.

Paso 1: evaluar las vulnerabilidades de la aplicación

Una forma de realizar el control de seguridad de Django y la secuencia de verificación del sitio es navegar a la raíz de nuestra aplicación y ejecutar:

python manage.py check --deploy --fail-level WARNING

Pero este comando ya está incluido en nuestra aplicación. heroku-release.sh Archivo (siguiendo los pasos de la parte 3 de esta serie de tutoriales) y el script se ejecutará automáticamente cuando se implemente la aplicación.

El check El comando en la secuencia de comandos anterior genera una lista de advertencias de Django relacionadas con la seguridad que se pueden ver haciendo clic en Mostrar registro de lanzamiento Botón en el tablero de Heroku. El resultado de nuestra aplicación se ve así:

System check identified some issues:
​
WARNINGS:
?: (security.W004) You have not set a value for the SECURE_HSTS_SECONDS setting. If your entire site is served only over SSL, you may want to consider setting a value and enabling HTTP Strict Transport Security. Be sure to read the documentation first; enabling HSTS carelessly can cause serious, irreversible problems.
?: (security.W008) Your SECURE_SSL_REDIRECT setting is not set to True. Unless your site should be available over both SSL and non-SSL connections, you may want to either set this setting True or configure a load balancer or reverse-proxy server to redirect all connections to HTTPS.
?: (security.W012) SESSION_COOKIE_SECURE is not set to True. Using a secure-only session cookie makes it more difficult for network traffic sniffers to hijack user sessions.
?: (security.W016) You have 'django.middleware.csrf.CsrfViewMiddleware' in your MIDDLEWARE, but you have not set CSRF_COOKIE_SECURE to True. Using a secure-only CSRF cookie makes it more difficult for network traffic sniffers to steal the CSRF token.​
System check identified 4 issues (0 silenced).

Reinterpretada, la lista anterior sugiere que abordemos los siguientes cuatro problemas de seguridad:

Ahora abordaremos cada uno de los cuatro problemas identificados. Nuestra configuración de HSTS tendrá esto en cuenta (security.W004) Mensaje de advertencia sobre la habilitación descuidada de HSTS para evitar una interrupción importante del sitio.

Paso 2: Reforzar la seguridad de la aplicación Django

Antes de abordar los problemas de seguridad relacionados con HTTPS, una versión de HTTP que usa el protocolo SSL, primero debemos habilitar HTTPS configurando nuestra aplicación web para aceptar solicitudes SSL.

Para admitir solicitudes SSL, configuremos la variable de configuración USE_SSL. Establecer esta variable no cambia el comportamiento de nuestra aplicación, pero es el primer paso para realizar más cambios en la configuración.

Naveguemos a la sección Config Vars del tablero de Heroku en la pestaña Configuración donde podemos ver nuestros pares clave-valor configurados:

Por lo general, la configuración de seguridad de Django se almacena dentro de una aplicación web settings.py Archivo. settings.py incluye el SettingsFromEnvironment Clase responsable de las variables de entorno. Agreguemos una nueva variable de configuración y establezcamos su clave en USE_SSL y su valor tambien TRUE. SettingsFromEnvironment responde y maneja esta variable.

mientras en nuestro settings.py también actualizamos los valores de las variables HTTPS, cookie de sesión y cookie CSRF. Esperaremos para habilitar HSTS ya que requiere un paso adicional.

Los cambios clave para admitir SSL y actualizar estas tres variables existentes son:

class SettingsFromEnvironment(BaseSettings):
    USE_SSL: bool = False
​
try:
   # ...
    USE_SSL = config.USE_SSL

# ...
if not USE_SSL:
    SECURE_PROXY_SSL_HEADER = None
    SECURE_SSL_REDIRECT = False
    SESSION_COOKIE_SECURE = False
    CSRF_COOKIE_SECURE = False
else:
    # (security.W008)
    SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")
    SECURE_SSL_REDIRECT = True
    # (security.W012)
    SESSION_COOKIE_SECURE = True
    # (security.W016)
    CSRF_COOKIE_SECURE = True

Estas actualizaciones de seguridad de Django son importantes para proteger nuestra aplicación. Cada configuración de Django está comentada en código con su correspondiente identificador de advertencia de seguridad.

El SECURE_PROXY_SSL_HEADER Y SECURE_SSL_REDIRECT La configuración garantiza que nuestra aplicación solo admita la conexión a nuestro sitio web a través de HTTPS, una opción mucho más segura que HTTP sin cifrar. Nuestros cambios aseguran que un navegador que intente conectarse a nuestro sitio a través de HTTP sea redirigido a una conexión a través de HTTPS.

Para admitir HTTPS, debemos proporcionar un certificado SSL. La función de administración de certificados automatizados (ACM) de Heroku se ajusta a la factura y está configurada de manera predeterminada para dynos básicos o profesionales.

Cuando estos ajustes se agregan a la settings.py podemos confirmar nuestros cambios de código, navegar al panel de administración de Heroku y activar otra implementación de la aplicación desde el repositorio para manifestar esos cambios en nuestro sitio web.

Paso 3: comprueba la redirección de HTTPS

Una vez completada la implementación, verifiquemos las capacidades de HTTPS en nuestro sitio web y confirmemos que el sitio web:

• Se puede llegar directamente a través de la https:// Prefijo.
• Redirige de HTTP a HTTPS si se usa http:// Prefijo.

Dado que la redirección de HTTPS está funcionando, hemos corregido tres de nuestras cuatro advertencias iniciales (#2, 3 y 4). Nuestra preocupación restante es HSTS.

Paso 4: Hacer cumplir la política HSTS

HTTP Strict Transport Security (HSTS) restringe los navegadores compatibles para que solo usen HTTPS para conectarse a nuestro sitio web. La primera vez que se accede a nuestro sitio web a través de un navegador compatible y a través de HTTPS, HSTS devuelve un Strict-Transport-Security Respuesta de encabezado que impide el acceso HTTP desde este punto en adelante.

A diferencia de la redirección HTTPS estándar, que es específica del sitio, la redirección HSTS se aplica a todo un dominio. En otras palabras, sin el soporte de HSTS, un sitio web de mil páginas podría cargar con mil solicitudes de redirección HTTPS únicas.

Además, HSTS utiliza su propio caché independiente, que permanece intacto incluso si un usuario elimina su caché "normal".

Para implementar el soporte de HSTS estamos actualizando nuestra aplicación settings.py Archivo:

 if not USE_SSL:
     SECURE_PROXY_SSL_HEADER = None
     SECURE_SSL_REDIRECT = False
     SESSION_COOKIE_SECURE = False
     CSRF_COOKIE_SECURE = False
+    SECURE_HSTS_INCLUDE_SUBDOMAINS = False
+    SECURE_HSTS_PRELOAD = False

Luego salta al final de la else Bloquea justo después y agrega estas líneas:

   # IMPORTANT:
   # (-) Add these only once the HTTPS redirect is confirmed to work
   #
   # (security.W004)
   SECURE_HSTS_SECONDS = 3600  # 1 hour
   SECURE_HSTS_INCLUDE_SUBDOMAINS = True
   SECURE_HSTS_PRELOAD = True

Actualizamos tres configuraciones para habilitar HSTS como se recomienda en la documentación de Django y optamos por enviar nuestro sitio a la lista de precarga del navegador. Usted puede recordar que nuestro (security.W004) advirtió contra la activación imprudente de HSTS. Para evitar fallas relacionadas con HSTS activado prematuramente, establecemos el valor para SECURE_HSTS_SECONDS hasta una hora; Este es el momento en que su sitio web se rompería si se configurara incorrectamente. Probaremos HSTS con este valor más pequeño para confirmar que la configuración del servidor es compatible antes de aumentarla; una opción común es 31536000 segundos o un año.

Ahora que hemos implementado los cuatro pasos de seguridad, nuestro sitio web está equipado con una lógica de redirección HTTPS combinada con un encabezado HSTS, lo que garantiza que las conexiones sean compatibles con la seguridad adicional de SSL.

Un beneficio adicional de codificar nuestra lógica de contratación en torno a la USE_SSL variable de configuración es que una sola instancia de código (la settings.py file) funciona tanto en nuestro sistema de desarrollo como en nuestros servidores de producción.

Django seguridad para su tranquilidad

Asegurar un sitio web no es una tarea fácil, pero Django lo hace posible en unos pocos pasos simples pero cruciales. La plataforma de desarrollo de Django hace que sea relativamente fácil proteger un sitio web, ya sea un experto en seguridad o un principiante. He implementado con éxito innumerables aplicaciones de Django en Heroku y duermo bien por la noche, al igual que mis clientes.

El Blog de Ingeniería de Toptal dice gracias Stephen Harris Davidson para revisar y realizar una prueba beta de los ejemplos de código presentados en este artículo.

Lectura adicional en el blog de ingeniería de Toptal: