Open
Bug 705415
Opened 13 years ago
Updated 12 years ago
LiveConnect allows JavaScript cookie access despite HTTPOnly
Categories
(Core Graveyard :: Java APIs for DOM, defect, P2)
Tracking
(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)
(deleted),
image/png
|
Details |
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.
Reporter | ||
Updated•13 years ago
|
Severity: normal → major
OS: Linux → All
Priority: -- → P2
Reporter | ||
Comment 1•13 years ago
|
||
@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...
Comment 2•13 years ago
|
||
> @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?
Reporter | ||
Comment 3•13 years ago
|
||
@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?
Updated•13 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [sg:moderate]
Updated•13 years ago
|
Status: NEW → UNCONFIRMED
Ever confirmed: false
Updated•13 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [sg:moderate] → [sg:vector-moderate]
Updated•13 years ago
|
Product: Core → Core Graveyard
Updated•12 years ago
|
Keywords: sec-vector
Comment 4•12 years ago
|
||
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.
status-firefox-esr10:
--- → wontfix
status-firefox14:
--- → wontfix
status-firefox15:
--- → fixed
status-firefox16:
--- → fixed
tracking-firefox14:
--- → -
Depends on: 748343
Comment 5•12 years ago
|
||
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?
Comment 6•12 years ago
|
||
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.
Updated•12 years ago
|
Whiteboard: [sg:vector-moderate] → [sg:vector-moderate][advisory-tracking-]
Updated•12 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•