Closed Bug 705415 Opened 13 years ago Closed 9 days ago

LiveConnect allows JavaScript cookie access despite HTTPOnly

Categories

(Core Graveyard :: Java APIs for DOM, defect, P2)

x86
All

Tracking

(firefox14- wontfix, firefox15 fixed, firefox16 fixed, firefox-esr10 wontfix)

RESOLVED INCOMPLETE
Tracking Status
firefox14 - wontfix
firefox15 --- fixed
firefox16 --- fixed
firefox-esr10 --- wontfix

People

(Reporter: mario, Assigned: ashuk)

References

Details

(Keywords: sec-vector, Whiteboard: [sg:vector-moderate][advisory-tracking-])

Attachments

(1 file)

Attached image Screenshot
User Agent: Mozilla/5.0 (Ubuntu; X11; Linux i686; rv:8.0) Gecko/20100101 Firefox/8.0
Build ID: 20111115183158

Steps to reproduce:

A small JavaScript/LiveConnect/JavaScript-To-Java snippet was created attempting to read the header fields of a website using HTTPOnly cookies. The snippet looks like this:

<script>
var jurl = new Packages.java.net.URL(document.URL);
var c = jurl.openConnection();
var h = c.getHeaderFields();
alert(h)
</script>

The website used for the PoC is this:
http://greebo.net/owasp/httponly.php

Other websites were tested as well (Deutsche Post E-POSTBRIEF etc.).


Actual results:

Since Java even in latest version seems to ignore most security mechanisms utilized by the browser, the cookie values are being returned despite the HTTPOnly settings. Note that Java's internal browser even bypasses X-Frame-Options - but that's going to be a different ticket.

A screen-shot has been created to demonstrate the effect:
http://a.yfrog.com/img611/9809/smip.png


Expected results:

Actually, the user agent should not allow the Java Plugin to bypass its security boundaries. I know this is hard and almost impossible by design - but given the penetration the JRE is said to have one can assume that a vast percentage of users surfing with Firefox is affected: http://www.statowl.com/java.php

LiveConnect makes it even easier to exploit the issue - and should be disabled by default. According to our research, LiveConnect is being used rather rarely itw. The BeefProject uses it to retrieve a victim's internal IP though :) (<- emoticon)

Note that disabling Java in NoScript does NOT affect LiveConnect. A user would have to deactivate the plug-in.
Severity: normal → major
OS: Linux → All
Priority: -- → P2
@Giorgio I added you to this ticket since I think it might make a bit sense in terms of mitigation to kill the Packages object in NoScript - then Java=disabled would indeed mean Java=disabled ;) Any thoughts? I might be wrong here...
> @Giorgio I added you to this ticket since I think it might make a bit sense
> in terms of mitigation to kill the Packages object in NoScript - then
> Java=disabled would indeed mean Java=disabled ;) Any thoughts? I might be
> wrong here...

@mario: 

AFAIK disabling Java in NoScript DOES disable LiveConnect, and even recognizes the attempt and propose "java-vm" to be unblocked under the "Blocked Objects" submenu. I've specific and rather complex code in place to ensure this to happen.

Of course this makes sense only if you've got "NoScript Options|Embeddings|Apply these restrictions to whitelisted sites as well" checked, because you need JavaScript to use LiveConnect.

If you've got evidence of the opposite, it would be a bug and should be fixed: Firefox version, NoScript version and POC?
@Giorgio: Alright - after clicking myself through to that very option, LiveConnect will indeed be disabled. I find that rather counter-intuitive though. If the check-box says Java is disabled, I expect it to be disabled. But in the end you are right - no NoScript bug here - just a wee bit blurry communication in the settings ;)  

@all Nevertheless, LiveConnect bypasses many security features very easily - including HTTPOnly and XFO. I'd still vouch for disabling it by default if possible - any thoughts?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [sg:moderate]
Status: NEW → UNCONFIRMED
Ever confirmed: false
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [sg:moderate] → [sg:vector-moderate]
Product: Core → Core Graveyard
Keywords: sec-vector
Keywords: sec-other
This should be fixed by the removal of window.java and window.Packages in bug 748343 in Firefox 15 (Aurora currently). Given the risk of breakage on unknown corporate webapps we're reluctant to back-port that change to the ESR-10 branch, but they'll hopefully have time to figure out workarounds (use an <applet> shim if necessary) for ESR-17.

Of course that doesn't solve the problem that Java itself allows access to the raw cookie headers, and you could write an applet that communicated with a page to pass the same information back out.
LiveConnect is lax on implementing the Same Origin Policy, when it comes to shared hosting.
Hosts that reside on the same IP Address can be requested and read using the same method (no protocol upgrade to HTTPS possible). This includes response header and body.

Proof of Concept: http://html5sec.org/java

Maybe this detail makes it worth reconsidering this bug?
It's not "LiveConnect" that's lax, it's java! And when the browser and DOM have a different idea of origin all sorts of problems ensue.
Whiteboard: [sg:vector-moderate] → [sg:vector-moderate][advisory-tracking-]
Group: core-security
Status: NEW → RESOLVED
Closed: 9 days ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: