Nom d'utilisateur et mot de passe dans l'URL https
Considérez l'URL: https: // foo: [email protected]
Est-ce que la portion nom d'utilisateur/mot de passe dans l'exemple ci-dessus est considérée comme un "paramètre d'URL", tel que défini dans cette question ?
Lorsque vous placez le nom d'utilisateur et le mot de passe devant l'hôte, ces données ne sont pas envoyées de cette manière au serveur. Au lieu de cela, il est transformé en un en-tête de demande en fonction du schéma d'authentification utilisé. La plupart du temps, cela va être Autorisation de base que je décris ci-dessous. Un schéma d'authentification similaire (mais nettement moins utilisé) est Digest Auth , qui fournit aujourd'hui des fonctionnalités de sécurité comparables.
Avec Basic Auth, la requête HTTP de la question ressemblera à ceci:
GET / HTTP/1.1
Host: example.com
Authorization: Basic Zm9vOnBhc3N3b3Jk
Le hachage ressemblant à la chaîne que vous voyez là-bas est créé par le navigateur comme suit: base64_encode(username + ":" + password).
Pour les personnes extérieures au transfert HTTPS, ces informations sont masquées (comme tout le reste au niveau HTTP). Vous devez cependant vous occuper de la connexion sur le client et sur tous les serveurs intermédiaires. Le nom d'utilisateur sera normalement affiché dans les journaux du serveur, mais pas le mot de passe. Ce n'est pas garanti cependant. Lorsque vous appelez cette URL sur le client avec par exemple curl, le nom d'utilisateur et le mot de passe seront clairement visibles dans la liste des processus et pourraient apparaître dans le fichier d'historique de bash.
Lorsque vous utilisez l'approche par ayush , le nom d'utilisateur et le mot de passe s'afficheront toujours dans les journaux de serveur de votre serveur Web, serveur d'applications , caches, ... sauf si vous configurez spécifiquement vos serveurs pour ne pas le consigner. Cela ne concerne que les serveurs capables de lire les données http non chiffrées, comme votre serveur d'applications.
L'authentification de base est normalisée et implémentée par les navigateurs en affichant ce petit popup de nom d'utilisateur/mot de passe. Lorsque vous insérez le nom d'utilisateur/mot de passe dans un formulaire HTML envoyé via GET ou POST, vous devez implémenter vous-même toute la logique de connexion/déconnexion (ce qui peut constituer un avantage). Mais vous devriez jamais transférer les noms d'utilisateur et les mots de passe par les paramètres GET. Si vous devez le faire, utilisez POST à la place. Cela empêche la journalisation de ces données par défaut.
Lorsque vous implémentez un mécanisme d’authentification avec un formulaire de saisie utilisateur/mot de passe et une session ultérieure basée sur un cookie, tel qu’il est couramment utilisé de nos jours, vous devez vous assurer que le mot de passe est transporté avec POST requêtes ou l'un des schémas d'authentification normalisés ci-dessus uniquement.
En conclusion, je pourrais dire que le transfert de données de cette manière via HTTPS est sécurisé, tant que vous veillez à ce que le mot de passe ne soit pas affiché à des endroits inattendus. Mais ce conseil s'applique à tout transfert de mot de passe de quelque manière que ce soit.