441166 - Blocking third-party cookies blocks non-third party cookies in applets

Status: RESOLVED INVALID

(Core Graveyard :: Plug-ins, defect)

Description

[Jeffrey Bush]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

An applet does not use the cookies of the containing page even when downloaded from the same domain when "Allow third-party cookies" is not checked (network.cookie.cookieBehavior=1) although the cookies are used correctly when it is checked (network.cookie.cookieBehavior=0).

Since the applet cannot make URL connections outside of the domain it is from it can NEVER use third party cookies unless it is signed or approved to do this. The applet may need to maintain the session that the containing document is part of. Java also does not allow reading the cookie information from within the applet and are seamlessly added to the HTTP connection, thus meaning they cannot even be read in the Java applet.

Safari currently allows same-domain applets to use cookies from the containing document even when third-party cookies are blocked.

Reference: Reimplementation of Third-Party Cookies (Bug 421494)

Reproducible: Always

Steps to Reproduce:
1. Put a same-domain applet on a page using either the <object> tag or <applet> tag.
2. Use the applet to connection to a page on the same domain
3. Look at Java console
Actual Results:  
network: Connecting https://domain/page with proxy=DIRECT


Expected Results:  
network: Connecting https://domain/page with proxy=DIRECT
network: Connecting https://domain/page with cookie "session=04aaedcff16ca839dff0e37626e90b21"

Comment 1

[Jeffrey Bush]

HttpOnly cookies are also not given to applets even though unsigned applets have no access to the cookies that will be used.

Comment 2

[Hiroto Kagotani]

Ditto on FreeBSD.

Mozilla/5.0 (X11; U; FreeBSD i386; ja-JP; rv:1.9.0.4) Gecko/2008111515 Firefox/3.0.4

Comment 3

[Boris Zbarsky [:bzbarsky]]

Hmm.  Is the applet making HTTP requests via Necko that it doesn't associate with the page it's loaded from?  If so, that's just broken (e.g. unloading the page won't stop the requests).  Can you possibly point me to a testcase that shows the problem?

Comment 4

[Jeffrey Bush]

I have created a test case to show the problem:

http://www.coderforlife.com/http-only-cookie-test/

It is tests both http-only and normal cookies with browser access, through AJAX, and through Java. Most browsers fail to give http-only cookies to the applet, but only Firefox and Chrome (and IE on High security) fail to give it normal cookies under some circumstances. All source code is available for the tests on that page.

Necko is not being used. Only using java.io.* built-in classes to read the data.

The java network messages show up in the command window with the default verbosity as:
network: Connecting http://www.coderforlife.com/http-only-cookie-test/has_cookie.php with cookie "normal=xxx"

Comment 5

[Boris Zbarsky [:bzbarsky]]

So how do I run that test?  I load it, there are two buttons.  Which of those is buggy, exactly?  What should I be looking for?

And ideal testcase here would be something that makes one and only one HTTP request, which does not get the right cookies sent in your testing, presumably, after I push a button on the page, so that I can trace that one request and see exactly what's happening...

Comment 6

[Jeffrey Bush]

There should be three buttons, and the last one (the Java button) looks different and is the one that is buggy. The others are there to prove that the cookies are working correctly as normal and http-only cookies. I couldn't just make it one button because calling calling functions between Java and JavaScript puts more security on and I wanted to show that it happens without that extra level of security.

I am guessing you are not seeing the Java button. I have recompiled to hopefully be compatible with all versions of Java (previously it was Java 6 only). I currently can only test in Vista and 64-bit Ubuntu, and 64-bit *NIX Java is completely broken, but it has worked on different Vista machines. Can you get other Java applets? This one is really simple and should have no problem starting up...

Comment 7

[Boris Zbarsky [:bzbarsky]]

Ah, now I see three buttons.  Here's the relevant stack:

#0  nsCookiePermission::GetOriginatingURI (this=0x1d3396c0, aChannel=0x0, aURI=0xb0d9317c) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/extensions/cookie/nsCookiePermission.cpp:449
#1  0x138f2ecb in nsCookieService::CheckPrefs (this=0x1d337f80, aHostURI=0x1acf88d0, aChannel=0x0, aCookieHeader=0x0) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/netwerk/cookie/src/nsCookieService.cpp:1878
#2  0x138f769c in nsCookieService::GetCookieInternal (this=0x1d337f80, aHostURI=0x1acf88d0, aChannel=0x0, aHttpBound=0, aCookie=0xb0d93538) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/netwerk/cookie/src/nsCookieService.cpp:1191
#3  0x138f813c in nsCookieService::GetCookieString (this=0x1d337f80, aHostURI=0x1acf88d0, aChannel=0x0, aCookie=0xb0d93538) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/netwerk/cookie/src/nsCookieService.cpp:686
#4  0x13450926 in nsPluginHostImpl::GetCookie (this=0x1d3b5620, inCookieURL=0x18e18e80 "http://www.coderforlife.com/http-only-cookie-test/has_cookie.php", inOutCookieBuffer=0xb0d935b8, inOutCookieSize=@0xb0d935b4) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp:6045
#5  0x188687b2 in MRJGetCookie (inCookieURL=0x18e18e80 "http://www.coderforlife.com/http-only-cookie-test/has_cookie.php", inOutCookieBuffer=0xb0d935b8, inOutCookieSize=0xb0d935b4) at /Volumes/Storage2/Developer/Mozilla/mozilla-1.6/plugin/oji/MRJCarbon/plugin/i386/../Source/MRJPlugin.cpp:254
#6  0x18a21d17 in Java_JEPCookieHandler_getCookie (env=0x18e15e60, self=0xb0d95610, url=0xb0d9560c) at /Volumes/Storage2/Developer/JavaEmbeddingPlugin/Project/JavaEmbeddingPlugin0.9.6.5/i386/../AppletView.m:346

Note that the request the cookie is for is NOT passed in to the cookie service, which makes it impossible to determine where the request is coming from.  The fail-safe behavior in this case, of course, is to not hand out the cookie.

I have no idea whether this is a bug in the Java Plug-in or in the plugin host.  But it's certainly not a necko bug.

Comment 8

[[e-mail]]

ah, this is coming from pluginhost... that API doesn't include any provision for passing in request info. this was one of the things that we knew would break...

not much we can do here, i think, short of changing the plugin API. :(

Comment 9

[Boris Zbarsky [:bzbarsky]]

I think we should extend the plug-in API as needed here...

Comment 11

[Mauno Ryytty]

This bug breaks JNLP-based applet usage when session authentication is used.
'Accept third party cookies' must be checked. Otherwise You don't get the jnlp file, instead javaws sees  the login form.

Comment 12

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

The HTML <applet> element and related java functionality was removed from Gecko in Bug 1279218. Marking related bugs as invalid.