Content-Disposition bug in browsers?
Would someone who knows the relevant web specifications double-check me on this? I think I've found a bug in how Safari, Firefox, and links handle Content-Disposition in file uploads. (This is part of how a form sends a file to the server and not how the server sends a file back to the browers.). I did the following on a Mac OS X 10.6 ("Snow Leopard") machine.
If you have input or comments, or test results for your browser, let me know. I looked in Firefox's Bugzilla but found nothing about it, nor did this problem come up in general Google searches using what I think are the relevant search phrases.
My appeal to the lazyweb: If this is a bug, and you know how to submit to the relevant trackers, please do so. Figuring out each one and tracking the comments for each site is a nuisance.
I created a file named:
Evil"; name="fred(It gets more evil if the file contains a newline, but I'm not going to work though an example of that since I want something which is easy for you to create.)
I created a simple form
<html> <head><title>content-disposition test</title></head> <body> <form method="POST" action="http://localhost:8888/" enctype="multipart/form-data"> <input type="file" name="blah"> <input type="submit"> </form> </body> </html>
I used netcat to listen for incoming requests
nc -l 8888
To put it all together, I loaded the HTML page in a browser, selected the evil file, and submitted it to netcat. Quick and dirty, but it works, and it proves that nothing in the server is messing things up.
What follows is what I saw for different browsers. The results are obviously suspicious. It's easy to make the header not follow RFC 2183, which is the relevant spec. For example, remove one of the quotes.
------WebKitFormBoundaryO5rrXim+NdIE0npI Content-Disposition: form-data; name="blah"; filename="Evil"; name="fred" Content-Type: application/octet-stream
-----------------------------94839879511149195311657737442 Content-Disposition: form-data; name="blah"; filename="Evil"; name="fred" Content-Type: application/octet-stream
-----------------------------00000000000000000000000000000 Content-Disposition: form-data; name="blah"; filename="Evil"; name="fred" Content-Type: text/plain; charset=us-ascii
Opera 10.10 is the odd one out. As far as I can tell, it's safe from evil filenames. It doesn't allow me to even submit filenames containing a newline. The newline character gets removed from the name. If there's a semicolon it removes that character and all following text, so that "simple;semicolon" becomes filename="simple". (Perhaps this is VMS versioning legacy?)
If I use a double quote (") and no other non-letter characters in the filename then the result is
------------lHwjN2s9agu9VAHOJ1ChbS Content-Disposition: form-data; name="blah"; filename="default" Content-Type: application/octet-streamIn other words, Opera does not generate invalid requests here.
NewlinesI did the same tests with a newline character in the filename and found that Safari and Firefox will upload a file containing the newline, and the newline is placed in the Content-Disposition field unaltered. This lets me craft new headers for the part, including a replacement Content-Disposition header. Useful? Probably not.
None that I can think of. There are other ways to craft ill-formatted requests than using a browser, so the only possible attacks are from people who have only the ability to create a filename.
Though it would be really cool if someone proved me wrong. Is there a server out there which trusts the 'size' field and tries to preallocate 2GB of data, just because of a well-constructed upload filename? If you come up with something, let me know!
Andrew Dalke is an independent consultant focusing on software development for computational chemistry and biology. Need contract programming, help, or training? Contact me
Copyright © 2001-2013 Andrew Dalke Scientific AB