Cookie geblokkeerd/niet opgeslagen in IFRAME in Internet Explorer

Ik heb twee websites, laten we zeggen dat het example.comen anotherexample.netzijn.
Op anotherexample.net/page.htmlheb ik een IFRAME SRC="http://example.com/someform.asp". Dat IFRAME geeft een formulier weer dat de gebruiker moet invullen en verzenden naar http://example.com/process.asp. Als ik het formulier (“someform.asp“) in zijn eigen browservenster open, werkt alles goed.
Echter, wanneer ik someform.asplaad als een IFRAME in IE 6 of IE 7, worden de cookies bijvoorbeeld.com niet opgeslagen.In Firefox verschijnt dit probleem niet .

Voor testdoeleinden heb ik een vergelijkbare configuratie gemaakt op http://newmoon.wz. cz/test/page.php.

example.comgebruikt op cookies gebaseerde sessies (en daar kan ik niets aan doen), dus zonder cookies wordt process.aspniet uitgevoerd. Hoe dwing ik IE om die cookies op te slaan?

Resultaten van het snuiven van het HTTP-verkeer: op GET /someform.asp-reactie is er een geldige Set-Cookie-header per sessie (bijv. Set-Cookie: ASPKSJIUIUGF=JKHJUHVGFYTTYFY), maar op POST / process.asp-verzoek, er is helemaal geen Cookie-header.

Edit3: sommige AJAX+serverside-scripts zijn blijkbaar in staat om het probleem te omzeilen, maar dat lijkt erg op een bug, en het opent een hele nieuwe reeks beveiligingslekken. Ik wil niet dat mijn applicaties een combinatie van bug + beveiligingslek gebruiken, alleen omdat het gemakkelijk is.

Bewerken: het P3P-beleid was de hoofdoorzaak, volledige uitleg hieronder.


Antwoord 1, autoriteit 100%

Ik heb het werkend gekregen, maar de oplossing is een beetje ingewikkeld, dus wees geduldig.

Wat gebeurt er

Zoals het is, geeft Internet Explorer een lager vertrouwensniveau aan IFRAME-pagina’s (IE noemt dit “inhoud van derden”). Als de pagina binnen het IFRAME geen privacybeleid heeft, worden de cookies geblokkeerd (wat wordt aangegeven door het oogpictogram in de statusbalk, wanneer u erop klikt, wordt een lijst met geblokkeerde URL’s weergegeven).

het boze oog
(bron: piskvor.org)

In dit geval, wanneer cookies worden geblokkeerd, wordt de sessie-ID niet verzonden en genereert het doelscript een ‘sessie niet gevonden’-fout.

(Ik heb geprobeerd de sessie-ID in het formulier in te stellen en deze vanuit POST-variabelen te laden. Dit zou hebben gewerkt, maar om politieke redenen kon ik dat niet.)

Het is mogelijk om de pagina binnen het IFRAME meer vertrouwd te maken: als de binnenpagina een P3P-header verzendt met een privacybeleid dat acceptabel is voor IE, worden de cookies geaccepteerd.

Hoe het op te lossen

Maak een p3p-beleid

Een goed startpunt is de W3C-zelfstudie. Ik heb het doorgenomen, de IBM Privacy Policy Editorgedownload en daar heb ik een weergave gemaakt van het privacybeleid en gaf het een naam om ernaar te verwijzen (hier was het policy1).

OPMERKING: op dit moment moet u erachter komen of uw site een privacybeleid heeft, en zo niet, maak het dan – of het gebruikersgegevens verzamelt, wat voor soort gegevens, wat ermee doet, wie er toegang toe heeft, enz. U moet deze informatie vinden en er nadenkenover. Het volstaat niet om een ​​paar tags samen te voegen.Deze stap kan niet puur softwarematig worden uitgevoerd en kan zeer politiek zijn (bijvoorbeeld “Moeten we onze klikstatistieken verkopen?”).

(bijv. “de site wordt beheerd door ACME Ltd., het gebruikt anonieme per-sessie-ID’s voor zijn werking, verzamelt alleen gebruikersgegevens als dit expliciet is toegestaan ​​en alleen voor de volgende doeleinden, de gegevens worden alleen opgeslagen zolang als nodig is, alleen ons bedrijf heeft er toegang toe, enz. enz.”).

(Bij het bewerken met deze tool is het mogelijk om fouten/omissies in het beleid te bekijken. Ook erg handig is het tabblad “HTML-beleid”: onderaan staat een “Beleidsevaluatie” – een snelle controle of het beleid wordt geblokkeerd door de standaardinstellingen van IE)

De Editor exporteert naar een .p3p-bestand, dat een XML-weergave is van het bovenstaande beleid. Het kan ook een “compacte versie” van dit beleid exporteren.

Link naar het beleid

Vervolgens was een beleidsreferentiebestand (http://example.com/w3c/p3p.xml) nodig (een index van het privacybeleid dat de site gebruikt):

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

De <INCLUDE>toont alle URI’s die dit beleid zullen gebruiken (in mijn geval de hele site). Het beleidsbestand dat ik vanuit de Editor heb geëxporteerd, is geüpload naar http://example.com/w3c/example-com.p3p

Stuur de compacte koptekst met antwoorden

Ik heb de webserver op example.com ingesteld om de compacte header met antwoorden te verzenden, zoals deze:

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

policyrefis een relatieve URI ten opzichte van het beleidsreferentiebestand (dat op zijn beurt verwijst naar het privacybeleid), CPis de compacte beleidsweergave. Houd er rekening mee dat de combinatie van P3P-headers in het voorbeeld mogelijk niet van toepassing is op uw specifieke website; uw P3P-headers MOETEN uw eigen privacybeleid waarheidsgetrouw weergeven!

Winst!

In deze configuratie verschijnt het Boze Oog niet, worden de cookies zelfs in het IFRAME opgeslagen en werkt de applicatie.

Bewerken: wat je NIET moet doen, tenzij je je graag verdedigt tegen rechtszaken

Verschillende mensen hebben voorgesteld om “gewoon wat tags in je P3P-header te plakken, totdat het boze oog het opgeeft”.

De tags zijn niet alleen een aantal stukjes, ze hebben echte betekenissen, en het gebruik ervan geeft je realistische verantwoordelijkheden!

Als je bijvoorbeeld doet alsof je nooit gebruikersgegevens verzamelt, kan de browser blij zijn, maar als je daadwerkelijk gebruikersgegevens verzamelt, is de P3P in strijd met de realiteit. Duidelijk en simpel, u liegt met opzet tegen uw gebruikers, en dat kan in sommige landen crimineel gedrag zijn. Zoals in, “ga naar de gevangenis, verzamel geen $ 200”.

Een paar voorbeelden (zie p3pwriter voor de volledige set tags):

  • NOI: “Website verzamelt geen geïdentificeerde gegevens.” (zodra er enige aanpassing is, een login of een gegevensverzameling (***** Analytics, iemand?), moetdit erkennen in uw P3P)
  • STP: informatie wordt bewaard om aan het vermelde doel te voldoen. Dit vereist dat informatie zo vroeg mogelijk wordt weggegooid. Sites MOETEN een bewaarbeleid hebben dat een tijdschema voor vernietiging vaststelt. Het bewaarbeleid MOET worden opgenomen in of gekoppeld aan het voor mensen leesbare privacybeleid van de site.” (dus als u STPverzendt maar geen bewaarbeleid heeft, mag ufraude plegen. Hoe cool is dat? Helemaal niet.)

Ik ben geen advocaat, maar ik ben niet bereid om naar de rechtbank te stappen om te zien of de P3P-header echtwettelijk bindend is of dat u uw gebruikers iets kunt beloven zonder dat u ze daadwerkelijk wilt nakomen uw beloften.


Antwoord 2, autoriteit 39%

Ik heb een groot deel van mijn dag besteed aan het onderzoeken van dit P3P-ding en ik voel de behoefte om te delen wat ik heb ontdekt.

Ik heb gemerkt dat het P3P-concept erg achterhaald is en alleen echt lijkt te worden gebruikt/afgedwongen door Internet Explorer (IE).

De eenvoudigste verklaring is: IE wil dat je een P3P-header definieert als je cookies gebruikt.

Dit is een leuk idee, en gelukkig veroorzaakt het niet verstrekken van deze header meestal geen problemen (lees browserwaarschuwingen). Tenzij uw website/webtoepassing in een andere website wordt geladen met behulp van een (i)Frame. Dit is waar IE een enorme pijn in de *** wordt. U kunt geen cookie plaatsen tenzij de P3P-header is ingesteld.

Dit wetende wilde ik een antwoord vinden op de volgende twee vragen:

  1. Wie maakt het uit? Met andere woorden, kan ik worden vervolgd als ik het woord “Aardappel” in de koptekst plaats?
  2. Wat doen andere bedrijven?

Mijn bevindingen zijn:

  1. Het kan niemand iets schelen. Ik kan geen enkel document vinden dat suggereert dat deze technologie enig juridisch gewicht heeft. Tijdens mijn onderzoek heb ik geen enkel land ter wereld gevonden dat een wet heeft aangenomen die verbiedt dat je het woord “Aardappel” in de P3P-header plaatst
  2. Zowel Google als Facebook plaatsen een link in hun P3P-headerveld die verwijst naar een pagina die beschrijft waarom ze geen P3P-header hebben.

Het concept werd geboren in 2002 en het verbijstert me dat dit verouderde en wettelijk niet geïmplementeerde concept nog steeds wordt opgedrongen aan ontwikkelaars binnen IE.
Als deze header geen juridische gevolgen heeft, moet deze worden genegeerd (of genereer een waarschuwing of melding in de console). Niet afgedwongen! Ik ben nu gedwongen een regel in mijn code te plaatsen (en een header naar de klant te sturen) die helemaal niets doet.

Kortom – om IE tevreden te houden – voeg de volgende regel toe aan je PHP-code (andere talen zouden er ongeveer hetzelfde uit moeten zien)

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

Probleem opgelost, en IE is blij met deze aardappel.


Antwoord 3, autoriteit 13%

Ik was in staat om het boze oog te laten verdwijnen door simpelweg deze kleine kop toe te voegen aan de site in de IFrame (PHP-oplossing):

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

Vergeet niet om op ctrl+F5te drukken om je site opnieuw te laden, anders kan Explorer nog steeds het boze oog laten zien, ondanks het feit dat het goed werkt. Dit is waarschijnlijk de belangrijkste reden waarom ik zoveel problemen had om het werkend te krijgen.

Er was helemaal geen beleidsbestand nodig.

Bewerken:
Ik vond een leuk blogbericht waarin het probleem met cookies in IFrames wordt uitgelegd. Het heeft ook een snelle oplossing in C#-code:
Frames, ASPX-pagina’s en geweigerde cookies


Antwoord 4, autoriteit 5%

Dit is begraven in de opmerkingen van andere antwoorden, maar ik heb het bijna gemist, dus het lijkt erop dat het een eigen antwoord verdient.

Te controleren: om IE cookies van derden te laten accepteren, moet u uw bestanden aanbieden met een http-header genaamd p3p in de indeling:

CP="my compact p3p policy"

MAAR p3p is op dit moment zo goed als dood als een standaard en je kunt IE gemakkelijk laten werken zonder de tijd en juridische middelen te investeren in het creëren van een echt p3p-beleid. Dit komt omdat als uw compacte p3p-beleidsheader ongeldig is, IE het in feite als een goed beleid behandelt en cookies van derden accepteert. U kunt dus een p3p-header zoals deze gebruiken

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

Je kunt optioneel een link naar een pagina toevoegen die uitlegt waarom je geen p3p-beleid hebt, zoals Google en Facebook doen (ze verwijzen hier naar: https://support.google.com/accounts/answer/151657en hier: https://www.facebook.com/help/327993273962160/).

Ten slotte is het belangrijk op te merken dat alle bestanden die vanaf de site van derden worden aangeboden, de p3p-header moeten hebben, niet alleen de header die de cookie instelt, dus het kan zijn dat u dit niet alleen in uw PHP, asp kunt doen. net, enz. code. U kunt het waarschijnlijk beter instellen op webserverniveau (d.w.z. in IIS of Apache).


Antwoord 5, autoriteit 5%

Ik had dit probleem ook, ik dacht ik post de code die ik in mijn MVC2-project heb gebruikt. Wees voorzichtig wanneer u in de paginalevenscyclus de header toevoegt, anders krijgt u een HttpException “Server kan header niet toevoegen nadat HTTP-headers zijn verzonden.” Ik heb een aangepast ActionFilterAttribute gebruikt op de OnActionExecuting-methode (aangeroepen voordat de actie wordt uitgevoerd).

/// <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);
    }
}

Voorbeeld van gebruik:

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

Antwoord 6, autoriteit 3%

Dit is een geweldig onderwerp over dit onderwerp, maar ik ontdekte dat een belangrijk detail (dat in mijn geval essentieel was) dat hier of ergens anders niet werd gepost (mijn excuses als ik het net gemist heb) was dat de P3P regel moet worden doorgegeven in de header van ELKbestand dat wordt verzonden vanaf de server van derden, zelfs bestanden die geen cookies instellen of gebruiken, zoals Javascript-bestanden of afbeeldingen. Anders worden de cookies geblokkeerd. Ik heb hier meer over in een post: http://posheika.net/?p=110


Antwoord 7

Iedereen met dit probleem in node.js.

Voeg vervolgens deze p3p-module toe en schakel deze module in bij middleware.

npm install p3p

Ik gebruik express, dus ik voeg het toe in app.js

Eerst die module in app.js vereisen

var express = require('express');
var app = express();
var p3p = require('p3p');

gebruik het dan als middleware

app.use(p3p(p3p.recommended));

Het voegt p3p-headers toe aan het res-object. U hoeft geen extra dingen te doen.

Je krijgt meer informatie op:

https://github.com/troygoode/node-p3p


Antwoord 8

Als iemand op zoek is naar een Apache-regel; deze hebben we gebruikt.

Koptekst instellen P3P “CP=\”Bedankt IE8\””

Het maakte echt niet uit waar we de CP-waarde op zetten, als er maar een P3P-header is.


Antwoord 9

Een mogelijk ding om te doen is om het domein toe te voegen aan toegestane sites in tools -> internetopties -> privacy -> sites: somedomain.com -> toestaan ​​-> Oké.


Antwoord 10

Dit berichtgeeft commentaar op P3P en een kortere oplossing die de problemen met IE7 en IE8.


Antwoord 11

Een oplossing die ik hier nog niet heb genoemd, is het gebruik van sessieopslagvan koekjes.
Natuurlijk voldoet dit misschien niet aan ieders eisen, maar in sommige gevallen is het een gemakkelijke oplossing.


Antwoord 12

Ik was dit probleem aan het onderzoeken met betrekking tot het uitloggen via Azure Access Control Services, en ik kon nergens kop en staart aan verbinden.

Toen struikelde ik over dit bericht https://blogs.msdn.microsoft.com/ieinternals/2011/03/10/beware-cookie-sharing-in-cross-zone-scenarios/

Kortom, IE deelt geen cookies tussen zones (bijv. internet versus vertrouwde sites).

Dus als je IFrame-doel en html-pagina zich in een andere zone bevinden, helpt P3P nergens mee.


Antwoord 13

Heb een soortgelijk probleem, ben vanmorgen ook gaan onderzoeken hoe je het P3P-beleid kunt genereren, hier is mijn bericht over hoe je je eigen beleid kunt genereren en gebruiken op de website 🙂
http://everydayopenslikeaflower.blogspot. com/2009/08/how-to-create-p3p-policy-and-implement.html


Antwoord 14

Ik heb al eerder een volledig P3P-beleid geïmplementeerd, maar wilde niet opnieuw de rompslomp maken voor een nieuw project waar ik aan werkte. Ik vond deze link nuttig voor een eenvoudige oplossing voor het probleem, waarbij ik alleen een minimaal compact P3P-beleid van “CAO PSA OUR” hoefde op te geven:

http://blog.sweetxml.org/ 2007/10/minimal-p3p-compact-policy-suggestion.html

Het artikel citeert een (nu verbroken) link naar een Microsoft kb-artikel. Het beleid heeft mij geholpen!


Antwoord 15

U kunt de bestanden p3p.xml en policy.xml ook als zodanig combineren:

/home/ubuntu/sites/shared/w3c/p3p.xml

<META xmlns="http://www.w3.org/2002/01/P3Pv1">
  <POLICY-REFERENCES>
    <POLICY-REF about="#policy1">
      <INCLUDE>/</INCLUDE>
      <COOKIE-INCLUDE/>
    </POLICY-REF>
  </POLICY-REFERENCES>
  <POLICIES>
    <POLICY discuri="" name="policy1">
      <ENTITY>
        <DATA-GROUP>
          <DATA ref="#business.name"></DATA> 
          <DATA ref="#business.contact-info.online.email"></DATA> 
        </DATA-GROUP>
      </ENTITY>
      <ACCESS>
        <nonident/>
      </ACCESS>
      <!-- if the site has a dispute resolution procedure that it follows, a DISPUTES-GROUP should be included here -->
      <STATEMENT>
        <PURPOSE>
          <current/>
          <admin/>
          <develop/>
        </PURPOSE>
        <RECIPIENT>
          <ours/>
        </RECIPIENT>
        <RETENTION>
          <indefinitely/>
        </RETENTION>
        <DATA-GROUP>
          <DATA ref="#dynamic.clickstream"/>
          <DATA ref="#dynamic.http"/>
        </DATA-GROUP>
      </STATEMENT>
    </POLICY>
  </POLICIES>
</META>

Ik ontdekte dat de gemakkelijkste manier om een ​​header toe te voegen een proxy is via Apache en mod_headers als zodanig te gebruiken:

<VirtualHost *:80>
  ServerName mydomain.com
  DocumentRoot /home/ubuntu/sites/shared/w3c/
  ProxyRequests off
  ProxyPass /w3c/ !
  ProxyPass / http://127.0.0.1:8080/
  ProxyPassReverse / http://127.0.0.1:8080/
  ProxyPreserveHost on
  Header add p3p 'P3P:policyref="/w3c/p3p.xml", CP="NID DSP ALL COR"'
</VirtualHost>

Dus we proxy alle verzoeken behalve die naar /w3c/p3p.xml naar onze applicatieserver.

Je kunt het allemaal testen met de W3C-validator


Antwoord 16

Als u de eigenaar bent van het domein dat moet worden ingesloten, kunt u, voordat u de pagina oproept die het IFrame bevat, omleiden naar dat domein, dat de cookie maakt en terugleidt,
zoals hier uitgelegd: http://www.mendoweb. be/blog/internet-explorer-safari-cookie-probleem van derden/

Dit werkt voor Internet Explorer maar ook voor Safari (omdat Safari ook de cookies van derden blokkeert).


Antwoord 17

Ik weet dat het een beetje laat is om mijn bijdrage over dit onderwerp te plaatsen, maar ik heb zoveel uren verloren dat dit antwoord misschien iemand zal helpen.

Ik probeerde een cookie van een derde partij op mijn site te noemen en natuurlijk werkte het niet aan Internet Explorer 10, zelfs op een laag beveiligingsniveau … vraag me niet waarom. In de IFrame belde ik een Read_cookie.php (Echo $ _cookie) met Ajax.

En ik weet niet waarom ik niet in staat was om het P3P-beleid te zetten om het probleem op te lossen …

Tijdens mijn zoektocht zag ik iets over het krijgen van het koekje in JSON. Ik probeer het niet eens omdat ik dacht dat als de cookie niet door een iframe zal passeren, het niet meer door een array zal passeren …

Raad eens, het doet het! Dus als u JSON_CODE uw cookie hebt, decoderen dan na uw AJAX-verzoek, krijgt u het!

Misschien is er iets dat ik heb gemist en als ik dat wel deed, al mijn excuses, maar ik heb nooit iets zo dom gezien. Blokkeer cookies van derden voor beveiliging, waarom niet, maar laat het passeren als gecodeerd? Waar is de beveiliging nu?

Ik hoop dat dit bericht iemand en nogmaals zal helpen, als ik iets heb gemist en ik domme, doe me alsjeblieft!


Antwoord 18

In Rails gebruik ik dit juweeltje: https://github.com/merchii/rack-iframe
In feite stelt het een reeks afkortingen in zonder een referentiebestand: https://github.com/merchii/rack-iframe/blob/master/lib/rack/iframe.rb#L8

Het is gemakkelijk te installeren als je helemaal niet geeft om de betekenis van de p3p-dingen.


Antwoord 19

Voor iedereen die het P3P Compact-beleid probeert te laten werken met statische inhoud:

Het is alleenmogelijk als u aangepaste server-side responsheaders kunt verzenden met de statische inhoud.

Voor een meer gedetailleerde uitleg zie mijn antwoord hier: P3P-code instellen in HTML


Antwoord 20

In Rails 3.2 gebruik ik:

class ApplicationController < ActionController::Base  
  before_filter :set_p3p  
  private  
    # for IE session cookies thru iframe  
    def set_p3p  
      headers['P3P'] = 'CP="ALL DSP COR CURa ADMa DEVa OUR IND COM NAV"'  
    end  
end  

Ik heb dit van: http://dot-net-web-developer-bristol.blogspot.com/2012/04/setting-p3p-header-in-rails-session.html


Antwoord 21

Een betere oplossing zou zijn om een Ajax-aanroep binnen het iframe te doen naar de pagina die cookies zou krijgen/instellen…

Other episodes