J'utilise django Authentification distante de l'utilisateur dans un projet. Ce que j'utilise réellement est juste lire la source du middleware, il semble que cela prend simplement le nom d'utilisateur d'un en-tête de la demande puis authentifie l'utilisateur contre le backend qui passe ce nom d'utilisateur. Le backend de l'utilisateur distant, à son tour, il suffit de joindre joyeusement l'utilisateur avec tout ce que l'utilisateur a été passé. L'utilisateur a ensuite accès à chaque domaine nécessitant une connexion valide.
N'est-ce pas juste une énorme défaut de sécurité? Comment cela est-il destiné à être utilisé?
Dans mon cas, je devrais être en sécurité, car le seul appel à django.contrib.auth.remoteuserbackend sans le middleware et appeler manuellement authentifier après avoir vérifié avec le backend que l'utilisateur est légitime.
authentifier vient après une vérification de l'identité distante réussie, mais je me demande la raison pour laquelle le middleware a été introduit.
3 Réponses :
Django 'enregistre joyeusement l'utilisateur dans' car votre serveur Web a vérifié que le visiteur a des informations d'identification valides pour ce nom d'utilisateur et définissez l'en-tête en conséquence.
Si vous faites confiance à votre serveur Web (E.G. Apache) pour définir le Remote_User (ou un autre) en-tête correctement, ce n'est pas une faille de sécurité.
Je ne comprends toujours pas. C'est juste un en-tête de la demande. Pourquoi un attaquant ne peut-il pas simplement la définir manuellement lors de la délivrance de la demande?
Django s'appuie sur le serveur Web pour définir l'en-tête correctement. Si le serveur Web permet à l'utilisateur de régler la tête manuellement, il y a un trou de sécurité.
Je comprends, mais le point est que vous devez instruire en quelque sorte le serveur Web de supprimer cet en-tête de la demande. Les en-têtes sont pour la plupart gardés inchangés. Ils font partie de la demande , ils sont donc une entrée utilisateur. Je pense que cela devrait mériter au moins un avis.
Ce n'est pas mon domaine d'expertise. À moins que quelqu'un d'autre ne puisse offrir un aperçu, je pense que nous allons faire le tour en cercles. En fin de compte, si vous utilisez une méthode d'authentification distante, je pense que c'est votre responsabilité de comprendre comment cela fonctionne et comment la configurer correctement. Toutefois, si vous pensez que la documentation peut être améliorée, je vous recommande de soumettre un correctif.
Un regard rapide sur le code source indique clairement que ce middleware et ce backend ne vérifient pas du tout le mot de passe / les informations d'identification. Il s'appuie simplement sur l'attribut Remote_user et va même de l'avant et crée un nouvel utilisateur avec ce nom d'utilisateur si on n'existe pas, tout sans confirmation du mot de passe est correct. Andrea, je suis d'accord avec toi, je ne sais pas pourquoi je voudrais toujours un trou de sécurité comme celui-ci dans mon code.
La création de l'utilisateur est documenté ici . La télécommande ne vérifie pas le mot de passe car l'utilisateur a déjà authentifié avec la source d'authentification distante. Où se trouve le trou de sécurité si la source d'authentification distante et le serveur Web sont configurés correctement?
Je ne comprends toujours pas votre réponse. Remote_USER est un en-tête de la Demande . Pourquoi un attaquant ne peut-il pas simplement envoyer cet en-tête avec sa demande? Je suppose que l'on peut configurer le serveur Web pour dépasser cet en-tête avant d'arriver à Django, mais je pense que les utilisateurs devraient en être informés.
La mise en œuvre par défaut s'appuie sur une variable d'environnement distant_utilisateur à définir. Si je comprends bien, un utilisateur ne pouvait pas forger cela, car un en-tête HTTP serait mappé sur http_remote_user dans django's demande.meta Dictionnaire. Si vous sous-classez le middleware et définissez un en-tête personnalisé , alors oui, un utilisateur pourrait envoyer cet en-tête . Comme je l'ai déjà dit, si vous comptez sur le serveur Web pour faire une authentification, il est important que le serveur Web soit configuré correctement.
Encore une fois, si la documentation peut être rendue plus claire, veuillez soumettre un correctif. Commentaires sans fin ici n'aide personne.
Ce n'est pas un en-tête HTTP. C'est une variable de côté serveur.
C'est WSGI env variable, pas un en-tête HTTP. C'est un attribut de l'objet de demande python pas un attribut de votre demande HTTP. Aucune quantité de fidélisation avec la demande HTTP ne définira que Var à sauf si vous avez délibérément configuré un serveur pour le faire.
Permettez-moi de tourner cela autour de vous: si vous pensez que c'est une faille de sécurité, essayez d'écrire un exploit qui définit l'en-tête Remote_user dans une demande de votre application et voyez ce qui se passe.
Tous les en-têtes passés par l'utilisateur commencent par REMOTE_USER remonte aux premiers jours du Web lorsque les pages CGI ont été exécutées localement comme l'utilisateur que vous frappiez la page Web avec. Remote_USER est en réalité le nom d'une variable d'environnement UNIX qui indique l'utilisateur actif. Les modèles de sécurité pour les serveurs Web ont changé, ce régime a été préservé pour la compatibilité. Maintenant, même IIS le supporte de gérer de manière transparente les connexions Active Directory.
http _ . Sinon, vous ne pouvez faire confiance à aucune information d'en-tête, comme Server_Name , qui serait un énorme désordre.
Merci d'avoir expliqué le préfixe HTTP!
Vous pouvez voir la documentation ici . Un utilisateur ne peut pas envoyer de demande avec un en-tête client pour AVERTISSEMENT
Soyez très prudent si vous utilisez une sous-classe UTILISMORDDDLEWAREWARE avec une en-tête HTTP personnalisée. Vous devez être sûr que votre serveur Web front-end définit toujours ou des bandes que l'en-tête basé sur les vérifications d'authentification appropriées, ne permettant jamais à un utilisateur final de soumettre une valeur d'en-tête fausse (ou «blanchie»). Étant donné que les en-têtes HTTP X-Auth-User et X-Auth_User (par exemple) sont tous deux normalisés à la touche http_x_auth_user dans demande.Meta, vous devez également vérifier que votre serveur Web n'autorise pas un en-tête blindé à l'aide de sous-traitants à la place des tirets.
Cet avertissement ne s'applique pas à la télémèneMermiddleware dans sa configuration par défaut avec Header = 'Remote_user', car une touche qui ne démarre pas avec http_ dans demande.meta ne peut être définie que par votre serveur WSGI, non directement à partir d'un HTTP. Demande d'en-tête.
distant_user .