Open Bug 252855 Opened 20 years ago Updated 2 years ago

window.find() enables a script to send a string to another page

Categories

(Core :: DOM: Events, defect)

x86
All
defect

Tracking

()

People

(Reporter: murawaki, Unassigned)

References

(Depends on 1 open bug)

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707

A script can set the search string of a Find dialog box by calling find() twise,
first without parameter and secondly with a parameter string:

find();
find("string");

This enables a script to send a string to another page. I think this violates
the same origin policy.

Reproducible: Always
Steps to Reproduce:
----- test1.html -----
<html>
<body>
<script tpye="text/javascript">
window.onblur = function (e) { location.href = "test2.html"; }

find();
find("white");
</script>
</body>
</html>

----- test2.html -----
<html>
<head>
<script tpye="text/javascript">
window.onfocus = function (e) {
    var str = getSelection(); // maybe the selected text was a string
transmitted from test1.html
}
</script>
</head>
<body>
This page should contain strings that can possibly be sent.

white
yellow
blue
red
</body>



1. Load test1.html. A find dialog will be shown and test2.html will be loaded.
2. We expect a user not to cancel the search or not to modify the search string
but just to click "Find". This is a likely assumption.
3. After closing the dialog, the window gets focused. And now str holds the
string sent from test2.html!
Note add document.getElementsByTagName('BODY')[0].innerHTML += "<BR>" +str; to
index2.html so you can see what is happeneing.
I see this on LInux 2004101106
OS: Windows 2000 → All
*sending* information to another page is not a security problem. Any page can
call any other page with a query string to send information. It's *reading* from
(or manipulating) another page that is forbidden. I guess find() does return
true/false whether the string exists and that binary bit could possibly be
leaked back to an attacker, assuming the attacker knows the existence of a
particular page but finds it useful to know whether it does or doesn't contain a
particular string.

Although I don't think there's a problem with find() sending info, the fact that
it's running in the context of the next page is troubling. Are there other
events or functions that could be similarly run after the next page is loaded?
Assignee: dveditz → jst
Component: Security: General → DOM: Events
I'll sort of confirm. Unlike find('string') in the current page that will return
true/false without raising a dialog, in the example testcase the second page
gets the find dialog with 'string' prefilled. The user would have to OK the
dialog before its page gets any info out of it. [Tested with a 1.8a5 trunk build]
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file demo testcase
I modified the testcase in the bug to load mozilla.org instead and wrapped the
find() in an alert. You can see that the calling page gets "false" returned
before the new page loads -- there is no transfer of information here.
In Firefox trunk on Mac, this testcase puts a Find window behind the browser window.  I wonder if those could be used as text-only pop-under ads ;)
QA Contact: events
Depends on: 672395

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.

Assignee: jstenback+bmo → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: