Last Comment Bug 164023 - Stealing files with file upload and event.relatedTarget
: Stealing files with file upload and event.relatedTarget
[adt1 RTM] [ETA 08/23]
: topembed
Product: Core
Classification: Components
Component: Security (show other bugs)
: Trunk
: All Linux
-- critical (vote)
: mozilla1.0.1
Assigned To: joki (gone)
: bsharma
: David Keeler [:keeler] (use needinfo?)
: 164687 (view as bug list)
Depends on: 164086
Blocks: 143047
  Show dependency treegraph
Reported: 2002-08-22 06:18 PDT by georgi - hopefully not receiving bugspam
Modified: 2011-08-05 22:34 PDT (History)
31 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

proposed patch (1.88 KB, patch)
2002-08-22 11:35 PDT, joki (gone)
no flags Details | Diff | Splinter Review
Testcase (318 bytes, text/html)
2002-08-22 19:21 PDT, John Keiser (jkeiser)
no flags Details

Description User image georgi - hopefully not receiving bugspam 2002-08-22 06:18:38 PDT
test bug
Comment 1 User image georgi - hopefully not receiving bugspam 2002-08-22 06:25:22 PDT
Posting the real bug.

It is possible to steal local files with the file upload control.
This is somewhat related to bug 163598 but the trick is done with
The following reads a local file and sends it to remote server.
Written by <a href="">Georgi Guninski</a>

<form action="http://localhost/cgi-bin/" enctype="multipart/form-data"
Mouse over this:
<input type=file name=c
<input type=submit>


Due to the increased number of file upload attacks, I suggest adding a
warning whenever a file is being uploaded.

Georgi Guninski

Comment 2 User image georgi - hopefully not receiving bugspam 2002-08-22 06:27:30 PDT
cc'ing per mitchell's out of office.
Comment 3 User image Randell Jesup [:jesup] 2002-08-22 07:44:35 PDT
Adding a bunch of people who were on bug 163598
Comment 4 User image scottputterman 2002-08-22 08:04:46 PDT
Any ideas on what it takes to fix this? jkeiser, should this be assigned to you
as well?
Comment 5 User image Jaime Rodriguez, Jr. 2002-08-22 08:12:12 PDT
jkieser: should you own this bug?
Comment 6 User image georgi - hopefully not receiving bugspam 2002-08-22 08:19:51 PDT
This seems very similar to bug 163598.
Comment 7 User image John Keiser (jkeiser) 2002-08-22 10:28:14 PDT
Sigh.  Would someone mind finding these exploits closer to the beginning of a
release cycle? :)  I've never even heard of relatedTarget.

And upload your testcase if you could be so kind.  I'll see what I can see.
Comment 8 User image joki (gone) 2002-08-22 11:34:30 PDT
Okay, so this one raises a couple of interesting questions.  Should
relatedContent be able to see anonymous content at all?  relatedContent is part
of the DOM spec, having content under a file control is not.  Of course that
doesn't change the fact that we use relatedContent to look at anonymous content
inside of tooltips so making it not see anonymous content could regress
something.  I have a fix (extension of the 163598 bug fix) that takes care of
file controls.  That may be as far as we want to go right now.
Comment 9 User image joki (gone) 2002-08-22 11:35:26 PDT
Created attachment 96329 [details] [diff] [review]
proposed patch
Comment 10 User image Jesse Ruderman 2002-08-22 11:53:15 PDT
-> security, joki
Comment 11 User image Asa Dotzler [:asa] 2002-08-22 13:23:06 PDT
Comment on attachment 96329 [details] [diff] [review]
proposed patch

Argh, this copies jkeiser's fix, not including final nit-picks.  Can you (a)
copy the final fix or (b, better) subroutine so the code is shared?

/be (using Asa's laptop)
Comment 12 User image joki (gone) 2002-08-22 13:41:14 PDT
Actually the patch is based on the final version of jkeiser's fix.  But if
you're talking about your ++numParentsChecked nit I just put that in.  As for
sharing the code I have hopes of fixing this version to better deal with
anonymous content in the future (the behavior of relatedTarget and
originalTarget as regards anonymous content is not exactly the same) so I'd
rather keep it separate.
Comment 13 User image Jesse Ruderman 2002-08-22 16:01:35 PDT
See also bug 164086, the same hole using event.rangeParent.
Comment 14 User image John Keiser (jkeiser) 2002-08-22 19:21:40 PDT
Created attachment 96401 [details]
Comment 15 User image Jaime Rodriguez, Jr. 2002-08-22 19:37:04 PDT
adding bclary.
Comment 16 User image John Keiser (jkeiser) 2002-08-26 14:23:04 PDT
*** Bug 164687 has been marked as a duplicate of this bug. ***
Comment 17 User image John Keiser (jkeiser) 2002-08-28 01:32:47 PDT
Fixed with bug 164086.
Comment 18 User image bsharma 2002-09-17 12:44:03 PDT
Verified on 7.0RTM build on Win 2000.

When mouse over on the text field, an exception is thrown and the text of the
"Submit" button is not changed.

When some file is selected in the text box using Browse button and then mouse
over, "Submit" button text is changed and it shows some file location. An
exception is also thrown at this time.

So, reopening the bug to make validate that this behavior is acceptable or not
Comment 19 User image John Keiser (jkeiser) 2002-09-17 13:11:05 PDT
bsharma: are you saying that the text in the Submit button ("Submit Query")
*changes* when you follow these steps:

- Go to
- Click the Browse ... button and select a file [text of file shows up in text
- Mouse over the text input [exception is thrown, nothing user-visible happens]

If not, I'm unclear on what you are saying.
Comment 20 User image bsharma 2002-09-17 13:13:23 PDT
Yes, that is exactly what I mean.
Comment 21 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2002-09-17 13:50:30 PDT
This looks fine to me. I think the bug is fixed. Someone should close it again.
Comment 22 User image Mitchell Stoltz (not reading bugmail) 2002-10-04 14:29:22 PDT
Yes, this seems OK to me. I'm marking the bug Fixed again.
Comment 23 User image bsharma 2002-10-08 10:28:43 PDT
Verified on the 2002-10-08-trunk build on Win 2000.

The test case works as expected.

Note You need to log in before you can comment on or make changes to this bug.