web-dev-qa-db-fra.com

Un cookie est-il plus sûr qu'un simple en-tête HTTP?

On m'a récemment dit qu'un cookie est "plus sûr" qu'un ancien en-tête HTTP classique, qui est plus sûr qu'un paramètre d'URL, en particulier lors du passage de jetons d'accès. Quel est le raisonnement derrière un cookie plus sûr qu'un en-tête HTTP?

De plus, je suis presque sûr de comprendre pourquoi un paramètre d'URL n'est pas sûr: car il est visible tout le temps et peut facilement être saisi. Est-ce exact?

httpcookies
15
mergesort

Cookies sont en-têtes HTTP. L'en-tête s'appelle Cookie:, et il contient votre cookie.

Mais les cookies sont en fait plus sûrs que les paramètres d'URL car les cookies ne sont jamais envoyés vers d'autres domaines. Les paramètres d'URL, d'autre part, se retrouveront dans le Referer: en-tête de tout site que vous visitez directement à partir de celui avec le paramètre URL.

23
tylerl

Il existe trois façons standard de transmettre des données à partir du navigateur: GET, POST et les cookies (qui sont envoyés pour les demandes GET et POST). Voici un exemple de demande envoyée à un serveur si vous avez demandé www.example.org/spec.html?secret=foo:

GET /spec.html?secret=foo HTTP/1.1
Host: www.example.org
Cookie: name=value; name2=value2
Accept: */*

Le fait de placer les informations de session dans l'URL les rend susceptibles d'être copiées par l'utilisateur du navigateur. Du point de vue de la visibilité sur le fil, cela ne fait aucune différence. C'est pour cette raison que les données sensibles sont souvent POSTed. Quelle que soit la manière dont vous faites une demande, gardez à l'esprit qu'elle devrait probablement être protégée contre CSRF .

Quant aux cookies, ils fournissent un moyen de stocker des données qui s'étendent sur toute la durée d'une session ou dans les onglets du navigateur.

8
Jeff Ferland

Si vous transmettez un jeton d'autorisation via des en-têtes http, vous devez disposer d'une logique côté client pour la transmettre au serveur chaque fois que vous faites une demande. Un skimmer peut rechercher cela dans votre code côté client et peut détourner votre session utilisateur avec le script Java.

Mais si les mêmes informations sont transmises via les cookies, il est de la responsabilité des navigateurs de transmettre le cookie chaque fois qu'une demande est effectuée (vous êtes libre d'écrire la logique côté client). Il est donc un peu difficile (mais pas impossible) d'identifier le mécanisme dans lequel le jeton est passé.

Si le cookie est configuré pour être httponly, le détournement de session devient presque impossible via JavaScript (après avoir lu, certains navigateurs transmettent ces informations à JavaScript mais le support augmente). Et les cookies ont la même politique d'origine. Mais en utilisant toujours des outils comme le violoneux, un pirate déterminé pourra accéder à ces informations.

Mais le pirate devrait pouvoir flairer le réseau pour accéder à ces informations.

Donc, en conclusion, un cookie est définitivement plus sûr.

Si vous êtes tellement préoccupé par la sécurité, optez pour des certificats SSL qui éliminent presque la menace de renifler le réseau d'une activité futile.

3
Mr.X

Les cookies font partie de la en-tête HTTP , ils ne peuvent donc pas être plus sûrs qu'eux-mêmes. Les cookies ont des indicateurs de sécurité intégrés dans leurs spécifications: HTTPOnly et Secure, ce dernier empêchant la transmission via des connexions non SSL.

Les paramètres faisant partie de l'URL sont susceptibles d'être enregistrés par les services Web que vous exécutez dans le cadre des statistiques ou autrement, les laissant ouverts à la lecture en texte brut pour toute personne pouvant y accéder.

3
Ditmar Wendt

  1. Les paramètres d'URL sont envoyés dans l'en-tête Referer à d'autres sites, c'est donc le pire moyen de transmettre des données sensibles.

  2. Le (obsolète) Cookie2 header est chiffré à l'aide d'un nonce fourni par le site dans son Set-Cookie2 en-tête de réponse. C'est donc le moins mauvais, mais n'est pas bien supporté.

  3. D'autres en-têtes de demande (y compris Cookie) se situent quelque part entre les deux.

Aucune de ces options n'est "sûre".

L'option seulement sûr est HTTPS (c'est-à-dire SSL) utilisant une autorité de certification mutuellement fiable.

2
Nicholas Shanks

Je suppose que les cookies et les en-têtes ont des points forts et des points faibles. Étant donné que certaines réponses indiquent déjà les points forts des cookies, je mentionnerai le point fort des en-têtes. Les en-têtes doivent être transmis par programme par l'application js; ils ne sont jamais transmis automatiquement par le navigateur lors de l'accès à une URL sur le domaine respectif. Cela fait en sorte que d'autres applications ou extraits js ne peuvent pas envoyer l'en-tête automatiquement, éliminant ainsi toute une gamme d'attaques dans le CSRF ou les zones de script intersite. Bien sûr, utiliser uniquement HTTPS sur TLS et désactiver la rétrogradation vers HTTP sont nécessaires dans les deux cas.

1
NicuMarasoiu