Cookie bloqué/non enregistré dans IFRAME dans Internet Explorer

Question

J'ai deux sites web, disons qu'ils sont example.com et anotherexample.net . Sur anotherexample.net/page.html J'ai un IFRAME SRC="http://example.com/someform.asp" . Cet IFRAME affiche un formulaire que l'utilisateur doit remplir et soumettre à la Commission européenne. http://example.com/process.asp . Lorsque j'ouvre le formulaire (" someform.asp ") dans sa propre fenêtre de navigateur, tout fonctionne bien. Cependant, quand je charge someform.asp en tant que IFRAME dans IE 6 ou IE 7, les cookies pour example.com ne sont pas enregistrés. Dans Firefox, ce problème n'apparaît pas.

A des fins de test, j'ai créé une configuration similaire sur http://newmoon.wz.cz/test/page.php .

example.com utilise des sessions basées sur les cookies (et il n'y a rien que je puisse faire à ce sujet), donc sans cookies, process.asp ne s'exécutera pas. Comment puis-je forcer IE à sauvegarder ces cookies ?

Résultats du reniflage du trafic HTTP : sur la réponse GET /someform.asp, il y a un en-tête Set-Cookie valide pour chaque session (par ex. Set-Cookie: ASPKSJIUIUGF=JKHJUHVGFYTTYFY ), mais sur la requête POST /process.asp, il n'y a pas du tout d'en-tête Cookie.

Edit3 : certains AJAX+serverside scripting sont apparemment capables de contourner le problème, mais cela ressemble beaucoup à un bug, et cela ouvre une toute nouvelle série de problèmes. failles de sécurité . Je ne veux pas que mes applications utilisent une combinaison de bug+trou de sécurité juste parce que c'est facile.

Edit : le La politique P3P était la cause première L'explication complète se trouve ci-dessous.

Answer 1

J'ai réussi à le faire fonctionner, mais la solution est un peu complexe, alors soyez indulgent avec moi.

Ce qui se passe

En l'état actuel des choses, Internet Explorer accorde un niveau de confiance inférieur aux pages IFRAME (IE appelle ce contenu "tiers"). Si la page à l'intérieur de l'IFRAME n'a pas de politique de confidentialité, ses cookies sont bloqués (ce qui est indiqué par l'icône de l'œil dans la barre d'état, lorsque vous cliquez dessus, il vous montre une liste d'URL bloquées).

_{(source : <a href="http://stuff.piskvor.org/cookies_blocked_MSIE_eye.png" rel="noreferrer">piskvor.org </a>)}

Dans ce cas, lorsque les cookies sont bloqués, l'identifiant de session n'est pas envoyé, et le script cible lance une erreur 'session non trouvée'.

(J'ai essayé de définir l'identifiant de session dans le formulaire et de le charger à partir des variables POST. Cela aurait fonctionné mais pour des raisons politiques, je n'ai pas pu le faire).

Il est possible de rendre la page à l'intérieur du IFRAME plus fiable : si la page intérieure envoie un en-tête P3P avec une politique de confidentialité qui est acceptable pour IE, les cookies seront acceptés. .

Comment le résoudre

Créer une politique p3p

Un bon point de départ est le Tutoriel W3C . Je l'ai parcouru, j'ai téléchargé les Rédacteur de la politique de confidentialité d'IBM et là, j'ai créé une représentation de la politique de confidentialité et lui ai donné un nom pour la référencer (ici, c'était policy1 ).

NOTE La politique de confidentialité : à ce stade, vous devez déterminer si votre site dispose d'une politique de confidentialité et, si ce n'est pas le cas, en créer une - si elle collecte des données sur les utilisateurs, quel type de données, ce qu'elle en fait, qui y a accès, etc. Vous devez trouver ces informations et pensez à à ce sujet. Il ne suffit pas de coller quelques étiquettes. Cette étape ne peut pas être réalisée uniquement par logiciel et peut être hautement politique (par exemple, "devons-nous vendre nos statistiques de clics ?").

(par exemple : "le site est exploité par ACME Ltd, il utilise des identifiants anonymes par session pour son fonctionnement, ne collecte les données des utilisateurs que si cela est explicitement autorisé et uniquement aux fins suivantes, les données ne sont conservées que le temps nécessaire, seule notre société y a accès, etc. etc.)

(Lors de l'édition avec cet outil, il est possible de visualiser les erreurs/omissions dans la politique. L'onglet "Politique HTML" est également très utile : en bas, il y a une "évaluation de la politique" - une vérification rapide si la politique sera bloquée par les paramètres par défaut d'IE).

L'éditeur exporte vers un fichier .p3p, qui est une représentation XML de la politique ci-dessus. Il peut également exporter une "version compacte" de cette politique.

Lien vers la politique

Ensuite, un fichier de référence de politique ( http://example.com/w3c/p3p.xml ) était nécessaire (un index des politiques de confidentialité utilisées par le site) :

<META>
  <POLICY-REFERENCES>
    <POLICY-REF about="/w3c/example-com.p3p#policy1">
      <INCLUDE>/</INCLUDE>
      <COOKIE-INCLUDE/>
    </POLICY-REF>
  </POLICY-REFERENCES>
</META>

Le site <INCLUDE> montre tous les URIs qui utiliseront cette politique (dans mon cas, le site entier). Le fichier de stratégie que j'ai exporté de l'éditeur a été téléchargé dans le répertoire http://example.com/w3c/example-com.p3p

Envoyer l'en-tête compact avec les réponses

J'ai configuré le serveur Web de example.com pour qu'il envoie l'en-tête compact avec les réponses, comme ceci :

HTTP/1.1 200 OK 
P3P: policyref="/w3c/p3p.xml", CP="IDC DSP COR IVAi IVDi OUR TST"
// ... other headers and content

policyref est un URI relatif au fichier de référence de la politique (qui à son tour référence les politiques de confidentialité), CP est la représentation compacte de la politique. Notez que la combinaison des en-têtes P3P dans l'exemple peut ne pas être applicable à votre site web spécifique ; vos en-têtes P3P DOIVENT représenter fidèlement votre propre politique de confidentialité !

Profit !

Dans cette configuration, le mauvais œil n'apparaît pas, les cookies sont sauvegardés même dans l'IFRAME, et l'application fonctionne.

Edit : Ce qu'il ne faut PAS faire, sauf si vous aimez vous défendre contre les poursuites judiciaires

Plusieurs personnes ont suggéré de "coller quelques balises dans votre en-tête P3P, jusqu'à ce que le mauvais œil abandonne".

Les étiquettes ne sont pas seulement un tas de bits, elles ont les significations du monde réel et leur utilisation vous donne responsabilités dans le monde réel !

Par exemple, prétendre que vous ne collectez jamais de données sur les utilisateurs peut rendre le navigateur heureux, mais si vous collectez réellement des données sur les utilisateurs, le P3P est en conflit avec la réalité. C'est aussi simple que cela, vous mentez délibérément à vos utilisateurs et cela pourrait être un comportement criminel dans certains pays. Comme dans "allez en prison, ne touchez pas 200 dollars".

Quelques exemples ( voir p3pwriter pour le jeu complet de balises ) :

• NOI : "Le site Web ne collecte pas de données identifiées." (dès qu'il y a une personnalisation, un login, ou une collecte de données (***** Analytics, anyone ?), vous doit le reconnaître dans votre P3P)
• STP : L'information est conservée pour répondre à l'objectif fixé. Cela signifie que les informations doivent être éliminées le plus tôt possible. Les sites DOIVENT avoir une politique de conservation qui établit un calendrier de destruction. La politique de conservation DOIT être incluse dans la politique de confidentialité lisible par l'homme du site ou être liée à celle-ci." (donc si vous envoyez STP mais n'ont pas de politique de rétention, vous mai commettre une fraude. C'est pas cool ça ? Pas du tout.)

Je ne suis pas un avocat, mais je ne suis pas prêt à aller au tribunal pour voir si l'en-tête P3P est vraiment légalement contraignant ou si vous pouvez promettre n'importe quoi à vos utilisateurs sans vouloir réellement honorer vos promesses.

Answer 2

J'ai passé une grande partie de ma journée à me pencher sur cette histoire de P3P et je ressens le besoin de partager ce que j'ai découvert.

J'ai remarqué que le concept P3P est très dépassé et ne semble être réellement utilisé/renforcé que par Internet Explorer (IE).

L'explication la plus simple est la suivante : IE veut que vous définissiez un en-tête P3P si vous utilisez des cookies.

C'est une bonne idée et, heureusement, la plupart du temps, le fait de ne pas fournir cet en-tête ne pose aucun problème (voir les avertissements des navigateurs). Sauf si votre site/application Web est chargé dans un autre site Web à l'aide d'un (i)Frame. C'est là qu'IE devient un véritable casse-tête. Il ne vous permettra pas de définir un cookie si l'en-tête P3P n'est pas défini.

Sachant cela, j'ai voulu trouver une réponse aux deux questions suivantes :

1. Qui s'en soucie ? En d'autres termes, puis-je être poursuivi en justice si je mets le mot "pomme de terre" dans l'en-tête ?
2. Que font les autres entreprises ?

Mes conclusions sont les suivantes :

1. Tout le monde s'en fiche. Je suis incapable de trouver un seul document qui suggère que cette technologie a un quelconque poids juridique. Au cours de mes recherches, je n'ai pas trouvé un seul pays dans le monde qui ait adopté une loi vous empêchant de mettre le mot "Potato" dans l'en-tête P3P.
2. Google et Facebook ont tous deux placé un lien dans leur champ d'en-tête P3P renvoyant à une page décrivant pourquoi ils n'ont pas d'en-tête P3P.

Ce concept est né en 2002 et je ne comprends pas que ce concept dépassé et juridiquement non appliqué soit encore imposé aux développeurs dans IE. Si cet en-tête n'a pas de ramifications légales, il devrait être ignoré (ou bien générer un avertissement ou une notification dans la console). Non appliqué ! Je suis maintenant obligé de mettre une ligne dans mon code (et d'envoyer un en-tête au client) qui ne fait absolument rien.

En bref, pour que IE soit satisfait, ajoutez la ligne suivante à votre code PHP (les autres langages devraient être similaires)

header('P3P: CP="Potato"');

Problème résolu, et IE est heureux avec cette pomme de terre.

Answer 3

J'ai pu faire disparaître le mauvais œil en ajoutant simplement ce petit en-tête au site dans l'IFrame (solution PHP) :

header('P3P: CP="NOI ADM DEV COM NAV OUR STP"');

N'oubliez pas d'appuyer sur ctrl+F5 pour recharger votre site ou Explorer peut encore montrer le mauvais œil, malgré le fait qu'il fonctionne bien. C'est probablement la raison principale pour laquelle j'ai eu tant de problèmes pour le faire fonctionner.

Aucun fichier de politique n'a été nécessaire.

Modifier : J'ai trouvé un article de blog sympa qui explique le problème des cookies dans les IFrames. Il propose également une solution rapide en code C# : Frames, pages ASPX et cookies rejetés

Answer 4

Cette question est enfouie dans les commentaires d'autres réponses, mais j'ai failli la manquer, alors il me semble qu'elle mérite sa propre réponse.

Récapitulons : pour qu'IE accepte les cookies tiers, vous devez servir vos fichiers avec un en-tête http appelé p3p au format :

CP="my compact p3p policy"

MAIS, p3p est à peu près mort en tant que norme à ce stade et vous pouvez facilement faire fonctionner IE sans investir le temps et les ressources juridiques nécessaires pour créer une véritable politique p3p. En effet, si votre en-tête de politique p3p compacte n'est pas valide, IE le traite comme une bonne politique et accepte les cookies tiers. Vous pouvez donc utiliser un en-tête p3p tel que celui-ci

CP="This site does not have a p3p policy."

Vous pouvez éventuellement inclure un lien vers une page qui explique pourquoi vous n'avez pas de politique p3p, comme le font Google et Facebook (ils indiquent ici : https://support.google.com/accounts/answer/151657 et ici : https://www.facebook.com/help/327993273962160/ ).

Enfin, il est important de noter que tous les fichiers servis à partir du site tiers doivent avoir l'en-tête p3p, pas seulement celui qui définit le cookie, donc vous ne pouvez pas simplement faire cela dans votre code PHP, asp.net, etc. Il est probablement préférable de le faire au niveau du serveur web (c'est-à-dire dans IIS ou Apache).

Answer 5

J'ai eu ce problème également, j'ai pensé poster le code que j'ai utilisé dans mon projet MVC2. Faites attention lorsque vous ajoutez l'en-tête dans le cycle de vie de la page ou vous obtiendrez une HttpException " Le serveur ne peut pas ajouter d'en-tête après l'envoi des en-têtes HTTP. ." J'ai utilisé un ActionFilterAttribute personnalisé sur la méthode OnActionExecuting (appelée avant l'exécution de l'action).

/// <summary>
/// Privacy Preferences Project (P3P) serve a compact policy (a "p3p" HTTP header) for all requests
/// P3P provides a standard way for Web sites to communicate about their practices around the collection, 
/// use, and distribution of personal information. It's a machine-readable privacy policy that can be 
/// automatically fetched and viewed by users, and it can be tailored to fit your company's specific policies.
/// </summary>
/// <remarks>
/// More info http://www.oreillynet.com/lpt/a/1554
/// </remarks>
public class P3PAttribute : ActionFilterAttribute
{
    /// <summary>
    /// On Action Executing add a compact policy "p3p" HTTP header
    /// </summary>
    /// <param name="filterContext"></param>
    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        HttpContext.Current.Response.AddHeader("p3p","CP=\"IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\"");

        base.OnActionExecuting(filterContext);
    }
}

Exemple d'utilisation :

[P3P]
public class HomeController : Controller
{
    public ActionResult Index()
    {
        ViewData["Message"] = "Welcome!";

        return View();
    }

    public ActionResult About()
    {
        return View();
    }
}