Re: why file upload cannot work?

Dan Rumney wrote:
Thomas 'PointedEars' Lahn wrote:
[snip]
My interpretation of the OP's request was the following question:

Is it possible to write a script that mimic's a user clicking the upload
box.
That is assuming that there is always an upload _button_.

Is your point that a text only browser would have an... [...]

My point is instead that no Web standard says how a file input control is to
be rendered; HTML 4.01 only says what it should allow to do. And that is
good so.

Nothing nefarious... just some way of opening the Open... dialog
such that the file input control's value will be populated in a
legitimate fashion.
[...]
I thought that the click function would do it, but I think all that does
is emulate the user clicking at some random point on the control and not
specifically on the Upload button.

Any thoughts?
ISTM the proprietary click() method is available for input[type="file"]
controls but does nothing at all (in Firefox 2.0.0.14/Gecko 1.8.1.14), not
even emulating a random click anywhere within the control's canvas. In
contrast to clicking directly, the `click' event does not occur for this
control when click() is called. However error-prone, it does occur then for
other types of controls.

And wouldn't you know it, it 'works' in MSIE.

True.

Personally, I think it's a shame that there's no way to do this (See below)

This might be another security precaution to prevent an attacker from
selecting a file programmatically.

Granted, but I grow a little tired of 'security precautions'.
I'm not laissez-faire about security, but I get frustrated at imposed
restrictions because there's some chance that somebody somewhere might
be able to do something that needs to be prevented.
It's a no-win argument because the security advocates do not need to
back up their position. They have the trump card which is "security risk"

I don't think so. For example, recently Gecko established a customizable
few-seconds timeout before a download/install dialog can be confirmed
because otherwise there was the possibility that the user accidentally
executed malicious software when pressing the return key while typing and a
script kiddie had the dialog window pop up. IIRC there was a real case that
prompted this design decision, and I think it is a Good Thing that it was
implemented. (Making the Cancel button the default instead would have been
rather counter-intuitive.)

The same thing could happen with a file upload/select dialog window that
popped up without user interaction.

Slight rant aside, this kind of attack, in my mind, could be more
readily protected against by alerting the user whenever a file is to be
transferred by the UA. The UA knows that it's about to read a local file
(because it's going to have to open a handle to that file) so why not
post a warning, instead of hobbling the functionality of form controls?

Maybe because the probability that a user uses an file upload control on
purpose (maybe without having scripting enabled) is greater than the
probability of a script kiddie wanting to click on it without user interaction.


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
.