-
Notifications
You must be signed in to change notification settings - Fork 2.4k
XSS with location.href behavior of some browsers #4787
Comments
I tested with android emulator, it works on Android 4.0.3 and not works on Android 4.1. It's a webkit's bug, but I think that it's also jQuery Mobile's bug. http://trac.webkit.org/changeset/96779 Simple workaround code is here
|
Thanks for the heads up. I'll be addressing this today. Unfortunately firefox has the exact same issue but with the |
I'm curious if you can reproduce with |
We're now in a position to fix this but I'd like to use |
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 It's not related but important, "isSameDomain" can load http page from https page. |
I'm not sure what you mean. I was curious if Thanks for all your help. |
@johnbender |
Yah I would never overwrite a built in method like the |
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? |
I, of course, am a moron. I'll play around with some regex twiddling to see if I can fix it. |
I would appreciate your eyes on this fix to make sure I've fully addressed the issue. |
All, Examining the possibility that our url parser might also be gamed by a well crafted authority in this case. More later. |
Hi, user:pass in location.href is dependent on browser's implementation. see http://jsrun.it/miya2000/2Lyx It is not necessary to consider percent encoding. |
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. |
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/ http://www.yahoo.com%2F@jquerymobile.com/demos/1.2.0-rc.1/ http://www.yahoo.com%2F@jquerymobile.com/demos/1.2.0-rc.2/ |
ah, enbugged by this commit 51d82b0 |
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 :( |
https://github.com/jquery/jquery-mobile/blob/master/js/jquery.mobile.navigation.js#L55 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 |
As explained by @mala in Issue jquery-archive#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.
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
The text was updated successfully, but these errors were encountered: