If you upload a file containing spaces, like:
Foo Version 2.0.tar.gz
w3t is "trusting" the filename it gets from the browser, which can be problematic if the filename contains spaces, slashes, colons, high-ascii, etc. none of which are permitted in the file portion of the URL (or which can very much confuse the issue... e.g., my mac can have files with "/" in the name, but on a unix machine that will mean something completely different. Just as a unix machine can have "" in the filename, but that will torque things up well on an NT server)
It seems to me that the file-accept code needs to get the filename from the form input, and then "safe it" (first, making sure the filename itself isn't a hook into javascript, etc., then URL-encoding any non-compliant stuff.)
for example, what would happen if the filename you received was:
foo" onClick=document.alert(document.cookies) BORDER="1
Seems that if that was accepted as a filename, then it would -- after being mated to the head and tail of the HREF from the w3t script -- form a real HREF that would, when clicked on, spill the cookies to a javascript alert (except that my javascript syntax is wrong because i haven't used it in years)... How to send those cookies elsewhere in javascript is left as an exercise for the reader.
D
