Can browsers react to Set-Cookie specified in headers in an XSS jquery.getJSON() request?
Asked Answered
A

2

0

(Note: This is a follow up to my question Can jQuery.getJSON put a domain's cookies in the header of the request it makes? and covers the XSS case of Setting a cookie in an AJAX request?)

I've been told I'm unable to set cookies to be read by other domains that are not subdomains of the current domain using $.cookie(..., ..., {domain: ...}). But in a comment on a response to my last question, @zanlok said "The server's reply, however, can definitely set a cookie" and it got two upvotes.

So I thought I'd try using a service which was created for the explicit purpose of setting cookies called Freebase's "touch" API. The call looks like:

$.getJSON("http://api.sandbox-freebase.com/api/service/touch",
{}, // URL parameters
afterCookieIsSetCallback); // Callback function

Looking in FireBug at the response header it's like this:

Date    Wed, 24 Nov 2010 03:35:28 GMT
Server  Apache
X-Metaweb-Cost  [...]
Etag    [...]
Expires Wed, 24 Nov 2010 03:35:29 GMT
Cache-Control   no-store
Vary    Accept-Encoding
Content-Encoding    gzip
Set-Cookie  mwLastWriteTime=1290569730|10325_9202a8c04000641f80000000199eff96|sandbox; expires=Thu, 25-Nov-2010 03:35:28 GMT; Path=/
Last-Modified   Wed, 24 Nov 2010 03:35:28 GMT
Content-Length  134
Content-Type    text/plain; charset=utf-8
X-Cache MISS from cache01.sandbox.sjc1.metaweb.com
Connection  keep-alive
X-Metaweb-TID   cache;cache01.sandbox.sjc1:8101;2010-11-24T03:35:28Z;0001

So there's definitely a Set-Cookie in there, and the script runs the response handler. Yet the cookie is not present in the request headers for later JSON requests this script makes to .sandbox-freebase.com.

(By contrast, simply typing the touch api URL into the address bar and loading it that way does set the cookie for future requests. That applies even in other tabs.)

This seems to be a deviation from a prior "expected behavior", because there was a toolkit published by MetaWeb circa "2007-2009" which seemed to think such an approach could work:

http://www.google.com/codesearch/p?hl=en#v099O4eZ5cA/trunk/src/freebase/api.js&q=touch%20package:http://mjt%5C.googlecode%5C.com&l=340

Without knowing much about it, I'm wondering if it was a recent change that Firefox adopted and then WebKit followed suit. Perhaps the one mentioned here:

http://trac.webkit.org/browser/trunk/WebCore/xml/XMLHttpRequest.cpp#L856

So is there any canonical documentation on this particular issue?

Ann answered 24/11, 2010 at 4:14 Comment(0)
F
4

The AJAX call you are making, is making a request to a domain outside of the domain of the top level url(the url in the address bar). This results in it being a 3rd party cookie, by default Internet explorer won't persist a 3rd party cookie. Meaning that the cookie will come back in the Set-Cookie header on the first request, but subsequent requests that you make to that server will not have that cookie sent in the request.

Like you said, if you go directly to the url in your browser it works. This is because in this case it's a first party cookie.

In order for IE to accept 3rd party cookie's the server that is sending the SET-COOKIE header on it's response, must also have a P3P Policy Header set.

Here is an example, when you navigate to CNN, you will notice one of the requests it makes is to a domain name of b.scorecardresearch.com, scorecardresearch is dropping a tracking cookie, but this cookie is considered a 3rd party cookie. So in order to make it work they had to also in include a p3p header, see headers below:

HTTP/1.1 200 OK
Content-Length: 43
Content-Type: image/gif
Date: Thu, 02 Dec 2010 19:57:16 GMT
Connection: keep-alive
Set-Cookie: UID=133a68a4-63.217.184.91-1288107038; expires=Sat, 01-Dec-2012 19:57:16 GMT; path=/; domain=.scorecardresearch.com
P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR NID OUR IND COM STA OTC"
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Pragma: no-cache
Cache-Control: private, no-cache, no-cache=Set-Cookie, no-store, proxy-revalidate
Server: CS

If you were to copy this header and add it to the response, you would notice that the cookie's start working,

P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR NID OUR IND COM STA OTC"

It's best that you craft a P3P header specific for your business, but the above should work for testing purposes.

Fichte answered 2/12, 2010 at 20:2 Comment(1)
Thanks for the P3P header example and terminology ("third party cookie" and "first party cookie"), that opens up some searches. It still seems like none of it's been formalized very well. Some APIs like Freebase's "touch" seem to be from an era before these rules became standard. You can still do whatever you want in non-browser scenarios (like server-side code making Ajax requests) that makes it being a cookie just an inconvenience. In any case, awarding you the bounty, and hopefully this can help someone in the future...Ann
T
1

If I correctly understand you, you are wondering why the server sends Set-Cookie only on the first request. If that is true, then it's by design - take a look here:

Set-Cookie is like a setter - the server sends it for the browser to cache it locally. It can send every time, but there is no need to do that, so it will send it again only if it needs to change the value stored locally.

Browser, on the other hand, will send Cookie header every time with the contents set by the last issued Set-Cookie from the server.

Toga answered 24/11, 2010 at 4:34 Comment(5)
That part I understand. The issue is that after processing this response, subsequent JSON requests to the api.sandbox-freebase.com do not have the Cookie set. (If I open up a new window and just paste the URL api.sandbox-freebase.com/api/service/touch into it, then hit enter, then subsequent requests to api-sandbox-freebase.com have the Cookie set. It just appears that using $.getJSON ignores the Set-Cookie in this case...)Ann
Which browser are you using? I looked at this and found that IE has security policies that disallow this, look here: msdn.microsoft.com/en-us/library/ms537342.aspx and here: htmlcoderhelper.com/…. Taken from this SOq: stackoverflow.com/questions/401535Toga
Thanks for the links...though I dunno if they really provide the definitive answer I'm looking for. So I've opened a bounty. I'm using Firefox and Chrome, BTW.Ann
And it looks like no one knows more than you do about this. :) I was hoping to get a good answer for posterity here... can we get a good cross-browser assurance that JSON requests won't add cookies even against their target domain?Ann
Patience, my friend! I would hardly think this is the last we are going to see here. On another note, you may want to think about alternative (i.e. non-cookie) solutions, if feasible in your case.Toga

© 2022 - 2024 — McMap. All rights reserved.