729150 - Firefox 4.0->10.0.2 do not correctly enforce Same origin policy for JavaScript

Status: RESOLVED DUPLICATE of bug 655649

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

Description

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

Attachment: Domain Test submitted by reporter

Hi,

starting with FF4.0 and up to 10.0.2 Same origin policy for javascript as described here: https://developer.mozilla.org/en/Same_origin_policy_for_JavaScript is not working anymore

how to reproduce:
1. set up a html document on foo.foobar.com containing an iframe
2. load in iframe another document from foo.foobar.com which changes via javascript document.domain to foobar.com
3. you can see that from document loaded in iframe you can call functions in parent document without problems even if document origins are different.

find attached a couple of files to test this.
- put them in the root of an http server
- set in hosts of your machion an entry for foo.foobar.com pointing to your server ip
- load http://foo.foobar.com/domaintest.html

press the link to load second document in iframe and see the alert

This only affects FF 4.0 and up

FF up to 3.6 are not affected
IE 5.5, 6 , 7, 8 ,9 are not affected (previous versions not tested)
Chrome is not affected
Safari is not affected
Opera is not affected

This is not a proof of concept. Domain widening via javascript is a common technique used from years to prevent javascript content which run in iframe from accessing parent page. This has been used for example to show email contents (potentially dangerous) in web clients in the case filtering of bad js fails.
It hurts literally millions of people.

Simone Leprai

Comment 1

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

Attachment: Domain Test iFrame submitted by reporter

Comment 2

[Daniel Veditz [:dveditz]]

The tests from bug 601277 didn't land. This will need to be fixed before they do (otherwise either they'll fail or we've got bogus tests).

Comment 3

[Daniel Veditz [:dveditz]]

Attachment: testcase if framed by BMO (try the "details" link)

Comment 4

[Daniel Veditz [:dveditz]]

Comment on attachment 599223 [details]
testcase if framed by BMO (try the "details" link)

oops, wrong file. ignore this one

Comment 5

[Daniel Veditz [:dveditz]]

Attachment: testcase (see comment 6 for use)

Comment 6

[Daniel Veditz [:dveditz]]

My testcase isn't as convenient as it could be, but

1. Open web console
2. Paste the following line and hit enter

{var i=document.createElement("iframe"); i.src="https://bug729150.bugzilla.mozilla.org/attachment.cgi?id=599224"; i.width=600; document.body.appendChild(i);}

3. Scroll to the frame. Click the "parent cookie" button

  Expect: security exception alert. This is correct behavior

4. Click the "set domain" button
5. Click the "parent cookie" button

  Expect: security exception alert. This is correct behavior
  because although the frame's domain now matches BMO, BMO
  itself has not "opted in" to document.domain.

  The claims in this bug led me to believe I would see BMO cookies at this
  point. If I did that would definitely be a security problem

6. In the web console enter {document.domain=document.domain;}
7. Click the "parent cookie" button

  Expect: alert with BMO cookies since the bug page has now opted-in.

Will have to set up a server to test the pages supplied by the reporter. Seems unlikely, but possible that function calls are handled differently than property access. Also might be a difference between built-in DOM properties like document.cookie and page-created properties.