Can't transfer File objects with postMessage cross domain

RESOLVED DUPLICATE of bug 1185360

Status

()

RESOLVED DUPLICATE of bug 1185360
7 years ago
3 years ago

People

(Reporter: dan, Assigned: khuey)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
sec-review +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
Created attachment 592471 [details]
Bug Example.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Build ID: 20111220165912

Steps to reproduce:

I two scripts on two different domains (postmessagea.s3.amazonaws.com (A) and postmessageb.s3.amazonaws.com (B)). I navigate to A/A.html and select a file. The submit posts a message to B/B.html. The message contains the File object selected in the input element.

View code within attached zip file to reproduce the issue.


Actual results:

The script A/A.js fails when sending the file object via postMessage. "The object could not be cloned."


Expected results:

The file object should be transferred to B/B.js.
(Reporter)

Comment 1

7 years ago
Sorry, missing word in first sentence--I *host* two scripts on two different domains.
(Reporter)

Comment 2

7 years ago
A follow up question--how can I test for availability of this feature without requiring the user to select a file and then click submit? Is there a "fake" file object that I can instantiate and attempt to post to the script on the other domain, or do I simply have to wrap the whole thing in a try-catch block?
(Reporter)

Updated

7 years ago
(Reporter)

Comment 3

7 years ago
Just tested, fails on FF10 as well.
Version: 9 Branch → 10 Branch

Comment 4

7 years ago
I get the following error on Trunk:

Timestamp: 2/12/2012 2:59:22 PM
Error: uncaught exception: [Exception... "The object could not be cloned."  code: "25" nsresult: "0x80530019 (NS_ERROR_DOM_DATA_CLONE_ERR)"  location: "http://postmessagea.s3.amazonaws.com/A.js Line: 10"]

Similar: Bug 673692

Core: Javascript Engine product/component?

Matti -> Do you know anything about this feature?
http://mxr.mozilla.org/mozilla-central/source/dom/base/domerr.msg#85 looks like DOM
Component: Untriaged → DOM
Product: Firefox → Core
QA Contact: untriaged → general
(In reply to dan from comment #2)
> A follow up question--how can I test for availability of this feature
> without requiring the user to select a file and then click submit? Is there
> a "fake" file object that I can instantiate and attempt to post to the
> script on the other domain, or do I simply have to wrap the whole thing in a
> try-catch block?

You can use BlobBuilder to construct a blob you can use to check.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: sec-review-needed
OS: Mac OS X → All
Hardware: x86 → All
Version: 10 Branch → Trunk
This should be scheduled for a group review and include Jonas
Whiteboard: [secr:curtisk]
(Reporter)

Comment 8

7 years ago
I have just updated the example code to show how you can reconstruct the blob on the receiving frame, without any data loss. If this is indeed a security issue (and I hope it's not because I need to use this feature for direct-to-s3 uploads!), then it's almost impossible to circumvent as long as BlobBuilder + ArrayBuffer + postMessage exists.

Just go to http://postmessagea.s3.amazonaws.com/A.html, browse to a file, and open up Firebug. Click "send file" to see the bug, then click "send contents and reconstruct file via blobbuilder" to see how it can be circumvented.
(Reporter)

Comment 9

7 years ago
I should add that FileReader is a necessary component as well.

But given those 4 tools, file transfer cross domain can be achieved no matter what.
When ready for security review please reply to comment 0 in bug 744438
Whiteboard: [secr:curtisk] → [secr:curtisk:744538]
sorry that should have been 744538
Whiteboard: [secr:curtisk:744538] → [sec-assigned:curtisk:744538]

Updated

7 years ago
Blocks: 752563
Flags: sec-review?(curtisk)
Whiteboard: [sec-assigned:curtisk:744538]

Comment 12

6 years ago
Is this bug still being worked on?
Sort of getting tired of having to have to explain to developers why there is a separate code path for Firefox to convert Blobs to ArrayBuffers before postMessages.

One of the main examples of an Eclipse Orion plugin that we work on at hackathons is writing fileservice extensions and the inability to pass Blobs without first converting to an ArrayBuffer is a significant stumbling block.
Created attachment 681143 [details] [diff] [review]
Just do it

Still need to write a test.
Assignee: nobody → khuey
Status: NEW → ASSIGNED
Attachment #681143 - Flags: review?(jonas)
Comment on attachment 681143 [details] [diff] [review]
Just do it

r=me if you add a test
Attachment #681143 - Flags: review?(jonas) → review+
:sicking - is this ready for the security team to take a look at it?
Yes. And it's ready for Kyle to land once he gets of his keaster :-)
When can we get a secreview scheduled for this?
Flags: needinfo?(khuey)
I don't think it needs a sec review.  We should just land it.  You can always transfer this data via other means as stated in comment 12.
Flags: needinfo?(khuey)
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #18)
> I don't think it needs a sec review.  We should just land it.  You can
> always transfer this data via other means as stated in comment 12.

dveditz thought we needed to do a team review of this one, but it's been so long flagged that I can't remember his concerns, if he is fine with removing the sec-review flag then this can pass by, otherwise we need to find a time to talk this one through with the team
Flags: needinfo?(dveditz)
As long as we're cloning the data and not sharing it should be fine.
Flags: sec-review?(curtisk)
Flags: sec-review+
Flags: needinfo?(dveditz)
These objects are immutable, so it doesn't really matter.
per spec that is true. per implementation it is not though for a File coming from <input type=file>.

Comment 23

5 years ago
Was going to report this bug. Was nice to see it's been fixed already. The security issue (bug 744538) is marked as resolved, and from the comments it sounds like it's nothing else stopping this from being merged. Would be nice if this could land soon :)
I got pinged about this on twitter the other day.  I actually don't think this patch works anymore, because it depends on the old XPConnect behavior of creating a wrapper for each scope for things that aren't wrapper cached.  I think we need to create a clone of the FileList in the new scope.

Comment 25

4 years ago
been 2.5 year now since this was reported. Is anyone looking into this?

Comment 26

4 years ago
Running into the same issue, also in Nightly. Apart from fetching the file content into an ArrayBuffer, is there a simpler solution available?
Andrea, want to have a look at this? Should be trivial to get this patch working I would think.
That is what baku is doing in Bug 1185360.
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1185360
You need to log in before you can comment on or make changes to this bug.