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

Question

Je crée une API Web sécurisée qui utilise HTTPS; cependant, si j'autorise les utilisateurs à le configurer (y compris l'envoi du mot de passe) en utilisant une chaîne de requête, est-ce que cela sera également sécurisé ou devrais-je le forcer à passer par un POST?

Answer 1

Oui, il est. Mais l'aide pour OBTENIR des données sensibles est une mauvaise idée pour plusieurs raisons:

• Surtout HTTP référent de fuite (une image externe dans la page cible pourrait fuir le mot de passe[1])
• Mot de passe sera stocké dans les journaux du serveur (ce qui est évidemment mauvais)
• L'histoire des caches des navigateurs

Par conséquent, même si la chaîne de recherche est sécurisé, il n'est pas recommandé pour le transfert de données sensibles sur la chaîne de recherche.

[1] Bien que j'ai besoin de noter que la RFC états que le navigateur ne devrait pas envoyer des référents de HTTPS en HTTP. Mais cela ne signifie pas une mauvaise 3ème partie de la barre d'outils du navigateur ou d'une image externe/flash à partir d'un site en HTTPS ne fuit pas.

Answer 2

À partir d'un "sniffer le réseau de paquets" point de vue d'une requête GET est sûr, comme le navigateur va d'abord établir la connexion sécurisée, puis envoyer la requête contenant les paramètres GET. Mais OBTENIR les url seront stockés dans le navigateur d'utilisateurs de l'histoire / la saisie semi-automatique, ce qui n'est pas un bon endroit pour stocker par exemple, données de mot de passe. Bien sûr, cela s'applique seulement si vous prenez le large "Webservice" définition de qui peut accéder au service à partir d'un navigateur, si vous y accéder uniquement à partir de votre application personnalisée, cela ne devrait pas être un problème.

Donc, à l'aide de post, au moins pour les dialogues de mot de passe qui doit être privilégiée. Aussi comme l'a souligné le lien littlegeek posté un GET de l'URL est plus susceptible d'être écrite à votre serveur de logs.

Answer 3

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.

Quant à la sécurité de votre méthode, il n'y a pas de véritable moyen de le dire sans une inspection appropriée.

Answer 4

SSL de la première connexion à l'hôte, de sorte que le nom d'hôte et le numéro de port sont transférées sous la forme de texte en clair. Lorsque l'hôte répond et le défi réussit, le client va chiffrer la requête HTTP avec l'URL réelle (c'est à dire quoi que ce soit après la troisième barre oblique) et de l'envoyer au serveur.

Il y a plusieurs façons de déjouer cette sécurité.

Il est possible de configurer un proxy pour agir comme un "homme du milieu". Fondamentalement, le navigateur envoie la demande de connexion au serveur réel pour le proxy. Si le proxy est configuré de cette façon, il va se connecter via le protocole SSL pour le serveur réel, mais le navigateur va encore en parler pour le 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.

Votre demande sera également visible dans l'historique du navigateur. Les utilisateurs pourraient être tentés de mettre en signet le site. Certains utilisateurs ont signet outils de synchronisation installé, de sorte que le mot de passe pourrait finir dans la charcuterie.ci.nous ou un autre endroit.

Enfin, quelqu'un pourrait avoir piraté votre ordinateur et d'y installer un enregistreur de clavier ou d'un écran de racloir (et beaucoup de Chevaux de Troie, virus). Puisque le mot de passe est visible directement sur l'écran (par opposition à "*" dans un dialogue de mot de passe), c'est un autre trou de sécurité.

Conclusion: Quand il s'agit de la sécurité, de toujours compter sur les sentiers battus. Il n'y a tout simplement trop de choses que vous ne savez pas, ne pense pas et qui va casser le cou.

Answer 5

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