Summary: | mod_perl config leaves main script dir indexable | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mikael Hedberg <stary> |
Component: | New packages | Assignee: | Gentoo Perl team <perl> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | web-apps |
Priority: | High | Keywords: | SECURITY |
Version: | 1.2 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Mikael Hedberg
2002-07-28 16:05:11 UTC
Can you do a test for me? Add the /*.pl back (as that was to register the extention) and add this section before the perl module configs: <Location /perl> Options -Indexes </Location> Lemme know the results. Sorry for the delay, been on a vacation. That works... I've now tested a section like this: <Location /cgi-perl> Options -Indexes </Location> #set Apache::PerlRun Mode for /cgi-perl Alias <Location /cgi-perl/*.pl> SetHandler perl-script PerlHandler Apache::PerlRun Options ExecCGI </Location> (all inside the <IfModule> section), which seems to work. I can't get an index listing, and the scripts still execute. The same should work for the /perl section, though I haven't tested it. *Important note*: I still consider this bad security practice, since it leaves some files readable. AFAIK the recommended option is to use the /perl and /cgi-perl directory matches. Consider the following: script access.pl uses module accessed.pm. loading access.pl will run the script as expected. Loading accessed.pm, will give the source of that document, however - not a good thing. Using <Location /perl> (or similar) will run the module however, which does nothing but load the module, return true, and the browser will most probably show some error like "The document contains no data" (Mozilla does). If an attacker can guess the name of a module used or somehow obtain this information, that'd give a platform for attack. This is an even more minor issue than the original one, but is there a good reason to only allow .pl files as scripts in /perl? This appears to be fixed in commonapache.conf. |