why file upload cannot work?

Dan Rumney wrote:

Thomas 'PointedEars' Lahn wrote:
Of course. By disabling the file input control you have only caused only
the encoded file path to be submitted per `photoUrl'. A file input control
in a form causes the encoded content of the selected file to be submitted
instead. And if it was possible to set the value of that control with
scripting, any Web site you visit could upload any file from your computed
without your knowing it; you do not want that to happen. (Using
display:none as suggested will not change that.)

Certainly the risk of being able to set the value of a file input
control via a script is clear to those who understand its function.

I would not be so sure.

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_.

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.

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


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

Thomas 'PointedEars' Lahn wrote:
[snip]

Certainly the risk of being able to set the value of a file input
control via a script is clear to those who understand its function.

I would not be so sure.

I confess to a little weaselry here. I'd argue that anyone who isn't
aware of this risk doesn't understand its function ;o)

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... well, I'm not
sure what the text-only version of a button is called. But I concede the
point that a button is only the appropriate term for a graphical
representation of the form, but I'm pretty sure my meaning was clear.

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. 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"

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?

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>