722126 - Can't transfer File objects with postMessage cross domain

Status: RESOLVED DUPLICATE of bug 1185360

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

Description

[dan]

Attachment: 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.

Comment 1

[dan]

Sorry, missing word in first sentence--I *host* two scripts on two different domains.

Comment 2

[dan]

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?

Comment 3

[dan]

Just tested, fails on FF10 as well.

Comment 4

[Tim (fmdeveloper)]

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?

Comment 5

[Matthias Versen [:Matti]]

http://mxr.mozilla.org/mozilla-central/source/dom/base/domerr.msg#85 looks like DOM

Comment 6

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(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.

Comment 7

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

This should be scheduled for a group review and include Jonas

Comment 8

[dan]

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.

Comment 9

[dan]

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.

Comment 10

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

When ready for security review please reply to comment 0 in bug 744438

Comment 11

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

sorry that should have been 744538

Comment 12

[simon.kaegi]

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.

Comment 13

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Attachment: Just do it

Still need to write a test.

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 681143 [details] [diff] [review]
Just do it

r=me if you add a test

Comment 15

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

:sicking - is this ready for the security team to take a look at it?

Comment 16

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yes. And it's ready for Kyle to land once he gets of his keaster :-)

Comment 17

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

When can we get a secreview scheduled for this?

Comment 18

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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.

Comment 19

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

(In reply to Kyle Huey [:khuey] ([e-mail]) 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

Comment 20

[Daniel Veditz [:dveditz]]

As long as we're cloning the data and not sharing it should be fine.

Comment 21

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

These objects are immutable, so it doesn't really matter.

Comment 22

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

per spec that is true. per implementation it is not though for a File coming from <input type=file>.

Comment 23

[gregersrygg]

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 :)

Comment 24

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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

[Jimmy Warting]

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

Comment 26

[Soeren.Balko]

Running into the same issue, also in Nightly. Apart from fetching the file content into an ArrayBuffer, is there a simpler solution available?

Comment 27

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Andrea, want to have a look at this? Should be trivial to get this patch working I would think.

Comment 28

[Olli Pettay [:smaug][[e-mail]]]

That is what baku is doing in Bug 1185360.