UBB.Developers Forums UBB.threads 6 Bug Reports 5.1.5 uploaded filename bug (may also exist w/perl

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

The PHP version has a function in it that will check to make sure it is a valid file. So, the file would actually need to be a valid file. Next, as long as you are using the allowfile option to only allow certain filetypes, then this should safeguard against that as well on either version.

The file can BE a valid file.. let's say I send up a very nice GIF but give it a filename of javascript:evilstuff()" ALT="foo.gif The "extension" when it looks at it, is .gif, right, fine, that's good. Is it really a GIF that I got uploaded? It is? Right, fine, that's good. That's one part of the problem, the other part is that if the filename includes spaces, e.g. Pic of my dog.jpg Then, the spaces do not get URL-encoded, because, to LINK to a file like that, in an HREF, you need to do: Pic%20of%20my%20dog.jpg HREF objects can't have spaces in them, because it must contain a URL, and a URL cannot contain whitespace (or any other special character for that matter). That's what tipped me off to this is that I saw a page on another person's w3t board where the image filename had spaces and netscape users couldn't download it because their browser (obeying the standard) was very confused. The issue with spaces is mildly easy because people expect it, but if I was to send a filename of "Derek?Susan?.jpg", that would cause some serious issues for some browsers, I reckon, even though it is a perfectly legitimate FILENAME. D

Good point. I guess the easiest way would be to just strip out any special characters or spaces from the filenames. That should cover pretty much everything, right?

yeah... thinking in perl terms, I'd just take out anything in $filename that wasn't in [\w._-] ... if you've got something else in the filename, just replace it with either (nul) or with "_" or something to signify the missing character. D