Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

I have a directory on my ISP's web server, I don't want users to see files inside that directory, so I have a index.html file in it to redirect user to my main page, I wonder someone could still write a program and use http or other protocols to list the files in it ? I know they can't use browsers to access those files.

Edit [ More specific ] :

The dir look like this :

index.html [ redirect to main page ]
1z3n67xzs.dus
s737er.pds
rijvnjdfjndf.oef
Dir_Deeper_Hidden_1 [ a directory ]
Dir_Deeper_Hidden_2 [ a directory ]

These files and directories are not mentioned in anywhere else, I'm the only one who knows the names of these files and directories, can users still list them ?

share|improve this question
add comment

migrated from stackoverflow.com Jul 14 '11 at 1:46

This question came from our site for professional and enthusiast programmers.

3 Answers

up vote 5 down vote accepted

Actually, if the web server and/or permissions aren't set up right, they can access the files with a web browser. Anyone who knows (or guesses) the names of files within the directory can get them just fine. index.html only hides the directory listing, and the same thing can be done by disabling directory indexes for that directory.

In a .htaccess file, you can do it like

Options -Indexes

If you don't want random strangers to access the directory or the files in it, you can tell the web server to require authentication for that directory.

AuthType basic
AuthName Private
AuthUserFile /path/to/htpasswd
Require valid-user

and set up an 'htpasswd' file that contains the names and passwords of users you want to allow.

For IIS, it's a little easier if you have admin access to the server (and particularly if FrontPage Server Extensions are installed). Just set the permissions on the directory.

share|improve this answer
    
Unless you're forcing HTTPS, you should really use digest authentication. It's just as easy to set up and much more secure than sending passwords in plain-text over an unencrypted connection. –  Lèse majesté Feb 26 '12 at 20:05
    
I just remember some compatibility issue with digest authentication, and never learned about all the various options that go along with it. Apparently, though, the setup isn't that different. Looks like it just amounts to replacing "basic" with "digest", and adding an AuthDigestDomain. Also looks like most of the other stuff is not implemented yet. :P –  cHao Feb 26 '12 at 20:28
    
That's pretty much it. That and you have to use htdigest to generate the password file instead of htpasswd. But otherwise there really aren't any differences in implementation. And the compatibility problems were probably from very very old browsers that only supported HTTP 1.0. –  Lèse majesté Feb 26 '12 at 20:33
add comment

You certainly could access the files in a web browser or other HTTP client, either by brute-force attack on filenames, or, more likely, because the URL of one of the pages has leaked out. This typically happens if a link or image on one of the pages leads to another server, passing a referrer URL. All it takes is one server (or proxy) log to make the URL public and it will be easily discoverable by Google.

URL obscurity is not a good way to protect sensitive information. If the pages are meant to be viewed only by authorised users, deploy an authentication scheme such as HTTP Basic Authentication (eg via .htaccess); if they are not meant to be viewable through the web at all, keep them in a directory outside of the web root.

share|improve this answer
add comment

No. They are not safe. The server should be configured not to list the contents of a folder via http, and should only serve files with certain extensions. HTML, asp, aspx, png etc are okay, but, say, .config is not. If your provider isn't configuring the server in this way, find a new one.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.