Bug #1720

Rewrite/redirect rules and URL encoding

Added by Anonymous about 2 years ago. Updated over 1 year ago.

Status:Reopened Start:
Priority:Normal Due date:
Assigned to:- % Done:

0%
Category:mod_rewrite
Target version:1.4.x
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 module Fixed 11/26/2008
related to Bug #1827: 400 Response on any URL that countains a space character ... Fixed 11/20/2008
related to Bug #1802: url-encode/decode Fixed 10/20/2008
related to Bug #1819: mod_rewrite not working anymore after patching Fixed 11/11/2008
duplicated by Bug #1898: url.redirect matches the raw URL instead of the normalize... Duplicate 02/12/2009

Associated revisions

Revision 2448
Added by stbuehler over 1 year ago

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

History

Updated by Anonymous about 2 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 $HTTPurl condition is evaluated after the URL is parsed (so all url-encoded characters are hopefully replaced); well, unless I'm mistaken.

-- gaetan.bisson

Updated by hoffie about 2 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

Updated by stbuehler almost 2 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)

Updated by stbuehler over 1 year 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.

Updated by icy over 1 year ago

  • Target version changed from 1.4.21 to 1.4.22

Updated by stbuehler over 1 year ago

  • Target version changed from 1.4.22 to 1.4.23

Updated by stbuehler over 1 year ago

  • Target version changed from 1.4.23 to 1.4.x

Also available in: Atom