1255687 - chrome-url with contiguous dots (.) is not a valid url?

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[Duan Yao]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160210153822

Steps to reproduce:

Run the following code in dev console:

  fetch('chrome://a/content/b..txt')



Actual results:

An error "chrome://a/content/b..txt is not a valid URL" is raised.


Expected results:

'chrome://a/content/b..txt' should be treated as a valid URL.

Urls of other schemes don't have such problem.

Comment 1

[Andrew Overholt [:overholt]]

Ben, WDYT?

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

AFAICT this is a security measure to prevent unexpected paths from being traversed with elevated privileges:

  https://dxr.mozilla.org/mozilla-central/source/chrome/nsChromeRegistry.cpp#233

This was added in bug 413250.

I think this is working as intended.  Marking WONTFIX.

Comment 3

[Duan Yao]

Why 'chrome://a/content/b..txt' is insecure? Only patterns like '/../' causes traversal to parent directory.

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

Sure, but parsing URLs is harder than it first appears.  I think we are being conservative here in order to avoid unexpected parsing bugs.  Also, consecutive dots in a file name is extremely uncommon.  I don't see why we would want to make the privileged URL parsing code more complex for such a rare use case.

I'll NI Daniel, though, since he implemented this code.

Comment 5

[Daniel Veditz [:dveditz]]

The code is overly strict, but no one has used double-dotted chrome:// filenames since Firefox 2 until now. Doesn't seem worth putting a lot of effort into fixing given the other stuff we have to do. I'd be happy to review a patch though.