442010 - uploading a file with double quote is giving problems: post message injection possible?

Status: RESOLVED DUPLICATE of bug 185863

(Core :: Security, defect)

Description

[Adriaan van Kekem]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; nl-NL; rv:1.9) Gecko/2008061017 Firefox/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; nl-NL; rv:1.9) Gecko/2008061017 Firefox/3.0

when uploading a file using the <input type="file"/> control, i tried to upload a file named: '';"<XSS>=&{()}.txt
The response never comes back. When using a sniffer, i see the following shown in the package:

Content-Disposition: form-data; name="file"; filename="'';"<XSS>=&{()}.txt"

Content-Type: text/plain


So, i see that the " is not escaped!

Reproducible: Always

Steps to Reproduce:
1. upload a file named: '';"<XSS>=&{()}.txt using the html file input control
2.
3.
Actual Results:  
never comes back. Injection possible?

Expected Results:  
double quotes should be escaped and file is uploaded successfully

Comment 1

[Adriaan van Kekem]

excuse me, the response comes back, but please check if this is a vuln

Comment 2

[Brandon Sterne (:bsterne)]

I can confirm the behavior you are describing, but I am not sure it is a vulnerability so I'll let others comment with their opinion.

It is true that uploading a file with special characters can affect the value of the Content-Disposition request header.  But a user agent has full control over all the request data anyway.  We rely on servers to properly handle the requests they receive.  Am I overlooking an attack scenario that you are thinking of?

I'm thinking this might be WONTFIX, but I'll let others make that call.

Comment 3

[Wladimir Palant]

Even if the server is somehow vulnerable... If the user is uploading the file, he doesn't need the browser to send a malicious request. And websites cannot upload files, neither can they rename files to create "dangerous" names. Websites can only use XMLHttpRequest to emulate file upload (as long as same-origin policy permits it), but then they have full control over the data being sent anyway. No, I don't see an attack scenario here either.

According to RFC822, the quotation marks within the file name should be prepended with a backslash. So this is a valid bug, just not a security issue.

Comment 4

[Wladimir Palant]

The code in question is nsFSMultipartFormData::AddNameFilePair. The comment there refers to rfc2231 which suggests using URL encoding rather than escaping. So there is no way around testing what other browsers are doing.

Comment 5

[Wladimir Palant]

Managed to test in Internet Explorer with a manipulated ISO image - file names aren't encoded there either. Both Firefox and Opera reject quotes in file names on Windows (which makes sense, quotes aren't allowed on Windows).