Bug 21779 - Need to reject malformed href strings send by webdav client
Summary: Need to reject malformed href strings send by webdav client
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_dav (show other bugs)
Version: 2.0.47
Hardware: Other Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: PatchAvailable
: 22023 (view as bug list)
Depends on:
Reported: 2003-07-21 18:57 UTC by Roy Gibbons
Modified: 2004-11-16 19:05 UTC (History)
1 user (show)

Patch to fix this bug (rejects requests with uri fragments) (1.21 KB, patch)
2004-01-08 12:44 UTC, Amit Athavale
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Roy Gibbons 2003-07-21 18:57:30 UTC
I have encountered two problems in using the Web Folders in XP Pro to
manipulate files hosted on a webdav-enabled webserver.  The server is
apache2.0.47 with the mod_dav modules and runs under linux.

The first problem is that XP does not escape the '#' character with
a '%23' as part of the path segment.  This is a MicroSoft bug in XP as
the Win2K version seems to be better behaved.

The more serious problem is that the Apache server does not reject such
a request and but processes it with some nasty results.

In the following example, an authorized client/user has DELETE priviledges
on the webdav server.  The test file is 
called '/websites/davtest/#dav_test.html'
which is a valid filename in linux, unix and MacOS worlds but not in Windows.

When the DELETE submission is made by a Cadaver client or a Win2K client, the
following command is issued to the server
    "DELETE /websites/davtest/%23dav_test.html HTTP/1.1"
everything works as it should.

However, when a DELETE submission is made by XP Pro, the server receives
    "DELETE /websites/davtest/#23dav_test.html"
which is doesn't escape the # character.  The server accepts the command
and proceeds to delete the following
    all files in the /davtest directory
    the parent directory (davtest).

A server-based solution seems to be in order.

Comment 1 Joe Orton 2003-07-21 20:27:49 UTC
Thanks for the report - it is simple enough to reject these requests.
Comment 2 Joshua Slive 2003-07-31 15:16:31 UTC
*** Bug 22023 has been marked as a duplicate of this bug. ***
Comment 3 Amit Athavale 2003-12-30 08:42:01 UTC
I have a simple patch for this, where it checks non-null condition for
"r->parsed_uri.fragment". If its not NULL, it rejects the request with 403
response and log a message. (Currently its for DELETE and MOVE which are most
harmful in such cases)

Should I post it for review, if anybody haven't put up a fix yet :)
Comment 4 Amit Athavale 2004-01-08 12:44:22 UTC
Created attachment 9857 [details]
Patch to fix this bug (rejects requests with uri fragments)
Comment 5 Amit Athavale 2004-01-08 12:45:00 UTC
Comment 6 Erik Abele 2004-01-08 12:49:57 UTC
Ahmit, thanks for adding PatchAvailable but this belongs into the Keywords field :-)
Comment 7 Amit Athavale 2004-01-10 08:42:50 UTC
I know PatchAvailable is from keyword list. And I thought one suppose to put
that keyword after submitting patch. Isnt this right ?

Sorry this is my only second patch, so please excuse me if I have done something
terribly wrong. :)
Comment 8 Joe Orton 2004-01-10 21:22:43 UTC
Thanks for the patch and report, a version of your patch was committed to the
2.1 tree and proposed for backport to the next 2.0 release.