P3p header tips

 

It is necessary to talk about p3p. It seems that when I discussed Netease's cross-origin implementation with my friends, I forgot to make it clear that the p3p header is required and the set-cookie later can be used to succeed. ForIEFor example (under the default security level ),IFRAME, IMG, link, and other labelsBoth send session cookies (also called the First-party cookies) and intercept local cookies (also called third-party cookies ). When these tags reference a page across domains, a GET request is actually initiated. IfCross-origin requests, The HTTP response header containsSet-CookieThe cookie is actually invalid for the browser. See the following test Assume that there are two domains: www.a.com and www. B .com. There is a page on www. B .com that contains an iframe pointing to www.a.com Http ://Www. B .com/test.htmlThe content is: ---------------------------------------------------------------------- <IFRAME width = 300 Height = 300 src = "http ://Www.a.com/test.php"> </Iframe> ---------------------------------------------------------------------- A http://www.a.com/test.php is a page for setting cookies for a.com domains with the following content: ---------------------------------------------------------------------- <? PHP Header ("Set-COOKIE: test = Axis; domain = .a.com; Path =/"); ?> <SCRIPT> Alert (document. Cookie ); </SCRIPT> ---------------------------------------------------------------------- At this point we request the http://www. B .com/test.html, which contains an IFRAME, will go to the Cross-origin request www.a.com/test.php, the PHP page will try set-cookie For the first request, test. php will set-Cookie, so the browser will receive a cookie. If the set-Cookie succeeds and the page is requested again, the browser shouldSentThe cookie returned by recieve. However, due to the cross-origin restrictions mentioned above, the IFRAME tag in IE is set-Cookie and fails, so the cookie that the sent just received cannot be obtained. Both session cookie and local cookie are the same. We can see that the second packet sending failed to send the cookie to sent. HoweverP3p HeaderWill change. The p3p header allows cross-origin access to private data, so that the cross-origin set-cookie is successful. We modify www.a.com/test.php ---------------------------------------------------------------------- <? PHP Header ("P3p: Cp = Cura ADMA Deva psao psdo our bus uni pur int DEM sta pre com nav OTC Noi DSP cor "); Header ("Set-Cookie: Test = Axis; expires = sun, 23-dec-2018 08:13:02 GMT; domain = .a.com; Path = /"); ?> <SCRIPT> Alert (document. Cookie ); </SCRIPT> ---------------------------------------------------------------------- Visit the above test process twice again You can see that the second packet has sent the cookie that you received. The javascript we wrote can also bring up cookies. It is worth noting that,You only need to set the p3p header once.In this way, all set-Cookies following this p3p header can be accessed across domains. That is to say: After being set once by the p3p header, the subsequent requests no longer require the p3p header and can also send these cookies across domains in the IFRAME. However, if you use set-cookie to change the configured cookie, this cross-origin access feature is no longer available. Another feature of the p3p header isSame bagYou can set only once, and the following p3p header does not overwrite the previous p3p header. the browser only recognizes the first header. P3p isThe platform for privacy preferencesAbbreviation For more information, seeW3CStandards Http://www.w3.org/TR/P3P/ Here, we can see things in the messy p3p header, and we don't know what a mess of policy content is. In fact, this is some shorthand For example P3p: Cp = Cura ADMA Deva psao psdo our bus uni pur int DEM sta pre com nav OTC Noi DSP Cor CP is short for Compact Policy In Cura, cur is short for <Current/> and A is short for always. There are many definitions. Here I will extract some content in the standard. [57] compact-purpose = "CUR" | ; for <current/>"ADM" [creq] | ; for <admin/>"DEV" [creq] | ; for <develop/>"TAI" [creq] | ; for <tailoring/>"PSA" [creq] | ; for <pseudo-analysis/>"PSD" [creq] | ; for <pseudo-decision/>"IVA" [creq] | ; for <individual-analysis/>"IVD" [creq] | ; for <individual-decision/>"CON" [creq] | ; for <contact/>"HIS" [creq] | ; for [58] creq = "a"| ;"always""i"| ;"opt-in""o" ;"opt-out" For more information, refer to the standards mentioned above. Of course, the p3p header can also directly reference an XML policy file. For example HTTP/1.1 200 OKP3P: policyref="http://catalog.example.com/P3P/PolicyReferences.xml"Content-Type: text/htmlContent-Length: 7413Server: CC-Galaxy/1.3.18 There are many other methods to use p3p, which are not listed here. Finally, the p3p header feature can be used in actual attacks. For exampleCRLFAfter an p3p header is inserted, the value of a local cookie is changed. The cookie can be referenced by IFRAME in the subsequent process, and some wonderful things may happen. I don't know what it will become. After all, the relationship between Web Application Security and the environment is getting closer and closer.