Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

XSS with location.href behavior of some browsers #4787

Closed
masatokinugawa opened this Issue · 18 comments

4 participants

Masato Kinugawa mala John Bender ojid49883
Masato Kinugawa

This bug differs from Issue #1990. I tested on Safari 5.1.7 for Windows, Safari Mobile(iOS 5.1.1).
The vector is:

http://l0.cm%2F@jquerymobile.com/demos/1.2.0-alpha.1/#//l0.cm/jqm

These browsers percent-decode "user:password@" part of location.href. I think XSS comes from this behavior.
FYI, this behavior is fixed as CVE-2012-3695 in Safari 6. See: http://support.apple.com/kb/HT5400

mala

I tested with android emulator, it works on Android 4.0.3 and not works on Android 4.1.
So, it has influence on over 90% of Android users. http://developer.android.com/about/dashboards/index.html

It's a webkit's bug, but I think that it's also jQuery Mobile's bug.
Same-origin checking should be use location.protocol + "//" + location.host

http://trac.webkit.org/changeset/96779
https://bugs.webkit.org/show_bug.cgi?id=30225

Simple workaround code is here

- documentUrl = path.parseUrl( location.href ),
+ documentUrl = path.parseUrl( location.protocol + "//" + location.host + location.pathname + location.hash ),
John Bender johnbender was assigned
John Bender

@masatokinugawa

Thanks for the heads up. I'll be addressing this today.

@mala

Unfortunately firefox has the exact same issue but with the location.hash and not the location.href, so we'll have to do some twiddling there. Otherwise I'm going to centralize the handling so there's less chance of someone using location.href in the future to avoid this.

John Bender

@mala

I'm curious if you can reproduce with window.location.toString(). I'd imagine that the underlying implementation is the same but it would make the fix more simple.

John Bender

@masatokinugawa @mala

We're now in a position to fix this but I'd like to use window.location.toString() if possible. I'm working on reproducing the issue so I can test it.

mala

@johnbender

In my knowledge, location.toString cannot be overwritten, even if it can do, it will not necessarily work in the future.

I just forgot location.search, location.href without user:pass is
location.protocol + "//" + location.host + location.pathname + location.search + location.hash
it also works on file:// url.

It's not related but important, "isSameDomain" can load http page from https page.
I think isSameOrigin is required for more strict security.

John Bender

@mala

In my knowledge, location.toString cannot be overwritten

I'm not sure what you mean. I was curious if window.location.toString() still decoded the user:pass segment. I'm going to try and reproduce tomorrow and if that doesn't work I'll use the string concat.

Thanks for all your help.

mala

@johnbender
window.location.toString() contains decoded username and
window.location.toString = myToStringFunction not work in almost all cases.
getLocation: function() { return … }, is OK.

John Bender

@mala

Yah I would never overwrite a built in method like the toString on location even if it were possible.

John Bender

@mala

Unfortunately the string concat doesn't appear to work on Android 2.3 which means we really have no recourse in addressing this issue for that platform. You said this works for Android 4.0.3 though?

John Bender

@mala

I, of course, am a moron. I'll play around with some regex twiddling to see if I can fix it.

John Bender johnbender closed this in 75ba273
John Bender

@mala @masatokinugawa

I would appreciate your eyes on this fix to make sure I've fully addressed the issue.

75ba273
4348eac

John Bender johnbender reopened this
John Bender

All,

Examining the possibility that our url parser might also be gamed by a well crafted authority in this case. More later.

mala

@johnbender

Hi,

user:pass in location.href is dependent on browser's implementation.
Non-webkit browsers remove user:pass in location.href by default.

see http://jsrun.it/miya2000/2Lyx

It is not necessary to consider percent encoding.
I think that just remove user:pass from location.href is no problem at all.

John Bender johnbender referenced this issue from a commit
John Bender johnbender strip authority to avoid exploits in parse regex
As explained by @mala in Issue #4787, most browsers simply strip the
authority from `location.href` anyway. We can simply mimick this more
secure behavior for the browsers that don't thereby avoiding the
decoding xss.
352f196
John Bender johnbender referenced this issue from a commit
John Bender johnbender strip authority to avoid exploits in parse regex
As explained by @mala in Issue #4787, most browsers simply strip the
authority from `location.href` anyway. We can simply mimick this more
secure behavior for the browsers that don't thereby avoiding the
decoding xss.
2c83dff
John Bender

@mala

Ah! Sorry to take such a roundabout path to your original solution. I was laboring under the false impression that we should preserve the authority, but if most strip it anyway (which they do in my testing) we can't support that.

Thanks again for all your help.

John Bender johnbender closed this
ojid49883

Please teach it.

Is 1.2.0 RC1/RC2 a modified mistake?

http://www.yahoo.com%2F@jquerymobile.com/demos/1.2.0-beta.1/
getLocation
uri.host = jquerymobile.com
uri.hostname = jquerymobile.com

http://www.yahoo.com%2F@jquerymobile.com/demos/1.2.0-rc.1/
getLocation
uri.host = www.yahoo.com
uri.hostname = www.yahoo.com

http://www.yahoo.com%2F@jquerymobile.com/demos/1.2.0-rc.2/
getLocation
uri.host = www.yahoo.com
uri.hostname = www.yahoo.com

mala

@johnbender @ojid49883

ah, enbugged by this commit 51d82b0
location.href returns wrong value, you shouldn't use that.

John Bender

Argh.

Sorry two problems confused there. The hash is also autodecoded by firefox, I'll have to get the hash from a parsed form of the url and everything else from the location object directly.

Thanks for keeping an eye on this :(

John Bender johnbender reopened this
John Bender

https://github.com/jquery/jquery-mobile/blob/master/js/jquery.mobile.navigation.js#L55

@mala @ojid49883

If you guys can take a quick look that should address the issue. You'll note that it handles both cases.

By default it uses the location objects values and parses the hash out of location.href to avoid FF's decoding of location.hash.

Thanks

John Bender johnbender closed this
Alexander Schmitz arschmitz referenced this issue from a commit in arschmitz/jquery-mobile
John Bender johnbender strip authority to avoid exploits in parse regex
As explained by @mala in Issue #4787, most browsers simply strip the
authority from `location.href` anyway. We can simply mimick this more
secure behavior for the browsers that don't thereby avoiding the
decoding xss.
64f3776
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.