Pruebas de seguridad: política de seguridad de Django Defense

Seguridad de Django
Django tiene cierto procesamiento para la seguridad. Aprender a procesar la configuración también ayuda a aprender conocimientos sobre pruebas de seguridad.

CSRF

La falsificación de solicitudes entre sitios (Cross-Site Request Forgery, CSRF) es un método de ataque de red en el que los atacantes engañan a los usuarios para que realicen operaciones maliciosas en los sitios web que visitan y envían solicitudes sin el permiso del usuario utilizando la identidad y los permisos actuales del usuario.

En términos sencillos, digamos que estás navegando en un sitio de redes sociales y has iniciado sesión. En otra pestaña, hiciste clic en un enlace malicioso que recibiste por correo electrónico o de otro modo, y no te diste cuenta de que era malicioso. El enlace es en realidad una solicitud al sitio web de su banco y el atacante ha incluido algunas acciones maliciosas en el enlace, como transferir dinero a la cuenta del atacante. Si ha iniciado sesión en un sitio web bancario que no cuenta con defensas CSRF, esta operación maliciosa podría tener éxito.

Defensas comunes

Para defenderse de los ataques CSRF, las siguientes son algunas defensas comúnmente utilizadas:

1. Token CSRF: la aplicación puede generar un token CSRF único para cada usuario e incrustarlo en la solicitud. Cada solicitud POST enviada debe incluir este token y validarse en el lado del servidor. De esta manera, un sitio web malicioso no puede obtener un token válido y no puede construir correctamente una solicitud.

2. Cookie SameSite: al configurar el atributo SameSite en Estricto o Laxo, puede restringir que las cookies se adjunten automáticamente solo a las solicitudes iniciadas por el mismo sitio. Esto evita ataques de solicitudes entre sitios.

3. Verificar el nombre de dominio de origen: el servidor puede verificar el nombre de dominio de origen de la solicitud y, si la solicitud no proviene de un nombre de dominio legal, se negará a realizar la operación. El origen se puede verificar utilizando el encabezado Referer, el encabezado Origin o verificando el campo host.

4. Doble confirmación: para operaciones confidenciales, se puede solicitar a los usuarios que ingresen información de confirmación adicional, como contraseñas, códigos de verificación, etc., para agregar una capa adicional de seguridad.

5. Prácticas de codificación segura: los desarrolladores deben seguir prácticas de codificación segura, como escapar y validar adecuadamente la entrada del usuario, evitar revelar información confidencial en las solicitudes, etc.

Estas defensas pueden aumentar la seguridad de su sitio web contra ataques CSRF. Sin embargo, la situación de cada sitio web puede ser diferente, por lo que es muy importante personalizar y aplicar una estrategia de defensa CSRF adecuada para su propia aplicación considerando de manera integral otros factores como mensajes de error, control de acceso y auditoría de seguridad.

defensa-django

1) El middleware CSRF está activado de forma predeterminada en la configuración de MIDDLEWARE. Si anula esta configuración, recuerde que 'django.middleware.csrf.CsrfViewMiddleware' debe solicitarse antes de cualquier middleware de vista que asuma que se han manejado ataques CSRF.
2) En la plantilla que utiliza el formulario POST, la plantilla agrega

<form method="post">{% csrf_token %}

inyección SQL

La inyección SQL permite a usuarios malintencionados ejecutar código SQL arbitrario en la base de datos. Esto resultará en que los registros se eliminen o se vean comprometidos.

Los conjuntos de consultas de Django están protegidos contra la inyección de SQL ya que se construyen a partir de consultas parametrizadas. El código SQL de la consulta se define por separado de los parámetros de la consulta. Los parámetros pueden provenir del usuario y, por lo tanto, no ser seguros, por lo que el motor de base de datos subyacente los escapa.

Django también brinda a los desarrolladores el poder de escribir consultas sin formato o ejecutar SQL personalizado. Estos métodos deben usarse con la menor moderación posible y debe tener cuidado de escapar adecuadamente de cualquier parámetro controlable por el usuario. Además, se debe tener cuidado al utilizar extra() con RawSQL.

Defensa contra el clickjacking-Protección contra el clickjacking

Evite que las páginas web se incrusten en otros iframes.
Los navegadores admiten el encabezado HTTP X-Frame-Options, que indica si los recursos pueden cargarse en marcos o iframes. Si la respuesta contiene un encabezado con el valor SAMEORIGIN, el navegador solo cargará el recurso en el marco si la solicitud proviene del mismo sitio web. Si el encabezado está configurado en DENEGAR, el navegador evitará que el recurso se cargue en el marco, sin importar desde qué sitio web se realice la solicitud.

secuestro de clics con django

https://docs.djangoproject.com/zh-hans/4.2/ref/clickjacking/#clickjacking-prevention
Supongamos que una tienda en línea tiene una página donde los usuarios que han iniciado sesión pueden hacer clic en "Comprar ahora" para comprar artículos. Para mayor comodidad, el usuario elige permanecer conectado a la tienda. Un sitio atacante podría crear un botón "Me gustan los ponis" en una de sus páginas y cargar la página de la tienda en un iframe transparente, con el botón "Comprar ahora" superpuesto de forma invisible encima del botón "Me gustan los ponis". Si un usuario visita el sitio web del atacante, al hacer clic en "Me gustan los ponis", sin darse cuenta, hará clic en el botón "Comprar ahora" y comprará el artículo sin su conocimiento.

Ejemplo de defensa de Django

Si accede directamente a la aplicación Django,


puede ver que X-Frame-Options está configurado en DENY, lo que prohíbe incrustar otros iframes.

Un html que contiene un iframe incrusta la dirección

<!DOCTYPE html>
<html>
<head>
    <title>包含 iframe 的页面</title>
</head>
<body>
    <h1>这是一个包含 iframe 的页面</h1>
    
    <iframe src="http://127.0.0.1:8000/polls/" width="500" height="300"></iframe>
</body>
</html>

Visite este html y descubra que la página web no se puede mostrar

Ataque de contenido subido por el usuario

Los ataques de contenido subido por usuarios se refieren a usuarios malintencionados o atacantes que cargan contenido que contiene código malicioso o archivos maliciosos en un sitio web o aplicación para atacar o abusar.

Este ataque puede provocar los siguientes problemas de seguridad:

1. Inyección de código: un atacante puede cargar archivos que contengan scripts maliciosos que se ejecutarán en los navegadores de otros usuarios cuando accedan a esos archivos. Este tipo de ataque se denomina inyección de código o ejecución remota de código (Remote Code Execution, RCE), que puede provocar que el navegador del usuario atacado sea controlado y realice operaciones maliciosas arbitrarias.

2. Vulnerabilidades de inclusión de archivos: un atacante puede cargar archivos que contengan datos confidenciales o rutas de archivos del sistema para descubrir y explotar vulnerabilidades de inclusión de archivos. Al explotar estas vulnerabilidades, un atacante podría leer, reemplazar o eliminar archivos importantes del sistema.

3. Distribución de archivos maliciosos: los atacantes pueden cargar archivos que contengan malware, virus o ransomware. Cuando otros usuarios descargan o ejecutan estos archivos, sus computadoras pueden infectarse o quedar expuestas a amenazas como fuga de datos, corrupción de datos o ransomware.

Medidas de seguridad comunes

Para defenderse de los ataques de contenido subido por los usuarios, las siguientes son algunas medidas de seguridad utilizadas habitualmente:

1. Verificación del tipo de archivo: limite los tipos de archivos cargados por los usuarios y verifique la extensión y el tipo MIME de los archivos cargados. Sólo se permiten cargar tipos de archivos confiables y seguros, y se rechazan los tipos de archivos desconocidos o de alto riesgo.

2. Límite de tamaño de archivo: limite el tamaño de los archivos cargados para evitar exceder la capacidad de procesamiento del servidor o aplicación.

3. Correcciones de vulnerabilidades de contención de archivos y configuraciones de seguridad: asegúrese de que la aplicación haya solucionado problemas de código que podrían provocar vulnerabilidades de contención de archivos y tenga configuraciones de seguridad adecuadas en el servidor para restringir el acceso a archivos confidenciales y evitar exponer información como las rutas del sistema.

4. Almacenamiento seguro de archivos: almacene los archivos cargados por el usuario en una ubicación segura y tome medidas para garantizar que los archivos no se puedan ejecutar ni descargar mediante acceso directo. Almacene los archivos cargados en directorios a los que no se puede acceder desde la web y utilice scripts del lado del servidor para proporcionar interfaces seguras de lectura y descarga.

5. Prácticas de codificación segura: durante el desarrollo, utilice técnicas adecuadas de validación de entrada y codificación de salida para evitar problemas de seguridad como la inyección de código y secuencias de comandos entre sitios (XSS).

En resumen, el ataque al contenido subido por el usuario es una grave amenaza a la seguridad. Se deben tomar medidas de seguridad adecuadas durante el diseño, desarrollo y mantenimiento de las aplicaciones para defenderse contra dichos ataques, y se deben realizar auditorías de seguridad y análisis de vulnerabilidades periódicamente, así como reparaciones oportunas Vulnerabilidades encontradas.

sugerencia-django

1) Considere la posibilidad de servir archivos estáticos desde un servicio en la nube o CDN para evitar este tipo de problemas.
2) Limite estos archivos cargados a un tamaño razonable en la configuración del servidor web para evitar ataques de denegación de servicio (DOS). En Apache, puede usar la directiva LimitRequestBody
3) Asegúrese de que los controladores como mod_php de Apache que pueden ejecutar archivos estáticos como código estén desactivados
4) Opcionalmente, defina una lista para limitar las extensiones de archivos que los usuarios pueden cargar

otra sugerencia

1. Asegúrese de que su código Python esté fuera del directorio raíz del servidor web. Esto garantizará que su código Python no se entregue (o ejecute accidentalmente) como texto sin formato.
2. Tenga cuidado con todos los archivos cargados por usuarios. Django no limita las solicitudes de usuarios autenticados. Para evitar ataques de fuerza bruta contra el sistema de autenticación, podría considerar implementar un
   complemento de Django o un módulo de servidor web para limitar estas solicitudes.
3. Mantenga en secreto su SECRET_KEY y SECRET_KEY_FALLBACKS si está en uso. Es una buena idea restringir el acceso a los sistemas de caché y bases de datos con un firewall.
4. Eche un vistazo a la lista de las 10 principales del Proyecto de seguridad de aplicaciones web de código abierto (OWASP), que especifica algunas vulnerabilidades comunes en las aplicaciones web. Si bien Django
   tiene las herramientas para resolver algunos problemas, otros deben considerarse en el diseño del proyecto.
   Edición 2023: https://owasp.org/API-Security/editions/2023/en/0x11-t10/
5. Mozilla analiza muchos temas relacionados con la seguridad web. Su página web también incluye principios de seguridad que se aplican a cualquier sistema.