Dalke Scientific Software: More science. Less time. Products
[ previous | newer ]     /home/writings/diary/archive/2010/01/04/content_disposition_bug

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

<head><title>content-disposition test</title></head>
 <form method="POST" action="http://localhost:8888/" enctype="multipart/form-data">
  <input type="file" name="blah">
  <input type="submit">

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.

Safari 4.0.4

Content-Disposition: form-data; name="blah"; filename="Evil"; name="fred"
Content-Type: application/octet-stream

Firefox 3.5.5

Content-Disposition: form-data; name="blah"; filename="Evil"; name="fred"
Content-Type: application/octet-stream

Links 2.2

Content-Disposition: form-data; name="blah"; filename="Evil"; name="fred"
Content-Type: text/plain; charset=us-ascii

Opera 10.10

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

Content-Disposition: form-data; name="blah"; filename="default"
Content-Type: application/octet-stream
In other words, Opera does not generate invalid requests here.


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

Security Vulnerabilities

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