Tests de sécurité - Politique de sécurité de Django Defense

Django Sécurité
Django dispose d'un certain traitement pour la sécurité. Apprendre à traiter les paramètres est également propice à l'apprentissage des connaissances en matière de tests de sécurité.

CSRF

Cross-Site Request Forgery (Cross-Site Request Forgery, CSRF) est une méthode d'attaque réseau dans laquelle les attaquants trompent les utilisateurs pour qu'ils effectuent des opérations malveillantes sur les sites Web qu'ils visitent et envoient des demandes sans l'autorisation de l'utilisateur en utilisant l'identité et les autorisations actuelles de l'utilisateur.

En termes simples, disons que vous naviguez sur un site de réseau social et que vous êtes connecté. Dans un autre onglet, vous avez cliqué sur un lien malveillant reçu par e-mail ou autrement, et vous n'avez pas réalisé qu'il était malveillant. Le lien est en fait une demande adressée au site Web de votre banque et l'attaquant a inclus certaines actions malveillantes dans le lien, telles que le transfert d'argent sur le compte de l'attaquant. Si vous êtes connecté sur un site Web bancaire qui ne dispose pas de défenses CSRF, cette opération malveillante pourrait réussir.

Défenses communes

Pour vous défendre contre les attaques CSRF, voici quelques défenses couramment utilisées :

1. Jeton CSRF : l'application peut générer un jeton CSRF unique pour chaque utilisateur et l'intégrer dans la requête. Chaque requête POST soumise doit inclure ce jeton et être validée côté serveur. De cette manière, un site Web malveillant ne peut pas obtenir un jeton valide et ne peut pas construire correctement une requête.

2. Cookie SameSite : en définissant l'attribut SameSite sur Strict ou Lax, vous pouvez restreindre l'attachement automatique des cookies uniquement aux demandes initiées par le même site. Cela empêche les attaques de requêtes intersites.

3. Vérifier le nom de domaine source : Le serveur peut vérifier le nom de domaine source de la requête, et si la requête ne provient pas d'un nom de domaine légal, il refusera d'effectuer l'opération. L'origine peut être vérifiée à l'aide de l'en-tête Referer, de l'en-tête Origin ou en vérifiant le champ host.

4. Double confirmation : pour les opérations sensibles, les utilisateurs peuvent être invités à saisir des informations de confirmation supplémentaires, telles que des mots de passe, des codes de vérification, etc., pour ajouter une couche de sécurité supplémentaire.

5. Pratiques de codage sécurisées : les développeurs doivent suivre des pratiques de codage sécurisées, telles que échapper et valider correctement les entrées de l'utilisateur, éviter de divulguer des informations sensibles dans les demandes, etc.

Ces défenses peuvent augmenter la sécurité de votre site Web contre les attaques CSRF. Cependant, la situation de chaque site Web peut être différente. Il est très important de personnaliser et d'appliquer une stratégie de défense CSRF adaptée à votre propre application en tenant compte de manière globale d'autres facteurs tels que les messages d'erreur, le contrôle d'accès et l'audit de sécurité.

Django-défense

1) Le middleware CSRF est activé par défaut dans la configuration MIDDLEWARE. Si vous remplacez cette configuration, n'oubliez pas que « django.middleware.csrf.CsrfViewMiddleware » doit précéder tout middleware de vue qui suppose que les attaques CSRF ont été gérées.
2) Dans le modèle utilisant le formulaire POST, le modèle ajoute

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

Injection SQL

L'injection SQL permet à des utilisateurs malveillants d'exécuter du code SQL arbitraire dans la base de données. Cela entraînera la suppression ou la compromission des enregistrements.

Les ensembles de requêtes de Django sont protégés de l'injection SQL car ils sont construits à partir de requêtes paramétrées. Le code SQL de la requête est défini séparément des paramètres de la requête. Les paramètres peuvent provenir de l'utilisateur et donc être dangereux, ils sont donc échappés par le moteur de base de données sous-jacent.

Django offre également aux développeurs le pouvoir d'écrire des requêtes brutes ou d'exécuter du SQL personnalisé. Ces méthodes doivent être utilisées avec autant de parcimonie que possible et vous devez veiller à échapper correctement à tout paramètre contrôlable par l'utilisateur. Des précautions doivent également être prises lors de l'utilisation de extra() avec RawSQL.

Défense contre le détournement de clics-Protection contre le détournement de clics

Empêcher l'intégration de pages Web dans d'autres iframes
Les navigateurs prennent en charge l'en-tête HTTP X-Frame-Options, qui indique si les ressources peuvent être chargées dans des frames ou des iframes. Si la réponse contient un en-tête avec la valeur SAMEORIGIN, le navigateur ne chargera la ressource dans le cadre que si la requête provient du même site Web. Si l'en-tête est défini sur DENY, le navigateur empêchera le chargement de la ressource dans le cadre, quel que soit le site Web à partir duquel la demande est effectuée.

Django détournement de clic

https://docs.djangoproject.com/zh-hans/4.2/ref/clickjacking/#clickjacking-prevention
Supposons qu'une boutique en ligne ait une page sur laquelle les utilisateurs connectés peuvent cliquer sur « Acheter maintenant » pour acheter des articles. Pour plus de commodité, l'utilisateur choisit de rester connecté au magasin. Un site attaquant pourrait créer un bouton « J'aime les poneys » sur l'une de ses pages et charger la page du magasin dans une iframe transparente, avec le bouton « Acheter maintenant » superposé de manière invisible au-dessus du bouton « J'aime les poneys ». Si un utilisateur visite le site Web de l'attaquant, en cliquant sur « J'aime les poneys », il cliquera par inadvertance sur le bouton « Acheter maintenant » et achètera l'article à son insu.

Instance de défense Django

Si vous accédez directement à l'application Django,


vous pouvez voir que X-Frame-Options est défini sur DENY, ce qui interdit l'intégration d'autres iframes.

Un html contenant une iframe intègre l'adresse

<!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>

Visitez ce code HTML et constatez que la page Web ne peut pas être affichée

Attaque de contenu téléchargé par l'utilisateur

Les attaques de contenu téléchargé par les utilisateurs font référence à des utilisateurs malveillants ou à des attaquants qui téléchargent du contenu contenant du code malveillant ou des fichiers malveillants sur un site Web ou une application à des fins d'attaque ou d'abus.

Cette attaque peut entraîner les problèmes de sécurité suivants :

1. Injection de code : un attaquant peut télécharger des fichiers contenant des scripts malveillants qui seront exécutés dans les navigateurs d'autres utilisateurs lorsqu'ils accéderont à ces fichiers. Ce type d'attaque est appelé injection de code ou exécution de code à distance (Remote Code Execution, RCE), qui peut amener le navigateur de l'utilisateur attaqué à être contrôlé et à effectuer des opérations malveillantes arbitraires.

2. Vulnérabilités d'inclusion de fichiers : un attaquant peut télécharger des fichiers contenant des données sensibles ou des chemins de fichiers système pour découvrir et exploiter les vulnérabilités d'inclusion de fichiers. En exploitant ces vulnérabilités, un attaquant pourrait lire, remplacer ou supprimer des fichiers importants sur le système.

3. Distribution de fichiers malveillants : les attaquants peuvent télécharger des fichiers contenant des logiciels malveillants, des virus ou des ransomwares. Lorsque d'autres utilisateurs téléchargent ou exécutent ces fichiers, leurs ordinateurs peuvent être infectés ou exposés à des menaces telles que des fuites de données, des corruptions de données ou des ransomwares.

Mesures de sécurité communes

Pour vous défendre contre les attaques de contenu téléchargé par les utilisateurs, voici quelques mesures de sécurité couramment utilisées :

1. Vérification du type de fichier : limitez les types de fichiers téléchargés par les utilisateurs et vérifiez l'extension et le type MIME des fichiers téléchargés. Seuls les types de fichiers fiables et sûrs peuvent être téléchargés, et les types de fichiers inconnus ou à haut risque sont rejetés.

2. Limite de taille de fichier : Limitez la taille des fichiers téléchargés pour éviter de dépasser la capacité de traitement du serveur ou de l'application.

3. Correctifs de vulnérabilités de confinement de fichiers et configurations de sécurité : assurez-vous que l'application a résolu les problèmes de code susceptibles d'entraîner des vulnérabilités de confinement de fichiers et dispose de configurations de sécurité appropriées sur le serveur pour restreindre l'accès aux fichiers sensibles et éviter d'exposer des informations telles que les chemins système.

4. Stockage de fichiers sécurisé : stockez les fichiers téléchargés par l'utilisateur dans un emplacement sécurisé et prenez des mesures pour garantir que les fichiers ne peuvent pas être exécutés ou téléchargés via un accès direct. Stockez les fichiers téléchargés dans des répertoires non accessibles sur le Web et utilisez des scripts côté serveur pour fournir des interfaces de lecture et de téléchargement sécurisées.

5. Pratiques de codage sécurisées : pendant le développement, utilisez des techniques appropriées de validation d'entrée et de codage de sortie pour éviter les problèmes de sécurité tels que l'injection de code et les scripts intersites (XSS).

Pour résumer, les attaques de contenu téléchargé par les utilisateurs constituent une menace sérieuse pour la sécurité. Des mesures de sécurité appropriées doivent être prises lors de la conception, du développement et de la maintenance des applications pour se défendre contre de telles attaques, et des audits de sécurité et des analyses de vulnérabilité réguliers doivent être effectués ainsi que réparations en temps opportun. Vulnérabilités trouvées.

suggestion-django

1) Envisagez de diffuser des fichiers statiques à partir d'un service cloud ou d'un CDN pour éviter de tels problèmes.
2) Limitez ces fichiers téléchargés à une taille raisonnable dans la configuration du serveur Web pour éviter les attaques par déni de service (DOS). Dans Apache, vous pouvez utiliser la directive LimitRequestBody
3) Assurez-vous que les gestionnaires comme mod_php d'Apache qui peuvent exécuter des fichiers statiques sous forme de code sont désactivés
4) Définissez éventuellement une liste pour limiter les extensions de fichiers que les utilisateurs sont autorisés à télécharger

autre suggestion

1. Assurez-vous que votre code Python se trouve en dehors du répertoire racine du serveur Web. Cela garantira que votre code Python n'est pas accidentellement servi (ou exécuté accidentellement) sous forme de texte brut.
2. Soyez prudent avec tous les fichiers téléchargés par les utilisateurs. Django ne limite pas les requêtes des utilisateurs authentifiés. Pour empêcher les attaques par force brute contre le système d'authentification, vous pouvez envisager de déployer un plugin Django
   ou un module de serveur Web pour limiter ces requêtes.
3. Gardez votre SECRET_KEY et SECRET_KEY_FALLBACKS s'ils sont utilisés, secrets. C'est une bonne idée de restreindre l'accessibilité des systèmes de cache et des bases de données avec un pare-feu.
4. Jetez un œil à la liste des 10 meilleurs projets de sécurité des applications Web Open Source (OWASP), qui spécifie certaines vulnérabilités courantes dans les applications Web. Si Django
   dispose des outils nécessaires pour résoudre certains problèmes, d’autres doivent être pris en compte lors de la conception du projet.
   Édition 2023 : https://owasp.org/API-Security/editions/2023/en/0x11-t10/
5. Mozilla aborde de nombreux sujets liés à la sécurité Web. Leur page Web comprend également des principes de sécurité qui s'appliquent à tout système.