2

There are times when directories are left publicly accessible intentionally. What's the harm here? How is this even considered a flaw?

I know that it can disclose sensitive info from the server then why are they sometimes intentionally left publicly accessible?

  • This isn't a good question for this site. If people claim they have a good reason to deviate from best practice, you should ask them what led them to that decision, rather than random people off the internet. – Lie Ryan Jun 15 '18 at 3:31
  • @Lie Ryan: disagree. Best Practice should be based on sound reason, not opinion. Sadly recommend practices are all to often flouted without justification. – symcbean Jun 15 '18 at 11:14
  • I don't disagree that best practice would have good reason, and questions about best practice would have been ok. But questions about deviations from best practice are generally case by case. Without knowing the original reason to deviate from best practice, and with so little context given here, it's impossible to evaluate whether or not such deviation is justified. It's essentially become a list question, which is a poor format for a QA site. – Lie Ryan Jun 15 '18 at 14:14
2

Because it makes sense to do it when it makes sense to do it. The usual practice is to disable it and only enable it for directories you specifically want it to in order to avoid accidental information disclosure but of course... not having a directory listing doesn't prevent them from accessing your /admin/err.log or whatever because you can still guess file paths. You might for example have a directory where you store pictures of your employees with random file names to avoid people from scrapping your website (but still allow them to access single pictures when necessary). If you don't disable directory listing (and have no index.html usually) an attacker could easily get a list of all employees that way.

| improve this answer | |
1

Few things are always good or always bad. It depends on context.

If the files in your directory are just static files that you want your users to be able to download, then turning on directory listing is fine. This is quite common for e.g. software distributions, where you might have different folders for different versions, operative systems, etc. Letting the user browse around in these is not harmful - it's probably the use case you built the site for.

On the other hand, if you are hosting something more complex like a dynamic web applicaiton, turning on directory listing is probably a bad idea. You risk exposing the programs internal structure or even worse all sorts of config or log files containing sensitive data. It's easy to accidentally leak your DB password this way.

Another aspect to take into consideration is that the directory listing will probably telegraph what webserver you are using, and maybe even what version. You may or may not care about this.

So, the bottom line is this: Make sure directory listing is off, unless you know what you are doing, you are only serving non sensitive static files, and you have a specific use case that needs it to be on.

| improve this answer | |
0

(I presume we are talking about HTTP access here - flagging it as web-application confuses the issue somewhat)

If something is done is intentionally, its not a flaw. As others have said, it may have inadvertently exposed information you do not want to be made public, or may do so in future. A decision to make or not a directory available is based on a simple set of questions:

  1. Does legitimate use of the service require the facility (in this case a publicly readable directory)
  2. Does the facility enhance the use of the service
  3. Is it required for the support/maintenance of the service?
  4. Does it enhance the support/maintenance of the service?
  5. What are the costs/risks of changing the behaviour? e.g. installing a web based file manager might remove the need for mod_autoindex, but is time consuming to install/configure and significantly increases the attack surface

In addition to the risk of exposing confidential information, it also raises the risk of publishing details of your application code to search engines. Which means that someone who has an exploit for some application merely needs to turn to Google to find vulnerable hosts searching by filename and filesize. Even if you never have information of any value on your site, an exploitable, internet connected machine is a valuable asset to any attacker.

Conversely someone specifically targetting your server might be able to cross reference the exposed filenames/filesizes against known vulnerabilities without probing your site for vulnerabilities (and hence tripping protection mechanisms).

In Apache and nginx, switching this functionality on and off (or applying it selectively) is very low cost. Hence the practice is merely an extension to the principle of least privilege.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.