Bug 54367 - Location header in response to PUT is not %-escaped
Summary: Location header in response to PUT is not %-escaped
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_dav (show other bugs)
Version: 2.4.3
Hardware: Macintosh All
: P2 major (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: RFC
Depends on: 54611
  Show dependency tree
Reported: 2013-01-02 23:18 UTC by Wim Lewis
Modified: 2015-03-10 02:38 UTC (History)
1 user (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Wim Lewis 2013-01-02 23:18:19 UTC
The DAV PUT method returns the location of the newly created resource in the Location: header of the response (RFC2616 14.30; RFC4918 13.1). However, Apache does not quote the contents of the newly created path segments when constructing the new Location: URL (RFC3986 2.4). This means that the response can be incorrect if the underlying resource name contains octet-sequences that are significant in URLs (such as "#" or "?") or in the HTTP protocol (such as CRLF) or both (whitespace, etc).

Here's an example of a request and response using httpd 2.4.3 on an OS X machine (httpd 2.2.x has the same behavior):


PUT /pdav/test%23file HTTP/1.1
Content-Length: 8
Host: localhost



HTTP/1.1 201 Created
Date: Wed, 02 Jan 2013 22:40:00 GMT
Server: Apache/2.4.3 (Unix) OpenSSL/1.0.0j
Location: http://localhost/pdav/test#file
Content-Length: 71
Content-Type: text/html; charset=ISO-8859-1

<title>Connection closed by foreign host.

The file is correctly created in the filesystem as "test#file", but the Location: header in the response is incorrect.

PUTting to a URL such as ".../davcoll/foo%0A%0DBar:%20blahblah" may be a way to perform a response splitting attack (a la http://jeremiahgrossman.blogspot.com/2007/07/http-response-splitting-revelations.html ).
Comment 1 Timothy Wood 2013-02-26 19:10:52 UTC
See also <https://issues.apache.org/bugzilla/show_bug.cgi?id=54611>, which seems like a more general case of Location headers not doing proper URI encoding.
Comment 2 Wim Lewis 2013-04-23 00:49:41 UTC
In trunk/2.5 r1470683, Apache simply doesn't return a Location: header for PUTs any more (sigh), but the problem still happens for eg MKCOL. 

% curl -ik -X MKCOL 'http://localhost:9080/wiml/foo%0D%0Aoo'
HTTP/1.1 201 Created
Date: Tue, 23 Apr 2013 00:48:10 GMT
Server: Apache/2.5.0-dev (Unix) OpenSSL/1.0.1c
Location: http://localhost:9080/wiml/foo
Content-Length: 71
Content-Type: text/html; charset=ISO-8859-1
Comment 3 Graham Leggett 2013-04-27 19:39:50 UTC
Can you verify whether the patch applied from 54611 fixes this?
Comment 4 Ben Reser 2013-08-10 02:37:42 UTC
Yes 54611 resolved this.
Comment 5 Juergen Mertens 2015-02-20 13:49:57 UTC
The problem still exists under Debian 8 (Apache 2.4.10-8).
So I think 54611 fix was not fixing this one
Comment 6 Wim Lewis 2015-03-10 02:38:12 UTC
(In reply to Juergen Mertens from comment #5)

I just ran the 'curl' test above against a bunch of recent httpd releases and it appears to be fixed in 2.4.6 and later (working: 2.4.6, 2.4.7, 2.4.9, 2.4.10, 2.4.12, 2.4.13-dev (r1665231), and 2.5.0-dev (r1665385); not working: 2.4.2, 2.4.4); methods MKCOL and PUT; on OSX 10.9.5.

(I did notice that the bug you can see in my earlier report where the response is truncated after the "<title>" is also fixed as of 2.4.12!)

Can you give more information on what request you're sending and what you're receiving back from the server?