Pour le cookie SameSite avec sous-domaines, que considère-t-on comme le même site?
Pour l'attribut de cookie samesite, je ne sais pas si j'ai défini un cookie avec le domaine .example.com de sub.example.com avec l'attribut samesite, s'il sera considéré comme le même site que other.example.com.
Le comportement des cookies est différent de CORS et j'ai du mal à trouver une ressource qui clarifie définitivement cela.
Le 'Site' dans SameSite fait référence à la combinaison d'un domaine de second niveau mysite. Com et domaine de premier niveau mysite. com .
Cela signifie qu'une demande de
login.mysite.comàcdn.mysite.comserait considéré comme une demande du même site.
[~ # ~] mais [~ # ~] ... comme vous pouvez l'imaginer, cela ne s'arrête pas là. Il y a Public Suffixes List qui modifie légèrement ce comportement de validation.
Pourquoi? Eh bien, parce qu'il existe un certain nombre de sites où les utilisateurs finaux, et non le registraire ou le propriétaire du domaine, contrôlent une partie du domaine (le sous-domaine). Par exemple. my-site.azurewebsites.net.
Du point de vue de la confidentialité et de la sécurité, les cookies sont étendus à my-site.azurewebsites.net ne doit certainement pas être envoyé à your-site.azurewebsites.net. Et, étant donné qu'il n'existe aucun moyen algorithmique pour votre navigateur de déterminer si une URL particulière est de ce type, la liste des suffixes publics a été créée pour que les navigateurs changent leur comportement de validation sur le même site. Par conséquent, azurewebsites.net est répertorié dans la Public Suffixes List .
Ainsi, pour les sites de la liste des suffixes publics, une demande de
my-site.azurewebsites.netàyour-site.azurewebsites.netserait considéré comme intersite.
Permettez-moi d'expliquer la spécification .
La définition de "same-site" est:
Une demande est "même site" si le domaine enregistré de l'URI d'origine de sa cible correspond exactement au client de la demande "site pour cookies" , ou si la demande n'a pas de client. La demande est par ailleurs "intersite".
Pour une demande donnée ("demande"), l'algorithme suivant renvoie "même site" ou "intersite":
Si le client de "request" est "null", retournez "same-site".
Soit "site" le "site pour cookies" du client "demande" (tel que défini dans les sections suivantes).
Soit "target" le domaine enregistré de l'url actuelle de "request".
Si "site" correspond exactement à "cible", renvoyez "même site".
- Retour "cross-site".
Comme vous pouvez le voir, le noyau est de comparer site for cookies avec registered domain.
Commençons par registered domain .
Le "domaine enregistré" d'une origine est le suffixe public de l'hôte d'origine plus l'étiquette à sa gauche. Autrement dit, pour " https: //www.example.com ", le suffixe public est "com" et le domaine enregistré est "example.com". Ce concept est défini plus rigoureusement dans [~ # ~] psl [~ # ~] , et est également connu comme "domaine de premier niveau efficace plus un" (eTLD + 1).
[PSL] "Public Suffix List", n.d., https: //publicsuffix.org/list/ .
Cependant, comme vous pouvez le voir dans https: //publicsuffix.org/list/ , github.io est également dans la liste, ce qui signifie qu'il s'agit d'un suffixe public. Ainsi, le registered domains de https://me.github.io et https://you.github.io sont me.github.io et you.github.io tandis que le registered domains de https://me.example.com et https://you.example.com sont les deux example.com.
La raison en est que github.io est dans le https: //publicsuffix.org/list/ tandis que example.com n'est pas dans le https: //publicsuffix.org/list/ .
Continuons d'avancer. Alors, quel est le "site for cookies"?
Nous pouvons trouver que c'est définition ici
L'URI affiché dans la barre d'adresse d'un agent utilisateur est le seul contexte de sécurité directement exposé aux utilisateurs, et donc le seul signal sur lequel les utilisateurs peuvent raisonnablement se fier pour déterminer s'ils font confiance ou non à un site Web particulier. Le domaine enregistré de l'origine de cet URI représente le contexte dans lequel un utilisateur se croit le plus susceptible d'interagir. Nous appellerons ce domaine le "site de niveau supérieur" .
Pour un document affiché dans un contexte de navigation de haut niveau, on peut s'arrêter ici: le "site de cookies" du document est le site de haut niveau.
Pour les documents qui sont affichés dans des contextes de navigation imbriqués, nous devons auditer les origines de chacun des documents actifs des contextes de navigation des ancêtres d'un document afin de tenir compte des "scénarios à emboîtements multiples" décrits dans la section 4 de la [RFC7034]. Le "site de cookies" d'un document est le site de niveau supérieur si et seulement si le document et chacune des origines de ses documents ancêtres ont le même domaine enregistré que le site de niveau supérieur. Sinon, son "site pour les cookies" est la chaîne vide.
Étant donné un document ("document"), l'algorithme suivant renvoie son "site pour les cookies" (soit un domaine enregistré, soit la chaîne vide):
Soit "top-document" le document actif dans le contexte de navigation de niveau supérieur du contexte de navigation de "document".
Soit "top-Origin" l'origine de l'URI "top-document" si l'indicateur de contexte de navigation d'origine "top-document" est mis en sandbox, et l'origine "top-document" sinon.
Soit "documents" une liste contenant "document" et chacun des documents actifs des contextes de navigation par ancêtre de "document".
Pour chaque "élément" dans les "documents":
Soit "Origin" l’origine de l’URI de "item" si l’indicateur de contexte de navigation d’origine de "item" est mis en sandbox, et l’origine de "item" sinon.
Si le domaine enregistré de l'hôte "Origin" n'est pas une correspondance exacte pour le domaine enregistré de l'hôte "top-Origin", renvoyez la chaîne vide.
Renvoie le domaine enregistré de l'hôte "top-Origin".
Les définitions associées sont répertoriées ci-dessus.
Nous pouvons terminer avec un exemple.
Par exemple, une demande de https://me.github.io à https://you.github.io est cross site si l'URI affiché dans la barre d'adresse de l'agent utilisateur est https://me.github.io.
Cependant, une demande de https://me.example.com à https://you.example.com est same site si l'URI affiché dans la barre d'adresse de l'agent utilisateur est https://me.example.com.
La différence est que le registered domains de https://me.github.io et https://you.github.io sont me.github.io et you.github.io tandis que le registered domains de https://me.example.com et https://you.example.com sont les deux example.com.
Le "domaine enregistré" de l'URI cible doit être une "correspondance exacte" pour le "site de cookies" de la demande.
Vous savez ce qu'est un "domaine enregistré": le nom de domaine que vous pouvez acheter ou louer, c'est-à-dire un niveau en dessous du suffixe public .
Le "site pour les cookies" est généralement le "domaine enregistré" également - ici, de la demande. Cela est vrai lorsque le document est "dans un contexte de navigation de haut niveau", c'est-à-dire pour la plupart des sites. Uniquement pour les documents "dans des contextes de navigation imbriqués", une condition supplémentaire est que "le document et chacune des origines de ses documents ancêtres aient le même domaine enregistré que le site de niveau supérieur".
En bref: Les sous-domaines ne comptent pas. Vous devez comparer les domaines enregistrables.
Source: draft-ietf-httpbis-rfc6265bis-