Can you elaborate on why you see indices as a threat? If you put a file under your webroot, you should assume it is publicly available (barring .htaccess or that sort of thing), so I don't see a great deal of security benefit from turning off indices.
–
D.W.Jul 31 '12 at 5:59

When you scan the server with most of the vuln scanners out there, you will see in the report: "Risk associated with an attacker discovering a Directory Listing depend upon what type of directory is discovered and what files are contained in it. The primary threat is that hidden files such as data files, source code, applications in dev will be visible to potential attacker. In addition to accessing files containing sensitive information, other risks include attacker utilizing the info discovered in that directory to perform other types of attack".
–
mnmncJul 31 '12 at 7:21

2

OK, thanks for elaborating. My conclusion: directory indices are not a serious threat. A general comment: Vulnerability scanners are stupid. Just because a vulnerability scanner claims something is a threat, doesn't mean it is actually a serious threat. You have to learn to read the outputs of those scans with a skeptical eye.
–
D.W.Jul 31 '12 at 7:36

It's usually described as a medium threat by the scanners. Yes - the scanners are pretty stupid as they cannot reason based on what they see in the indexof. But it's our job to identify if this is an actual threat or a false positive. Attacker collects data from bits and pieces along the way. We may potentially help him enabling the indices, or we may disable the indices - "just to be safe". Can you tell me why do you think indices are useful for average user? I mean actual average user - not IT literate.
–
mnmncJul 31 '12 at 7:42

Whether it's useful to the average user is a separate question of whether it's a security threat. My view: it's not a serious security threat. If there is no need for an index, then turning them off is reasonable as a better-safe-than-sorry measure, but I'm not sure we should be saying that indexes are a security threat or a vulnerability: that might make it sound more dangerous than it really is. If indexes are useful to the website owner (as appears to be the case with this question), it's reasonable to turn them on. See my answer for elaboration. That's just my take, others may disagree.
–
D.W.Jul 31 '12 at 18:23

Originally the idea behind the web was to provide a catalog of useful information; each file in a public directory contains some piece of information, and an index is automatically generated to make that information accessible. The whole reason why your default file is traditionally called index.html is because that file theoretically is supposed to be an index, just like the auto-generated one, but perhaps formatted differently.

If the directory contains nothing but publicly-accessible files (such as pictures, PDFs, HTML files, or what-have-you), then the auto-generated index is no less secure than an equivalent manually-generated index.

But if instead you have some sort of web app -- and particularly one written in PHP or ASP or ASP.NET or a similar language where the application files are stored inside the document root mixed in with the media -- then the auto-generated index may provide links to files that you didn't intend to make public. This is even more true if you have "include" files in there as well. And in that case, this automatic index could make it easier to find files that could lead to a vulnerability.

Note that the index itself is not a vulnerability and is not a security risk in itself. Instead, it could assist in locating and exploiting some other security vulnerability on the site. If you have no such vulnerabilities, then the index does not add any risk on its own.

Furthermore, all of the practices that could make a directory index dangerous are, themselves, categorically bad practices, and are not made safe simply by removing the index directive.

This specifically includes placing server-side code files in your document root. To be safe, you should have ONE file (index.php) inside your document root, and ALL the other files outside. Your index.php file should contain nothing but bootstrap code that loads and executes your webapp, while the webapp handles all URL routing independent of your filesystem structure. Aside from that, your document root should only contain static files that are safe for anyone to view.

If you want to allow browsing files in that manner, why not setup a file server? You used the tag web-application, which differs from just providing some PDFs. In that case I would go with what tyler1 stated.

Are you suggesting SAMBA / NetBEUI / NetBIOS over Internet? I dont think this is particularly a good idea.
–
mnmncJul 26 '12 at 13:18

Why would a server to provide files to you over the internet not be a good idea. Dropbox, google drive,... not sure what you mean as not a good idea. Yea sure you can say "cloud storage" but essential you are reaching files over the internet as with a file server.
–
stlsaintJul 27 '12 at 0:17

I would be very concern about security of such a service. samba / NetBeui was not particularly designed to be used over the Internet. File services should be provided for the network hidden behind the NAT and firewall. Dropbox and alike are totaly different idea. It is not using any of mentioned protocols -> en.wikipedia.org/wiki/Dropbox_%28service%29
–
mnmncJul 27 '12 at 6:10

No. This does not present any security vulnerabilities. It is a perfectly reasonable thing to do.

Do make sure that every file in that directory is in fact intended to be made publicly available. Don't put any file you want to keep secret under that directory. (But then, ordinarily you should avoid putting such files anywhere under your web root, so I'm probably not telling you anything overly new.)

While there is likely no problem in showing the list of files in that particular location, the main risk you run into is when the code passes the folder name as a parameter, possibly from user input.

At that point, you have to be very careful to filter the folder parameter to only allow approved folders, or a user could specify other folders like /etc or your web app source code and read all sorts of sensitive data like passwords.