> In my method JavaScript would have to be used to automatically submit
> a
> HTML Form to the server. In these forms a page writer could have
> already coded the file name into the source document, such as
> "autoexec.bat". When the browser loads the page off of the server, it
>
> submits the form which transmits the file to the server via the
> HTTP-File upload procedure. The SERVER now has the file the author
> wanted. To fool the user, the CGI program sends the location of the
> real web page to the client, and the client doesn't know otherwise.
>
> This method would require the files to be small or else the user will
> notice this is taking a long time to load the page over a modem. But
> the potential for this exploit to be used over faster transmission
> lines
> is greater.
>
> To have a solution to this problem would be a warning dialog box,
> telling the user that they are transmitting a file not just a regular
> HTTP form. I have not written a single line of code exploiting this
> potential vulnerability, I might get around to it if I have time.
>
> Please note: I sent this original message 1 day (June 12) before to
> Netscape and now they confirm that my hypothesis was correct on the
> URL:
>
> http://home.netscape.com/misc/security_update.html
Yes, this is absolutely correct. You have proved my points also. Please
see my message on netscape.security newsgroup, titled "Re: Security
BUG".
I have then post the same message to other newsgroups one day after,
which is today. I want public to know the truth, instead of being panic.
The following is the original message.
--------------------------------------------------------------------------
This is probably caused by the support of <INPUT TYPE=FILE> tag. This
tag allows you to send a file to a server side CGI program with the
multi-part mime type. As it is an "Input type" tag, you can assign a
default value to it. You can than write maybe a Java or a JavaScript to
force submit the form data containing the content of the specified file
to your CGI program. The reason why I think so is because I know
GeoCities uses this method to upload the homepage files, which is
another way to give out the file, but requires the knowledge of the
complete path name and file name. If GeoCities' file uploader works in
IExplorer, then IE is vulnerable as well.
I am not sure if this is a correct information about the bug. If it is,
please go ahead and shut my mouth and remove this message from the
newsgroup. The purpose of this message is just to make sure if I was
right. I post this message here because I trust the people around here.
I have to disclaim that there is no leak of information about this
security bug. All of the above came from my 50% imagination and 50%
creativity. (Maybe 10% extra from my IQ ...... :-) )
I think this bug is very useless because I think no webmaster would want
to get the files with the specified file name from the clients. First of
all, the client may be using a different settings, having a different
environments, etc. You cannot actually guess someone's file name that
easy.
For example, I have a file stored in the root of my third HD (the second
partition of my second hard drive), named "passwords.txt" that stores
all the userids and passwords of my currently using accounts. However,
the file could be also named "passwd.txt," "pass.txt," or even with a
different extension. Also not everyone has the third hard drive though.
Who knows? (I also have to tell that in order to prevent somebody from
using the information above and try to get this file and flood up all my
accounts, I have encrypted it using my very own encryption method, which
is only availiable for myself. Anyway.)
--Robin Hood ------------------------------------ Dreaming of a butterfly, fly into the sky. 夢想變成蝴蝶，飛上天空。