do better job of choosing filename for data: URIs when saving

NEW
Unassigned

Status

()

Firefox
File Handling
--
enhancement
11 years ago
3 months ago

People

(Reporter: VK, Unassigned)

Tracking

({helpwanted, student-project})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9

window.loacation seems treating argument not as opaque string but something as to resolve: at least it's trying to resolve data() URL.

As reported by user Jeff at comp.lang.javascript (see the URL) an assignment like
 window.location = 'data:plain/text,Test';
leads to FileSave dialog with cryptic default file name "d2zmrxtf" which alone suggests a unexpected exploit of window.location property.

P.S. I'm not the founder, I'm just pointing your attention to the post.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
(Reporter)

Comment 1

11 years ago
Created attachment 251771 [details]
Demonstration of the exploit

I confirm that the observed phenomenon is in effect for the Internet zone as well. See the attached HTML page in action at http://jsnet.sourceforge.net/tmp/367231.html

Comment 2

11 years ago
What is this exploiting? This looks like mostly-proper use of the data: protocol to me, not a bug. There is a problem with your webpage that it uses plain/text instead of text/plain. So instead of displaying the data, we try to save it to disk.
Thanks for bringing this post to our attention. This is how the data: scheme is supposed to work, the only odd behavioral issue is that since it wasn't loaded from a particular path from which we could take a file name, and because it's not an HTML document where we could use the <title>,  we pick a unique temporary name.

This is not a security problem.

Because it's confusing you could make the case for an enhancement request that we should prompt the user for a filename when we don't have one rather than pick something random.
Group: security
Severity: major → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: window.location accepts data() URL → prompt for filename rather than save data: uris with a random name
(Reporter)

Comment 4

11 years ago
(In reply to comment #3)
> Thanks for bringing this post to our attention. This is how the data: scheme is
> supposed to work, the only odd behavioral issue is that since it wasn't loaded
> from a particular path from which we could take a file name, and because it's
> not an HTML document where we could use the <title>,  we pick a unique
> temporary name.

Thank you for clarification about the file name and sorry for troubles then. My primary impression was that this approach does allow to escape the regular sandbox and given the popularity of news:comp.lang.javascript I just wanted to report it as quick as possible. Further tests show that the sandbox is still imposed by the page from where the navigation occurs, so there is not obvious vilnerability in here.

Comment 5

11 years ago
I too am running into this issue. I want to forward an hCalendar microformat appointment from Firefox to PalmDesktop. I use:
    <a href="data:text/x-vcalendar,_escaped VEVENT comes here_"/>
However, as reported previously, Firefox picks up not only a random file name.

Beside the filename, there's another issue: Firefox does not add an extension to the filename (how could it when it does know what the user intends?). This leads to the appointment being ignored by PalmDesktop.

Suggestion: add "name" or "filename" parameter to the data: URI scheme (as per older RFC1806 or former Content-Disposition header field). Example:
    <a href="data:text/x-vcalendar;filename='event.vcs',..."/>

Comment 6

11 years ago
Comment 5 seems like a good strategy to me.  Short of that, and easier, is to attempt to infer an extension from the MIME type; possibly having a short hard-coded list, or, better, using the OS MIME-typing mechanism.
OS: Windows 98 → All
Hardware: PC → All
Summary: prompt for filename rather than save data: uris with a random name → do better job of choosing filename for data: uiris when saving
Summary: do better job of choosing filename for data: uiris when saving → do better job of choosing filename for data: URIs when saving

Comment 7

9 years ago
When saving a inline file (NOT image), Firefox (3.0.6/Win32) generates temporary file name with the correct extension (by mimetype), but it also appends the ".part" extension, so the saved file has confusing name "filename.ext.part" instead of expected "filename.ext". This shoud be also corrected.

Comment 8

9 years ago
Comment #6 is from 04.2007 and #7 - 02.2009. Is there any progress with that issue?
I'm trying to use such a functionality when generating m3u file from a page. The strange thing is that if i save the generated with a random name file it is in format <random-name>.m3u.part, but if i choose to open it, instead of directly saving it, file name is in format <random-name>.m3u.part.m3u.
Not entirely sure where this should go, but data: URI support is Core... somewhere.
Component: File Handling → File Handling
Product: Firefox → Core
QA Contact: file.handling → file-handling

Updated

8 years ago
Duplicate of this bug: 546045
Keywords: helpwanted, student-project
Comment 5 is tracked in bug 532230, even if it is listed as a Mac OS issue.

Comment 12

6 years ago
Until this gets fixed it is impossible to perform client side file processing and export.

Chrome has added a download attribute to a tags that handles the naming of the file. http://html5-demos.appspot.com/static/a.download.html
> Chrome has added a download attribute to a tags that handles the naming of
> the file. http://html5-demos.appspot.com/static/a.download.html

See bug 676619

Comment 14

5 years ago
5 years old issue...

Comment 15

5 years ago
Changing the data: URL scheme to add a filename would imply non-complaince with RFC 2397. The only way to include the filename in the URI would be to hack the "mediatype" value by adding non-standard parameters. This may have an imapct on the browser interpretation of conten-length that would need to be assessed.

The best solution I can find is to use the download attribute of <a> tag. This is being solved in bug 676619 and should be implemented in Firefox 20.
(In reply to Kris from comment #15)
> Changing the data: URL scheme to add a filename would imply non-complaince
> with RFC 2397. The only way to include the filename in the URI would be to
> hack the "mediatype" value by adding non-standard parameters. 

Since the mediatype has an explicit provision for _custom_ attribute=value pairs (see the referenced RFC2045, page 12), using it for signaling a preferred filename wouldn't be a hack nor a non-compliance with the RFC. In the worst cast it could be considered a mere extension of the RFC.

Also, IMHO, using the "download attribute of <a> tag" would be ugly for data programmatically generated by js code.

Updated

a year ago
Component: File Handling → File Handling
Product: Core → Firefox
You need to log in before you can comment on or make changes to this bug.