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

du point de vue" renifler 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 paramètres GET. Mais obtenir des URLs sera stocké dans l'historique de navigateur d'utilisateurs / autocomplete, qui n'est pas un bon endroit pour stocker par exemple des données de mot de passe dans. Bien sûr, cela ne s'applique que si vous prenez la définition plus large de "Webservice" qui pourrait accéder au service à partir d'un navigateur, si vous y accédez seulement à partir de votre application cela ne devrait pas poser de problème.

il est donc préférable d'Utiliser post au moins pour les dialogues de mot de passe. En outre, comme indiqué dans le lien littlegeek posté une URL GET est plus susceptible d'être écrit à vos journaux de serveur.

Oui. Le texte complet d'une session HTTPS est sécurisé par SSL. Qui inclut la requête et les en-têtes. A cet égard, un poste et une GET seraient exactement les mêmes.

en ce qui concerne la sécurité de votre méthode, il n'y a pas de vrai moyen de dire sans une inspection appropriée.

Oui , votre requête chaînes cryptées.

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

lors de l'établissement d'une connexion SSL , votre client suivra les étapes suivantes dans l'ordre. Supposons que vous essayez de vous connecter à un site nommé example.com et que vous souhaitez envoyer vos informations d'identification en utilisant des paramètres de requête. Votre URL complet peut ressembler à ce qui suit.

(e.g https://example.com/login?username=alice&password=12345) 

1. votre client (E. g: navigateur / application mobile) résoudra d'abord votre nom de domaine (example.com) en IP adresse (124.21.12.31) utilisation d'une requête DNS . En interrogeant ces informations, seules les informations spécifiques au domaine sont utilisées. ie: seul example.com sera utilisé.
2. maintenant, votre client va essayer de se connecter au serveur avec le IP adresse 124.21.12.31 et tentera de se connecter au port 443 ( SSL port de service pas le défaut http port 80 ).
3. Maintenant, le serveur à example.com enverra ses certificats à votre client.
4. votre client vérifiera les certificats 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 les paramètres de votre requête seront envoyés via la connexion sécurisée.

par conséquent, vous n'exposerez pas les données sensibles. Cependant, envoyer vos justificatifs d'identité sur une session https en 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 de l'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 actuelle (c'est-à-dire tout ce qui suit la troisième barre oblique) et l'envoie au serveur.

il y a plusieurs façons de briser cette sécurité.

Il est possible de configurer un proxy pour agir comme un "homme du milieu". Fondamentalement, le navigateur envoie le requête pour se connecter 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 parlera quand même au proxy. Donc, si un attaquant peut accéder de l'extérieur, il peut voir toutes les données qui le traverse en texte clair.

vos requêtes seront également visibles dans l'historique du navigateur. Les utilisateurs pourraient être tentés de marquer le site d'un signet. Certains utilisateurs ont signet outils de synchronisation installé, de sorte que le mot de la fin sur deli.ci.nous ou un autre endroit.

enfin, quelqu'un a peut-être piraté votre ordinateur et installé un logger à clavier ou un scraper (et beaucoup de virus du type Cheval de Troie le font). Puisque le mot de passe est visible directement sur l'écran (par opposition à "*" dans une boîte de dialogue de mots de passe), il s'agit d'un autre trou de sécurité.

Conclusion: quand il s'agit de sécurité, toujours compter sur les sentiers battus. Il ya juste trop que vous ne savez pas, ne pensera pas et qui va casser le cou.

Oui, tant que personne ne regarde par-dessus votre épaule à l'écran.

je ne suis pas d'accord avec la déclaration suivante au sujet de [...] Fuite de la référence HTTP (une image externe dans la page cible pourrait laisser échapper le mot de passe) dans réponse de Slough .

Le HTTP 1.1 RFC indique explicitement :

les Clients ne devraient pas inclure un référent champ d'en-tête dans un HTTP (non sécurisé) demande si la page a été transféré sécurisé protocole.

quoi qu'il en soit, les journaux du serveur et l'historique du navigateur sont des raisons plus que suffisantes pour ne pas mettre 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) comme le POST est envoyé sur SSL.

vous pouvez envoyer mot de passe comme MD5 hash param avec un peu de sel ajouté. Comparer sur le côté serveur pour auth.