Project

General

Profile

Bug #1720

Rewrite/redirect rules and URL encoding

Added by Anonymous about 10 years ago. Updated 5 days ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
mod_rewrite
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Missing in 1.5.x:

Description

Dear lighty community,

I am using lighty to serve a wiki; to have nice urls, i use the following in my lighttpd.conf:


url.rewrite-once = ( "^/wiki/(.*)$" => "/wiki/awki.cgi/$1" )

and so i was hoping that everything going through /wiki/ would be interpreted by the script 'awki.cgi'. However, if I url-encode a part of the url, the above rewrite rule does not apply: if I ask my browser to access /wik%69/, lighty does not execute the script and gives me a
listing of files in that directory!

Is there a way to avoid that?
I asked in the forum last week but, as I had no answer, I decided to open a ticket; I apologize if this is unapropriate.

-- gaetan.bisson


Related issues

Related to Bug #1832: lighty doesn't quote spaces in urls in proxy moduleFixed2008-11-26

Actions
Related to Bug #1827: 400 Response on any URL that countains a space character (ASCII 20)Fixed2008-11-20

Actions
Related to Bug #1819: mod_rewrite not working anymore after patchingFixed2008-11-11

Actions
Related to Bug #1802: url-encode/decodeFixed2008-10-20

Actions
Related to Bug #911: Need for URL encoding in mod_redirect and possibly mod_rewriteFixed

Actions
Has duplicate Bug #1898: url.redirect matches the raw URL instead of the normalized URLDuplicate2009-02-12

Actions

Associated revisions

Revision 55479281 (diff)
Added by stbuehler about 10 years ago

Decode url before matching in mod_rewrite (#1720)

git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@2278 152afb58-edef-0310-8abb-c4023f1b3aa9

Revision 345462a4 (diff)
Added by stbuehler almost 10 years ago

Use decoded url for matching in mod_redirect (#1720)

git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@2309 152afb58-edef-0310-8abb-c4023f1b3aa9

Revision 2448 (diff)
Added by stbuehler over 9 years ago

Revert url decoding+simplifying before matching of mod_rewrite/mod_redirect (#1720)

Revision 3eb7902e (diff)
Added by gstrauss 5 days ago

[core] server.http-parseopts URL normalization opt (fixes #1720)

server.http-parseopts = ( ... ) URL normalization options

Note: not applied to CONNECT method

Note: In a future release, URL normalization likely enabled by default
(normalize URL, reject control chars, remove . and .. path segments)
To prepare for this change, lighttpd.conf configurations should
explicitly select desired behavior by enabling or disabling:
server.http-parseopts = ( "url-normalize" => "enable", ... )
server.http-parseopts = ( "url-normalize" => "disable" )

x-ref:
"lighttpd ... compares URIs to patterns in the (1) url.redirect and (2) url.rewrite configuration settings before performing URL decoding, which might allow remote attackers to bypass intended access restrictions, and obtain sensitive information or possibly modify data."
https://www.cvedetails.com/cve/CVE-2008-4359/
"Rewrite/redirect rules and URL encoding"
https://redmine.lighttpd.net/issues/1720

History

#1

Updated by Anonymous about 10 years ago

I've come up with the following workaround:


url.rewrite-once = ( "^/wiki/(.*)$" => "/wiki/awki.cgi/$1" )

$HTTP["url"] =~ "^/wiki" {
  $HTTP["url"] !~ "^/wiki/awki.cgi/" {
    url.access-deny = ("")
  }
}

It works because the $HTTP["url"] condition is evaluated after the URL is parsed (so all url-encoded characters are hopefully replaced); well, unless I'm mistaken.

-- gaetan.bisson

#2

Updated by hoffie about 10 years ago

  • Status changed from New to Fixed
  • Resolution set to fixed

Should be fixed in r2278. Just for reference, in your case you consider this a security issue since it allows for unwanted disclosure of information.
Not sure if we are going to handle it as one, but I guess it should be at least noted.

stbuehler committed the fix and didn't close this ticket as trac was broken, so I'm doing that now. All kudos to him in any case. :p

#3

Updated by stbuehler almost 10 years ago

mod_redirect had similar problems:

Summary for now:
  • 1.4.x: fixed in r2278 (rewrite) and r2309 (redirect)
  • trunk: fixed in r2307 (rewrite) and r2310 (redirect)
#4

Updated by stbuehler over 9 years ago

  • Status changed from Fixed to Reopened
  • Target version changed from 1.4.20 to 1.4.21
  • Patch available set to No

Patch(es) reverted in 1.4.x (r2362) - too many regressions came up.
See commit message for more details.

We are not sure yet what to do, maybe we won't fix this at all.

#5

Updated by icy over 9 years ago

  • Target version changed from 1.4.21 to 1.4.22
#6

Updated by stbuehler over 9 years ago

  • Target version changed from 1.4.22 to 1.4.23
#7

Updated by stbuehler over 9 years ago

  • Target version changed from 1.4.23 to 1.4.x
#8

Updated by gstrauss over 2 years ago

  • Related to Bug #911: Need for URL encoding in mod_redirect and possibly mod_rewrite added
#9

Updated by gstrauss over 2 years ago

  • Status changed from Reopened to Need Feedback

con->request.uri is url-encoded and includes URI path and query-string
con->uri.path has been url-decoded and path has been simplified/normalized
con->uri.query is url-encoded

mod_rewrite operates on con->request.uri, meaning that there might be ways to subvert rewrite rules by url-encoding parts of it, since most rewrite rules will be against a normalized path and query string.

Perhaps the solution is to normalize the url-encoding of con->request.uri for rewrite rules, but there might still be complexities involved in virtual paths containing '.' or '..', PATH_INFO, whether or not to decode %2F ('/') in path and/or query-string parts, ...

I propose normalizing the url-encoding, including decoding %2F to '/'. Decoding %2F to '/' potentially loses some info in PATH_INFO and query string, but is a more secure default giving most people what they would expect. Maybe we could additionally provide a config switch to skip decode of %2F for the regex input.

Note: I am suggesting decoding con->request.uri temporarily for the regex match. If we were to normalize url-encoding at the start of the request, I would suggest leaving %2F url-encoded at that point of normalization. We might still decode %2F for regex matching, unless a new config flag were set.

(While discussing url-decoding here, please see url-encoding discussion of regex back-reference matches in #911)

#10

Updated by gstrauss 5 days ago

  • Status changed from Need Feedback to Fixed
  • % Done changed from 0 to 100
#11

Updated by gstrauss 5 days ago

See server.http-parseopts documentation for how to enable URL normalization (recommended)

For backwards compatibility, URL normalization is not enabled by default, though that may change in a future release.

Also available in: Atom