Quotes in uploaded filenames are not parsed correctly.

When you handle a multipart/form-data post with libapreq quotes in
filenames are mishandled. For example, a post that includes:

Content-Disposition: form-data; name="foo"; filename="break"here.jpg"

Will result in a filename of just 'break'.

To reproduce, set up a test following the snippets below, and upload a
file named 'break"here.jpg' to the resulting form.

I'm using Apache/2.2.9 (Ubuntu) DAV/2 SVN/1.5.1 mod_ssl/2.2.9
OpenSSL/0.9.8g mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0

In your error log you will see just 'break'.

---httpd.conf---

use lib qw(/home/mcrawfor/);

PerlModule QuoteParse

SetHandler perl-script
PerlResponseHandler QuoteParse


---QuoteParse.pm---
package QuoteParse;

use strict;
use warnings;

use Apache2::RequestRec ();
use Apache2::Request ();

use Apache2::Const -compile => qw(OK);

sub handler {
my $r = shift;
my $req = Apache2::Request->new($r);

warn $req->param('foo');

$r->content_type('text/html');
print "

Re: Quotes in uploaded filenames are not parsed correctly.

Miles Crawford wrote:
> When you handle a multipart/form-data post with libapreq quotes in
> filenames are mishandled. For example, a post that includes:
>
> Content-Disposition: form-data; name="foo"; filename="break"here.jpg"

Isn't that a malformed header? I would think that the internal '"'
should be escaped for it to be properly represent that filename.
Assuming that's the case, the rest of the behavior that you describe is
what I'd expect.

Adam

Re: Quotes in uploaded filenames are not parsed correctly.

I agree it looks bogus, but safari and firefox send the header in that
format. Not sure about IE since Windows does not allow files with a "
in the name.

I looked over the Content-Disposition header RFC but it does not seem
to address escaping directly.

Either way, it seems that this format is a "browser fact of life"

-miles

On Fri, Jan 2, 2009 at 4:44 PM, Adam Prime wrote:
> Miles Crawford wrote:
>>
>> When you handle a multipart/form-data post with libapreq quotes in
>> filenames are mishandled. For example, a post that includes:
>>
>> Content-Disposition: form-data; name="foo"; filename="break"here.jpg"
>
> Isn't that a malformed header? I would think that the internal '"' should
> be escaped for it to be properly represent that filename. Assuming that's
> the case, the rest of the behavior that you describe is what I'd expect.
>
> Adam
>

Re: Quotes in uploaded filenames are not parsed correctly.

Miles Crawford wrote:
> I agree it looks bogus, but safari and firefox send the header in that
> format. Not sure about IE since Windows does not allow files with a "
> in the name.
>
> I looked over the Content-Disposition header RFC but it does not seem
> to address escaping directly.
>
> Either way, it seems that this format is a "browser fact of life"

I suggested this in IRC, but never saw a reply. Perhaps it's because
you're using $r->param for a input type=file? I'd check to see what
$upload->filename gives you when you use Apache2::Upload to handle the
file upload instead.

Adam

Re: Quotes in uploaded filenames are not parsed correctly.

That's actually what my production code does (where I originally found
this error) and I was trying to simplify the testcase down for the bug
report. ;)

If you set up the test exactly as described before, but use the
following Perl code instead, you still see just 'break' in the error
log:


package QuoteParse;

use strict;
use warnings;

use Apache2::RequestRec ();
use Apache2::Request ();
use Apache2::Upload();

use Apache2::Const -compile => qw(OK);

sub handler {
my $r = shift;
my $req = Apache2::Request->new($r);

if( my $upload = $req->upload('foo') ){
warn $upload->filename();
}

$r->content_type('text/html');
print "

Re: Quotes in uploaded filenames are not parsed correctly.

Miles Crawford wrote:
> That's actually what my production code does (where I originally found
> this error) and I was trying to simplify the testcase down for the bug
> report. ;)

Theoretically I guess you should report the bug to
apreq-dev@httpd.apache.org. It does seem wrong, but to me it mostly
seems like it's the browsers that are behaving badly.

Adam