URL() handling of single-quote character in domains handled inconsistently amongst browsers
Categories
(Core :: Networking, task, P5)
Tracking
()
People
(Reporter: pahan.ranjit0201, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: reporter-external, Whiteboard: [necko-triaged][reporter-external] [client-bounty-form] [verif?])
BUG
Improper validation of url cause major security issue
TESTED VERSION
tested in FIREFOX browser windows and Linux 118.0.1
DETAILS
Firefox has built-in url parser "new URL" .
But it does not properly escape/encode single-qoute(') from url host part . So, this cause various secuirty vulnerability
try bellow command and see the result
new URL("http://example.com'/")
result
URL { href: "http://example.com'/", origin: "http://example.com'", protocol: "http:", username: "", password: "", host: "example.com'", hostname: "example.com'", port: "", pathname: "/", search: "" }
here see provided malicious url is http://example.com'/ and new URL() does not escape/encode single-qoutes(') from this url href,hostname,origin part
**here i found rfc . Host can only contain dot,alphanumeric and "-" .
https://www.rfc-editor.org/rfc/rfc3986.html Page-20
https://datatracker.ietf.org/doc/html/rfc1738 page 5
defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123].
Such a name consists of a sequence of domain labels separated by ".",
each domain label starting and ending with an alphanumeric character
and possibly also containing "-" characters. The rightmost domain
label of a fully qualified domain name in DNS may be followed by a
single "." and should be if it is necessary to distinguish between
the complete domain name and some local domain.
**i just checked all the modern browser like chrome, microsoft edge,opera,brave-browser,vivaldi,safari,yandex properly filter this payload .
they urlencode the single-quotes(') present in host part .
But it only exception for firefox browser .
here is sample code to make xss attack
<!DOCTYPE html>
<html>
<head>
<title>Page Title</title>
<style>
</style>
</head>
<body>
<div id=aaa>
</div>
<script>
var u=new URL("http://example.com'/onmouseover=alert();//")
hh="<a href='"+u.href+"'>sddsf</a>"
document.getElementById("aaa").innerHTML=hh
</script>
</body>
</html>
host this page and open this page in browser and mouseover over the url to execute xss .
This is happening only becauses of single-quotes present in host part . this single-quote(') breaks the html context .
You should also urlencode the single-quote character present in host part just like all the other modern web-browser did .
|
||
Comment 1•1 year ago
|
||
This is happening only becauses of single-quotes present in host part . this single-quote(') breaks the html context .
In this scenario, presumably the assumption is that you can somehow insert a value in the webpage that gets passed to the new URL constructor?
And you insert the value:
http://example.com'/onmouseover=alert();//
which gets escaped by blink and webkit. So the ' doesn't lead to XSS. But surely you could also just insert:
http://example.com/'onmouseover=alert();//
so put the ' after the host portion, which doesn't get escaped anywhere (tested in Chrome), and would have the same effect?
Because of this, I think any website that relies on new URL causing escaping and "defending" against XSS is wrong and should be fixed on the website.
Not escaping is potentially a browser bug (the RFC you cite is woefully out of date; the RFC doesn't even make sense here because the % sign used for escaping is also invalid according to that RFC! URL parsing is governed by https://url.spec.whatwg.org/ these days and I haven't checked what it says about escaping hosts), which if so I imagine is already on file as a public bug in this tracker, but either way I don't think it's a security issue that needs to stay hidden.
|
|
||
Updated•1 year ago
|
|
||
Comment 2•1 year ago
|
||
From the parser POV the single quote is valid because it's not one of the forbidden host characters:
https://url.spec.whatwg.org/#host-miscellaneous
Then again, the same section doesn't seem to rule out double-quote, and that -does- result in an error. Seems like something's missing in the spec. I'm deliberately ignoring the RFCs because the URL spec says to, in part because in practice DNS servers and browsers have allowed more characters than the RFCs allow.
According to the same section, U+0025 (%) --is-- a forbidden domain code point. The other browsers are arguably wrong to be percent-encoding that character. Then again https://github.com/whatwg/url/issues/796 was filed to consider allowing percent encoded domains.
All the browsers' results for a domain with an apostraphe are nonsense domains so I think the URL spec needs some help. Let's stick this in the interop-2023 bucket
I agree with Gijs that this is not a security problem. String concatenation with user input is dangerous on the web, and always needs to be sanitized. The sanitization in one context (for example URL) is not always the correct sanitization in another context (for example, element attributes)
| Comment hidden (off-topic) |
| Comment hidden (off-topic) |
|
||
Comment 5•1 year ago
|
||
According to the reference URL parser we are currently parsing ' in the hostname correctly
https://jsdom.github.io/whatwg-url/#url=aHR0cDovL2V4YW1wbGUuY29tJy8=&base=YWJvdXQ6Ymxhbms=
If we were to change this behaviour it would have to be in cooperation with the other browsers.
There's already an issue for it, but it hasn't had a lot of traction recently https://github.com/whatwg/url/issues/390
|
|
||
Updated•1 year ago
|
|
|
||
Updated•1 year ago
|
|
|
||
Updated•1 year ago
|
|
|
||
Updated•10 months ago
|
|
||
Updated•8 months ago
|
Description
•