Une chaîne de requête HTTPS est-elle sécurisée?

Je crée une API Web sécurisée qui utilise HTTPS; Cependant, si j’autorise les utilisateurs à le configurer (y compris l’envoi d’un mot de passe) en utilisant une chaîne de requête, cela sera-t-il également sécurisé ou devrais-je le forcer via un POST?

Oui, ça l’est. Mais utiliser GET pour des données sensibles est une mauvaise idée pour plusieurs raisons:

  • Principalement la fuite du référent HTTP (une image externe de la page cible risque de perdre le mot de passe [1])
  • Le mot de passe sera stocké dans les journaux du serveur (ce qui est évidemment mauvais)
  • Historique des caches dans les navigateurs

Par conséquent, même si Queryssortingng est sécurisé, il n’est pas recommandé de transférer des données sensibles sur la chaîne de requête.

[1] Bien que je doive noter que RFC stipule que le navigateur ne doit pas envoyer de références HTTPS vers HTTP. Mais cela ne signifie pas qu’une mauvaise barre d’outils de navigateur tiers ou une image / flash externe provenant d’un site HTTPS ne la fuit pas.

D’un sharepoint vue “sniffer le paquet réseau”, une requête GET est sûre, car le navigateur établira d’abord la connexion sécurisée, puis enverra la requête contenant les parameters GET. Mais les URL GET seront stockées dans l’historique / autocomplete du navigateur des utilisateurs, ce qui n’est pas un bon endroit pour stocker des données de mot de passe. Bien sûr, cela ne s’applique que si vous utilisez la définition “Webservice” Si vous n’y accédez que depuis votre application personnalisée, cela ne devrait pas poser de problème.

Il est donc préférable d’utiliser au moins les messages dans les boîtes de dialog de mot de passe. De plus, comme indiqué dans le lien, littlegeek a publié une URL GET plus susceptible d’être écrite dans les journaux de votre serveur.

Oui. Le texte entier d’une session HTTPS est sécurisé par SSL. Cela inclut la requête et les en-têtes. À cet égard, un POST et un GET seraient exactement les mêmes.

En ce qui concerne la sécurité de votre méthode, il n’y a pas vraiment de moyen de le dire sans une inspection appropriée.

Oui , vos chaînes de requête seront cryptées.

La raison est que les chaînes de requête font partie du protocole HTTP , qui est un protocole de couche application, tandis que la partie sécurité (SSL/TLS) provient de la couche de transport. La connexion SSL est établie en premier, puis les parameters de requête (qui appartiennent au protocole http) sont envoyés au serveur.

Lors de l’établissement d’une connexion SSL , votre client appelle les étapes suivantes dans l’ordre. Supposons que vous tentiez de vous connecter à un site nommé exemple.com et que vous souhaitiez envoyer vos informations d’identification à l’aide de parameters de requête. Votre URL complète peut ressembler à ceci:

 (eg https://example.com/login?username=alice&password=12345) 
  1. Votre client (par exemple: navigateur / application mobile) va d’abord résoudre votre nom de domaine (example.com) sur une adresse IP (124.21.12.31) aide d’une requête DNS . Lors de l’interrogation de ces informations, seules les informations spécifiques au domaine sont utilisées. ie: seul example.com sera utilisé.
  2. Maintenant, votre client essaiera de se connecter au serveur avec l’adresse IP 124.21.12.31 et tentera de se connecter au port 443 (le port du service SSL n’est pas le port http 80 par défaut).
  3. Maintenant, le serveur sur example.com enverra ses certificates à votre client.
  4. Votre client vérifiera les certificates et commencera à échanger une clé secrète partagée pour votre session.
  5. Après avoir établi avec succès une connexion sécurisée, seuls vos parameters de requête seront envoyés via la connexion sécurisée.

Par conséquent, vous n’exposez pas de données sensibles. Toutefois, l’envoi de vos informations d’identification sur une session https utilisant cette méthode n’est pas la meilleure solution. Vous devriez aller pour une approche différente.

SSL se connecte d’abord à l’hôte, de sorte que le nom d’hôte et le numéro de port sont transférés en texte clair. Lorsque l’hôte répond et que le challenge réussit, le client crypte la requête HTTP avec l’URL réelle (c’est-à-dire après la troisième barre oblique) et l’envoie au serveur.

Il existe plusieurs façons de briser cette sécurité.

Il est possible de configurer un proxy pour agir comme un “homme au milieu”. Fondamentalement, le navigateur envoie la demande de connexion au serveur réel au proxy. Si le proxy est configuré de cette façon, il se connectera via SSL au serveur réel, mais le navigateur continuera de communiquer avec le proxy. Ainsi, si un attaquant peut accéder au proxy, il peut voir toutes les données qui le traversent en texte clair.

Vos demandes seront également visibles dans l’historique du navigateur. Les utilisateurs pourraient être tentés de créer un signet sur le site. Certains utilisateurs ont des outils de synchronisation de signets installés, de sorte que le mot de passe pourrait se retrouver sur deli.ci.us ou ailleurs.

Enfin, quelqu’un a peut-être piraté votre ordinateur et installé un enregistreur de clavier ou un scraper d’écran (et beaucoup de virus de type cheval de Troie le font). Étant donné que le mot de passe est visible directement à l’écran (par opposition à “*” dans une boîte de dialog de mot de passe), il s’agit d’une autre faille de sécurité.

Conclusion: En matière de sécurité, toujours compter sur les sentiers battus. Il y a trop de choses que vous ne connaissez pas, auxquelles vous ne pensez pas et qui vont vous casser le cou.

Oui, tant que personne ne regarde par-dessus votre épaule.

Je ne suis pas d’accord avec l’énoncé concernant la fuite du référent HTTP (une image externe dans la page cible risque […] de laisser échapper le mot de passe) dans la réponse de Slough .

Le RFC HTTP 1.1 indique explicitement :

Les clients NE DEVRAIENT PAS inclure un champ d’en-tête Referer dans une requête HTTP (non sécurisée) si la page de référence a été transférée avec un protocole sécurisé.

Quoi qu’il en soit, les journaux du serveur et l’historique du navigateur sont plus que suffisants pour ne pas placer de données sensibles dans la chaîne de requête.

Oui, à partir du moment où vous établissez une connexion HTTPS, tout est sécurisé. La chaîne de requête (GET) en tant que POST est envoyée via SSL.

Vous pouvez envoyer un mot de passe en tant que paramètre de hachage MD5 avec un peu de sel ajouté. Comparez-le du côté du serveur pour l’authentification.