Le nom d'utilisateur curl -u: mot de passe http://example.com est-il sécurisé?

30

Est curl -u username:password http://example.comsécurisé?

Sinon, pouvez-vous expliquer brièvement comment quelqu'un pourrait obtenir votre mot de passe?

security curl JDiMatteo
la source
6
si vous l'utilisez dans un terminal, avez-vous à l'esprit que les deux informations d'identification sont stockées dans l'historique de bash?
Francisco Tapia
15
Une telle commande n'est pas sécurisée car un autre utilisateur peut utiliser ps -efpour voir quels processus sont en cours d'exécution. Lorsque vous curl -u username:password http://example.comapparaissez dans la liste, votre destination, nom d'utilisateur et mot de passe sont compromis.
Lambert
Bien que la question soit sur le sujet ici, vous pouvez également être intéressé par Information Security StackExchange
IQAndreas

Réponses:

54

Il n'est pas sûr, car cURL utilise par défaut l'authentification de base où le protocole HTTP envoie votre mot de passe en texte clair. Lorsque vous spécifiez la username:passwordchaîne, elle est convertie en chaîne BASE64 dans l'en-tête HTTP:

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Toute personne capable d'intercepter votre trafic HTTP (votre fournisseur, toute personne accédant au même point d'accès sans fil que vous, etc.) pourra récupérer le mot de passe en utilisant simplement un convertisseur BASE64 en ligne .

Le protocole HTTPS améliorera les choses en établissant une connexion cryptée avant l'envoi de cet en-tête, empêchant le mot de passe d'être révélé. Cependant, cela ne s'applique que si l'utilisateur fait attention lorsqu'il lui est demandé de confirmer des certificats inconnus, d'autoriser des exceptions de sécurité, etc.

Notez que les arguments de commande peuvent être disponibles pour que d'autres utilisateurs sur la même machine puissent voir, par exemple ps -ef, le système de fichiers / proc, dans votre historique bash, et dans votre journal de terminal (merci pour le commentaire de @ Lambert qui a noté cela). cURL sur certaines plates-formes tente de masquer le mot de passe, par exemple avec ps -efvous, vous verrez probablement un espace vide au lieu d'un mot de passe. Cependant, au lieu de passer le mot de passe comme argument de ligne de commande, il est préférable que cURL demande directement un mot de passe, comme indiqué dans la FAQ cURL .

Dmitry Grigoryev
la source
4
Même si vous êtes sur une plate-forme où curl écrase avec succès son propre argv pour masquer les données ps, il y a une période pendant le démarrage avant que l'écrasement ne soit effectué où ce contenu est vulnérable.
Charles Duffy
Qu'en est-il de l'authentification Digest? Curl ne l'utilise pas par défaut?
rr-
2
L'authentification @rr Digest est juste légèrement meilleure, car elle n'empêche pas les attaques de l'homme du milieu, il est donc préférable d'utiliser HTTPS.
Dmitry Grigoryev
1
@rr Comment affirmez-vous que StartSSL n'est pas approuvé par la plupart des navigateurs ? Vous attendez-vous à de nombreux utilisateurs de Windows 95 ou Firefox 1.5?
Hagen von Eitzen
1
@rr À mon humble avis, vous n'êtes pas fiable uniquement s'il y a un problème avec des certificats intermédiaires manquants (ou incorrects) sur le serveur
Hagen von Eitzen
24

Ce n'est pas sûr. Les paramètres de ligne de commande sont visibles pour tous les utilisateurs.

Tronic
la source
4
Fusionner avec @Dmitry Grigoryev réponse pourrait être la plus précise.
Francisco Tapia
1
Ouais, j'ai complètement raté la grande partie du problème que je dois admettre.
Dmitry Grigoryev
pourrait faire partie d'un script uniquement lisible par l'utilisateur ...
Pete
2
Les lignes de commande @Pete des programmes en cours d'exécution (qu'elles soient démarrées à partir d'un script ou d'un terminal) sont généralement visibles par tous les utilisateurs via la pscommande et le /procsystème de fichiers. Si la commande se termine rapidement, le risque est réduit, mais il est toujours là.
RBerteig
2
Les réponses @Pete ne sont pas censées être exclusives, elles se complètent. Il est donc normal que la deuxième réponse omet la menace expliquée dans la première, il serait plutôt superflu de la répéter. Et je n'appellerais pas la déclaration fausse parce que ce n'est pas vrai dans tous les cas.
Dmitry Grigoryev
1

Cela pourrait être fait de manière plus sûre en utilisant le paramètre --netrc-file.

  1. Créer un fichier avec l'autorisation 600

Par exemple: vi / root / my-file

machine example.com

nom d'utilisateur connexion

MOT DE PASSE

Enregistrez et fermez le fichier

  1. Utilisez ce qui suit pour accéder à l'URL avec le nom d'utilisateur et le mot de passe.

curl --netrc-file / root / my-file http://example.com

  1. Terminé
Shameer
la source
0

Il n'est pas sécurisé lors de l'utilisation du schéma HTTP. Pour le sécuriser, vous devez utiliser HTTPS.

Pour masquer le mot de passe d'apparaître dans l'historique des commandes, indiquez uniquement le nom d'utilisateur. Curl demandera le mot de passe, s'il n'est pas fourni dans la commande.

Mohnish
la source
Pas une réponse utile si HTTPS n'est pas disponible. cURL est un "client".
mckenzm
0

La réponse courte est non ... mais ...

S'il n'y a pas d'options côté serveur, vous pouvez renforcer la sécurité.

  1. S'il s'agit d'un intranet local, isolez le domaine de diffusion et n'utilisez pas le WiFi ou une radio.
  2. Comme le dit Shameer, utilisez un fichier .netrc, gardez les valeurs hors du code.
  3. Si vous pensez que la mémoire est sûre, utilisez des variables environnementales. $ PSWD.
  4. S'il s'agit d'automatisation, exécutez à partir de la crontab de root.
  5. ... dans un conteneur.
  6. ... à partir d'une machine virtuelle avec un disque chiffré.

Rien de tout cela n'est moins sûr qu'un navigateur utilisant HTTP.

mckenzm
la source