Consejos de seguridad para Django

¡Qué suerte tienes, usuario del framework web para perfeccionistas con plazos (también conocido como Django)! El equipo de Django ha dedicado mucho tiempo a pensar en sus prácticas de seguridad (encuentra funciones de seguridad en su documentación y también es interesante su política de seguridad). Resumimos algunos de los mejores consejos para mantener seguro tu proyecto de Django.

Descarga nuestra guía rápida de consejos de seguridad para Django.

Conoce tu versión y usa una segura

¿Qué versión de Django usas? Actualmente hay tres versiones principales de Django en uso (aunque el soporte a largo plazo para la versión 1.11 termina en abril de 2020). La versión de Django que usas tiene varias implicaciones para tu proyecto. Por ejemplo, Django 1.11 es la última versión compatible con Python 2, cuyo soporte terminó a principios de 2020.

Además, la versión que elijas determina qué vulnerabilidades conocidas están presentes y podrían explotarse en tu aplicación. Obtén más información sobre las vulnerabilidades conocidas de Django en nuestra base de datos de vulnerabilidades o analiza tu proyecto con Snyk, y te avisaremos si usas una versión vulnerable.

Por último, es importante que tengas un plan para mantener actualizada tu versión de Django. Por lo general, es buena idea elegir una versión con soporte a largo plazo y planear la migración a la siguiente antes de que termine el soporte de tu versión actual. Así contarás con el soporte de los encargados de mantenimiento, sin tener que cambiar de versión constantemente.

Como nota adicional, asegúrate de consultar la documentación de la versión correcta de Django. No querrás creer que existe una política de seguridad porque la leíste en la documentación y luego descubrir que había una diferencia entre la versión que usas y la de la documentación que consultaste.

Limita los intentos de autenticación de usuarios

Django incluye muchas funciones de seguridad, pero el sistema de autenticación no protege por sí solo contra ataques de fuerza bruta. Un actor malicioso podría realizar numerosos intentos de inicio de sesión en tu sistema y posiblemente entrar.

Si te preocupa este tipo de ataque en tu proyecto, usa un proyecto como Django Defender para bloquear a los usuarios después de demasiados intentos de inicio de sesión.

Protege tu código fuente

Proteger tu código fuente puede parecer un paso obvio, pero abarca varios aspectos y, por lo tanto, vale la pena analizarlo. Una forma de proteger tu código fuente es asegurarte de que no esté incluido en el directorio raíz de tu servidor web. Si lo está, existe la posibilidad de que se sirva o de que parte de él se ejecute de una manera que no habías previsto.

Aunque no hace falta decirlo, si tu proyecto es confidencial, asegúrate de usar un repositorio privado en GitHub, Bitbucket o Gitlab. Además, nunca guardes tus secretos en el sistema de control de versiones, tanto si tienes previsto usar un repositorio privado como si no. Es posible que un repositorio privado no siempre siga siendo privado, y no siempre puedes confiar en quienes tienen acceso a él.

Usa consultas sin procesar y SQL personalizado con precaución

Aunque puede ser tentador escribir consultas SQL sin procesar y SQL personalizado, hacerlo puede abrir la puerta a un ataque. El framework de mapeo objeto-relacional (ORM) de Django está diseñado para facilitar las consultas a tu base de datos. Los conjuntos de consultas se construyen mediante la parametrización de consultas. Los parámetros de consulta se abstraen del código SQL de las consultas. Si siempre usas el ORM, será mucho más difícil que un usuario realice una inyección SQL (ejecute SQL arbitrario en una base de datos).

Django permite usar consultas sin procesar, pero no se recomienda. Si las usas, ten mucho cuidado de escapar correctamente todos los parámetros. Si el ORM de Django no es suficiente para tus necesidades, puedes usar otro ORM en Django. SQLAlchemy es un ejemplo de ORM que puedes usar con Django. Si hay un ORM que se adapte mejor a tu proyecto, es preferible usarlo en lugar de escribir muchas consultas SQL sin procesar.

Usa HTTPS

Independientemente del framework que elijas, siempre es preferible implementar tu aplicación detrás de HTTPS. Esto evita que usuarios maliciosos intercepten la información que se envía entre el cliente y el servidor. Para que HTTPS funcione correctamente, es importante configurar bien los ajustes.

Los siguientes ajustes son importantes para usar HTTPS. Asegúrate de entenderlos y habilitarlos correctamente. La documentación explica bien los ajustes, los valores predeterminados seguros y por qué quizá debas cambiarlos en determinadas circunstancias.

• SECURE_PROXY_SSL_HEADER

• SECURE_SSL_REDIRECT

• SESSION_COOKIE_SECURE

• CSRF_COOKIE_SECURE

• SECURE_HSTS_SECONDS

• SECURE_HSTS_INCLUDE_SUBDOMAINS

• SECURE_HSTS_PRELOAD

Vigila tus encabezados

Primero, queremos centrarnos en el encabezado de solicitud referer. Este encabezado contiene la dirección de la página web anterior desde la que llegaste a la página actual. Esta información es útil, entre otras cosas, para el análisis. Sin embargo, a veces causa problemas porque, por lo general, a las personas no les gusta que las sigan por la web. Por motivos de privacidad, es posible deshabilitar esta función. El encabezado referer-policy determina si se envía el encabezado de solicitud referer. En ciertas condiciones, se envía información parcial; en otras, se incluye toda la información y, a veces, no se reenvía ningún dato del encabezado de solicitud referer.

Cuando el sitio se sirve mediante HTTPS, Django utiliza el encabezado de solicitud referer para ayudar a prevenir ataques de falsificación de solicitudes entre sitios (CRSF). Si configuras el encabezado referer-policy de forma demasiado estricta, deshabilitas la protección CRSF de Django. En definitiva, debes sopesar los beneficios de privacidad de usar un encabezado referer-policy estricto frente a las ventajas de la protección CRSF. Puedes encontrar un punto medio si habilitas únicamente los referentes del mismo origen en el encabezado referer-policy.

Ten cuidado con las cookies

Algunas cookies son más seguras que otras: el comportamiento predeterminado es que se conecten mediante HTTP. Sin embargo, como ya establecimos que debes usar HTTPS, también debes asegurarte de que tus cookies solo se envíen mediante HTTPS. Para evitar que se filtren, asegúrate de configurar SESSION_COOKIE_SECURE y CSRF_COOKIE_SECURE en True. Esto indica al navegador que solo envíe estas cookies a través de conexiones HTTPS. Configurar estos parámetros en true tiene algunos efectos secundarios interesantes, pero puedes mitigarlos redirigiendo el tráfico HTTP a HTTPS.

Maneja con cuidado las cargas de archivos de usuarios

Si tu aplicación web permite que los usuarios carguen archivos, estás abriendo una vía de ataque y, por lo tanto, debes manejar cuidadosamente la lógica de carga. Primero, es importante validar todos los archivos cargados para asegurarte de que sean lo que esperas (por ejemplo, un archivo de imagen y no un script PHP). No querrás que un usuario pueda ejecutar código.

Hay varias medidas que ayudan a validar los archivos cargados o a manejarlos con más cuidado. Entre ellas se incluyen las siguientes:

• Crea una lista de tipos de archivo permitidos

• Limita el tamaño permitido de los archivos cargados para evitar problemas de denegación de servicio

• Deshabilita los manejadores que ejecutarían archivos estáticos como código (por ejemplo, deshabilita mod_php de Apache)

• Aprovecha las protecciones contra secuencias de comandos entre sitios. Si sirves el contenido de los usuarios desde un dominio de nivel superior distinto, se activarán las protecciones contra secuencias de comandos entre sitios. Puede ser un dominio que administres, aunque probablemente sea más fácil servir los archivos desde un servicio en la nube o un proveedor de red de distribución de contenido.

Comprende todas tus dependencias

Si elegiste una versión de Django con pocos o ningún riesgo de seguridad conocido, quizá pienses que ya no hay otros problemas de seguridad que debas considerar. Sin embargo, es importante comprender qué bibliotecas de código abierto importa Django y si tienen vulnerabilidades.

Cuando incluyes Django (o cualquier biblioteca de código abierto), normalmente también estás incluyendo todas las bibliotecas que utiliza la biblioteca que elegiste. El código abierto se construye sobre código abierto, que a su vez se construye sobre más código abierto.

Las dependencias indirectas pueden introducir tantos riesgos como las directas, pero es menos probable que se detecten. Una herramienta como Snyk te ayuda a comprender todo el árbol de dependencias, y ahora que Snyk ofrece pull request de corrección para Python, solucionar problemas (incluso en dependencias indirectas) es más fácil que nunca.

No dejes que lo perfecto sea enemigo de lo bueno

Cada medida de seguridad que tomas es un paso en la dirección correcta. Puede que Django sea para perfeccionistas con plazos, pero el código no tiene que ser perfecto para obtener beneficios de seguridad. Implementar los conceptos que mencionamos, en la medida de tus posibilidades, puede mejorar significativamente la seguridad de tu código y dar como resultado un proyecto más saludable y resiliente. ¡A programar, Pythonistas!