Post Reply 
New: Block Third Party Cookies
Apr. 03, 2009, 10:34 PM (This post was last modified: Apr. 03, 2009 10:34 PM by lnminente.)
Post: #16
RE: New: Block Third Party Cookies
I included Location in my logs, and realized that many of the text/html 302 responses are redirecting to images. So again images for setting cookies...
Add Thank You Quote this message in a reply
Apr. 03, 2009, 11:13 PM
Post: #17
RE: New: Block Third Party Cookies
Anyone try the grc cookie forensics page? Smile!
http://www.grc.com/cookies/forensics.htm
Add Thank You Quote this message in a reply
Apr. 04, 2009, 12:02 AM
Post: #18
RE: New: Block Third Party Cookies
Good link DarthTrader!! Well, reading from that good site we have to disable third party cookies in our browsers that is what i will do. Anyway i will play a bit more with proxo Smile!
Add Thank You Quote this message in a reply
Apr. 04, 2009, 12:24 AM (This post was last modified: Apr. 04, 2009 12:32 AM by sidki3003.)
Post: #19
RE: New: Block Third Party Cookies
Very cool link!
(Although he's using images for everything but the CSS and on-page test, and apparently didn't account for content-type dependent cookie blocking.)

lnminente, i guess it is a matter of taste what we like Proxomitron to handle and what not. Wink
Add Thank You Quote this message in a reply
Apr. 04, 2009, 01:48 AM
Post: #20
RE: New: Block Third Party Cookies
That's why both of us develop our own configs, hopefully Big Teeth
Add Thank You Quote this message in a reply
Apr. 04, 2009, 03:22 PM
Post: #21
RE: New: Block Third Party Cookies
What's interesting on that testpage - after merging discussed 3rd party filter - is the leaking icon cookie. I've just learned that Firefox and IE, but not Opera, are suppressing the "Referer" header for implicit (favicon.ico in remote root dir) or explicit (via link tag) favicon requests.

So, here is a header filter which does what Graycode is suggesting (extension to MIME mapping is done elsewhere). It also blocks favicons from setting cookies, of course.

Code:
[HTTP headers]
In = TRUE
Out = FALSE
Key = "Set-Cookie: 2a Block Image Cookies     9.04.03 [sd] (d.1) (In) TEST"
URL = "^$TST(keyword=*.a_cookie.*)|$LST(AllowCookies)"
Match = "?&$IHDR(Content-Type:( ) image/)\1&$LOG(wRESP $DTM(c) : Set-Cookie Image killed: \1)"


Afterwards things look fine for me at GRC's page. Smile!

Regarding the "TROUBLE, see below" messages for 1st party cookies, in reality there is no trouble. It happens because all cookie-setting replies - except for "PAGE" and "CSS" - are images. Our current working-hypothesis is that there is no legit reason for images to set cookies.

As for the second section, "First-party persistent cookies", as long as "5.1 Session Cookies by Default" is activated, all persistent cookies have been turned into session-only.
Add Thank You Quote this message in a reply
Apr. 04, 2009, 03:48 PM
Post: #22
RE: New: Block Third Party Cookies
Custom privacy import files are possible:
http://msdn.microsoft.com/en-us/library/...S.85).aspx
Add Thank You Quote this message in a reply
Apr. 04, 2009, 04:41 PM (This post was last modified: Apr. 04, 2009 05:59 PM by Graycode.)
Post: #23
RE: New: Block Third Party Cookies
The GRC site is interesting, but misleading in a couple of areas.

1. It's assuming that if a persistent cookie got through then it must still be persistent. That's not necessarily true.

A persistent cookie is one that has a "expires=" attribute with a future date, or a "max-age=" attribute. When the proxy strips those attributes then the cookie becomes session-only and will not be stored when the browser is closed. The GRC page doesn't know that their permanent cookie attempt has been rendered non-permanent.

Original
Set-Cookie: ppag=z34lpolb2ezvv; path=/; expires=Mon, 01-Jan-2046 00:00:00 GMT
Modified
Set-Cookie: ppag=z34lpolb2ezvv; path=/


2. GRC doesn't seem to be doing the kind of third-party party cookie that HTTP headers can carry. GRC is instead using multiple domains (grc.com and grctech.com) that each set cookies that aren't automatically sent to the other. It's confusing.

Edit Note: This section improperly mis-uses the term "third party cookie" to represent a different form of cross-domain cookie settings.

Real third party cookies have a "domain=" attribute with a name that is, well, for another site. I think these are the kind of third party cookies that some (or most) modern browsers can also address.

Below is third party cookies being set by visiting "www.hotmail.com/".
Code:
HTTP/1.1 302 Found
Date: Sat, 04 Apr 2009 15:33:39 GMT
Server: Microsoft-IIS/6.0
P3P: CP="BUS CUR CONo FIN IVDo ONL OUR PHY SAMo TELo"
xxn: 18
MSNSERVER: H: BAY0-DP1-18 V: 13.3.204.225 D: 2009-02-26T04:43:10
Location: http://login.live.com/login.srf?wa=wsignin1.0&rpsnv=10&ct= ...{snip}...
Set-Cookie: KSC=; domain=.mail.live.com; expires=Thu, 01-Jan-1970 12:00:01 GMT; path=/
Set-Cookie: UIC=; domain=.mail.live.com; expires=Thu, 01-Jan-1970 12:00:01 GMT; path=/
Set-Cookie: dfoo=; domain=.mail.live.com; expires=Thu, 01-Jan-1970 12:00:01 GMT; path=/
Set-Cookie: kr=; domain=.mail.live.com; expires=Thu, 01-Jan-1970 12:00:01 GMT; path=/
Set-Cookie: afu=; domain=.mail.live.com; expires=Thu, 01-Jan-1970 12:00:01 GMT; path=/
Set-Cookie: bsc=; domain=.mail.live.com; expires=Thu, 01-Jan-1970 12:00:01 GMT; path=/
Set-Cookie: prc=; domain=.mail.live.com; expires=Thu, 01-Jan-1970 12:00:01 GMT; path=/
Set-Cookie: mt=; domain=.mail.live.com; expires=Thu, 01-Jan-1970 12:00:01 GMT; path=/
Set-Cookie: KVC=; domain=.mail.live.com; expires=Thu, 01-Jan-1970 12:00:01 GMT; path=/
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Content-Type: text/html; charset=utf-8
Content-Length: 314

Hotmail is setting cookies that would be applicable to "mail.live.com". In this example, because the "expires=" specifies a time in the past, what it's actually trying to do is delete those live.com cookies.
Add Thank You Quote this message in a reply
Apr. 04, 2009, 05:05 PM
Post: #24
RE: New: Block Third Party Cookies
As for your point 1, exactly.


(Apr. 04, 2009 04:41 PM)Graycode Wrote:  2. GRC doesn't seem to be doing the kind of third-party party cookie that HTTP headers can carry. GRC is instead using multiple domains (grc.com and grctech.com) that each set cookies that aren't automatically sent to the other. It's confusing.

Real third party cookies have a "domain=" attribute with a name that is, well, for another site. I think these are the kind of third party cookies that some (or most) modern browsers can also address.

Below is third party cookies being set by visiting "www.hotmail.com/".

If i got you right, saying a 3rd party cookie is e.g. one sent by hotmail.com, carrying a .mail.live.com domain field, that is simply a defunct cookie, and i strongly assume that no halfway recent browser would accept it, no matter what you've told it to do with 3rd party cookies (i'm certain only regarding Firefox, though).

I think GRC got it correctly. Wikipedia explains it nicely. What surprised me (besides the favicon story) is that this test page is considering cookies set by an off-domain iframe as 3rd party, too! I would expect a lot of breakage here.
Add Thank You Quote this message in a reply
Apr. 04, 2009, 05:22 PM (This post was last modified: Apr. 04, 2009 06:05 PM by Graycode.)
Post: #25
RE: New: Block Third Party Cookies
Hmmm. You're absolutely right, I've discussed an unrelated cross-domain attribute instead of what "third party cookie" really is. Thanks.
Add Thank You Quote this message in a reply
Post Reply 


Forum Jump: