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)
Tracking
()
NEW
People
(Reporter: murawaki, Unassigned)
References
(Depends on 1 open bug)
Details
Attachments
(1 file)
212 bytes,
text/html
|
Details |
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
Comment 2•20 years ago
|
||
*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
Comment 3•20 years ago
|
||
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
Comment 4•20 years ago
|
||
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.
Comment 5•17 years ago
|
||
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 ;)
Updated•15 years ago
|
QA Contact: events
Comment 6•2 years ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.
Assignee: jstenback+bmo → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•