Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Various sensitive directories are browsable if web server directory browsing is enabled #2758

Closed
TheWitness opened this issue Jun 24, 2019 · 8 comments
Labels
bug Undesired behaviour resolved A fixed issue
Milestone

Comments

@TheWitness
Copy link
Member

Describe the bug
The Cacti log directory does not include an index.php. Therefore, the directory can be directly browsed using a browser. This is a bad practice.

To Reproduce
Steps to reproduce the behavior:

  1. Login to Cacti
  2. Point the browser to cacti/log
  3. View the data in the log directory on the server

Expected behavior
Directory browsing should be blocked.

@bmfmancini
Copy link
Member

Thats a good find however I think another issue is that you could browse directly to
xyz.com/cacti/log/cacti.log and view the whole log file in the browser
perhaps this could be better locked down?

@bmfmancini
Copy link
Member

bmfmancini commented Jun 24, 2019

May I suggest

<Files .htaccess>
Order allow,deny
Deny from all

<FilesMatch ".(log)$">
Order allow,deny
Deny from all

As the default .htaccess file

@bmfmancini
Copy link
Member

just submitted a pull request with these changes I have tested them on 1.2.4 and apache2
this would require AllowOverride All in the apache config

@ddb4github
Copy link
Contributor

BTW, lots of dir missed index.php, e.g. include/vendor/phpgettext/, include/vendor/phpseclib/, .....

@cigamit
Copy link
Member

cigamit commented Jun 24, 2019

Instead of blindly adding htaccess files everywhere, a better idea would be to create a Security Document that informs everyone which directories they should be blocking at a server level. Maybe with examples for the major HTTP engines out there.

htaccess files do absolutely nothing for those people not using Apache (Nginx, IIS, Lighttpd, etc...). Even with Apache, it is better to block these in your conf instead.

From https://cwiki.apache.org/confluence/display/HTTPD/Htaccess

The use of .htaccess files is discouraged as they can have a detrimental effect on server performance. Only use them when necessary.

If we really have to go down this route, then I recommend 1 htaccess file in the root instead of 1 in every directory we want to block.

cigamit added a commit that referenced this issue Jun 25, 2019
@cigamit cigamit added bug Undesired behaviour resolved A fixed issue labels Jun 25, 2019
@netniV
Copy link
Member

netniV commented Jun 27, 2019

I would agree with the idea to document the security recommendations. Currently, we have:

log/.htaccess
cli/.htaccess
rra/.htaccess
cache/spikekill/.htaccess
cache/mibcache/.htaccess
cache/realtime/.htaccess
cache/boost/.htaccess

As @cigamit pointed out, these will do nothing for nginx or IIS so if they aren't already in the https://github.com/cacti/documentation repo, they should be.

cigamit added a commit that referenced this issue Jun 27, 2019
@cigamit
Copy link
Member

cigamit commented Jun 27, 2019

Okay, I've added the redirects in include/vendor. The rest can be covered in a documentation bug for now.

@netniV
Copy link
Member

netniV commented Jun 27, 2019

So, I used Cigamits post above to create a new documentation issue. For now, this part will be marked as resolved.

@netniV netniV closed this as completed Jun 27, 2019
@netniV netniV changed the title Lack of index.php in Cacti's log directory enable remote browse of the directory Various sensitive directories are browsable if web server directory browsing is enabled Jul 14, 2019
@github-actions github-actions bot locked and limited conversation to collaborators Jun 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Undesired behaviour resolved A fixed issue
Projects
None yet
Development

No branches or pull requests

5 participants