Open Bug 1228719 Opened 9 years ago Updated 2 years ago

Partial URL spoofing using javascript: URI scheme

Categories

(Core :: Networking, defect, P5)

Product:
Core
Component:
Networking
Version:
42 Branch
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: qab, Unassigned)

Details

(Keywords: csectype-spoof, sec-want, Whiteboard: [necko-would-take])

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Build ID: 20151029151421 Steps to reproduce: This is pretty much a copy of a previous report regarding the DATA: url scheme. https://bugzilla.mozilla.org/show_bug.cgi?id=1221444 I noticed that we can perform the same bug using the javascrip: URI scheme: PoC: <a target='q' href="javascript://#%0a`<script>location.hash='#google.com'</script>`">aaaaaaaa</a> Have the victim press the malicious link. Actual results: We will end up in 'javascript://#google.com' Expected results: Parser handling the javascript URI scheme should consider the hash symbol. This type of behavior may lead to tricking victims into trusting the weird looking address bar. There should really be a full sweep of hash symbol consideration in all URL parsers for all URI schemes. Tested on FF42.0
I'm not sure this is the same kind of bug. The JS URI is parsed correctly. Boris, can you take a look?
Flags: needinfo?(bzbarsky)
> Parser handling the javascript URI scheme should consider the hash symbol. Consider in what sense? The javascript: URI listed is a perfectly valid javascript URI. The spec for those says that the entire string after the ':', including the fragment, is used as the script. So "parsing" javascript: URIs is dead simple: it starts with "javascript:" and everything after that is script.
Flags: needinfo?(bzbarsky)
Though note that implementing bug 836567 might address the spoofing issue here, of course.
(In reply to Boris Zbarsky [:bz] from comment #2) > > Parser handling the javascript URI scheme should consider the hash symbol. > > Consider in what sense? > > The javascript: URI listed is a perfectly valid javascript URI. The spec > for those says that the entire string after the ':', including the fragment, > is used as the script. So "parsing" javascript: URIs is dead simple: it > starts with "javascript:" and everything after that is script. I assumed it was the same issue as the data: bug too soon, my mistake. My only other suggestions are as follows: -The injected newline '%0a' char should be replaced with spaces. Dont see the point of allowing it in a javascript scheme, there is always a semicolon. Also very CSRFy. -Have the javascript: code re-evaluated when location.hash is changed. -Implement some sort of check to see if the document is the real owner, this could be done by checking the original url the document was made from and comparing it to the changed current url
> -The injected newline '%0a' char should be replaced with spaces. That's not equivalent, and could break scripts that use ASI. If all browsers did that and the spec got changed accordingly, it could be done, but the value seems low. >-Have the javascript: code re-evaluated when location.hash is changed. Not web-compatible; would break anchor scrolling in javascript:-generated documents, no? > Implement some sort of check to see if the document is the real owner I'm not sure what you're suggesting here... Can you explain?
(In reply to Boris Zbarsky [:bz] from comment #5) > I'm not sure what you're suggesting here... Can you explain? The address bar should always reflect the window.document content. So 'javascript:1' returns a document with '<body>1</body>' so in this case the URL hints to what the content will be. Similarly with our bug, if we end up in 'javascript://#whatever.com' the content should be empty, because parsing that URL will give us that. So if Firefox had a way to compare the contents of the current window document with the javascript URI in the address bar, and make sure the URL reflects the content otherwise FF should return a blank page or the new content as reflected by the new URL. I can see how this might be a bit too messy though, but I cant think of any other way to solve this problem. Also this suggestion would also solve the more severe bug I reported at https://bugzilla.mozilla.org/show_bug.cgi?id=1228754
> The address bar should always reflect the window.document content. Note that this is already not the case if a site does window.open() (no url) and then modifies the DOM of the resulting document. In any case, as I said above addressing bug 836567 would probably help with that.
(In reply to Boris Zbarsky [:bz] from comment #7) > > The address bar should always reflect the window.document content. > > Note that this is already not the case if a site does window.open() (no url) > and then modifies the DOM of the resulting document. > > In any case, as I said above addressing bug 836567 would probably help with > that. I guess 'about:blank' could be the exception?
Group: core-security
Keywords: sec-want
Whiteboard: [necko-would-take]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.