Is there any security risk with having the following folders...
can you provide more information behind your question?
Obfuscation (i.e. security through obscurity) is one technique for making things more secure.
It has been suggested by many to make your web host directories and filenames obscure so people (i.e. hackers) cannot easily find things.
I'm not sure if there is any value doing that with the directories I mentioned, though?! :-/
Well yes, think about this if I planted a sign saying "I have $500k in my sock drawer, I keep my back door unlocked, and work 2pm to midnight" my house would get attention. So yes naming directories js, et el, it may attract attention. But once a bad person is in your site (ftp) you cannot do anything. but if you want random visitors to not see /js/ contents while surfing, you can chmod the directory to 700 or 740. I forget which is better, I think 740 is directories with multiple ftp account access.
You can call your css folder anything you like, but in your html code you'll have to link to it anyway (the same with js and images), so it's not much of a security measure.
You can't secure what is sent to the browser.
That was my thinking.
But, then, if I make each directory "read-only", at least people can't go poking around, right?
(It's one thing to let a user know that a picture came from the "images" directory, and quite another to let them have access to the entire directory and its contents, right?)
You can prevent that by putting an empty index.html file in each folder.
Or by making it read-only, right? (Linux)
Read-only would still let them see everything. You probably want to go in your Apache configuration or your .htaccess file and disable Indexes. This (or adding an empty index.html file) will make it so when I go to /someDir I won't see a list of files in there.
Most hosts have Indexes off in their Apache configuration.
If they don't, simply put this in your .htaccess:
To be the most secure, I really want read-only AND hidden (i.e. not indexed), right?
To be most secure you want them not indexed and read only "for the world".
In linux and mac you have 3 different permissions for a file. One is for the owner, one is for the group the file belongs to and the last one is for "everyone else" (also known as "the world").
It's okay if the user and/or the group have write access, but "the world" should most definitely not have write access.
Oh, and don't fall for the trap of putting directories you don't want people to see in the robots.txt. That's the equivalent of hanging a note on your wall stating where thieves are not allowed to look (" thieves, do not go through my sock drawer! ")
Okay, so in Linux hosting, I should make all directories 1.) Read-only to the world, 2.) Not Indexed, and 3.) Don't rely on robot.txt to provide any security.
Thanks for the tips!
Just so everyone one knows. Linux permissions have nothing to do with anything. Those permissions do not effect users connecting and viewing files via Apache. You could stop Apache from being able to read them but that is about the only affect they will have on web users. You could set the permssions of everything to "777" (read-write-execute for everyone) and it won't make a difference. Won't be less or more secure. Well unless you setup Apache with the ability to modify files via HTTP routines like PUT and DELETE. Apache is not setup with that ability out of the box, however.
Again Linux permissions are only for the local system, not for users connecting through Apache.
Actually, that's not quite true logic_earth.
Apache is actually assigned to a specific user and group (just like any other user) and bases it's permissions off of that. By default I believe it's www-data:www-data. You can configure this in a specific file (I think it's usually the apache.conf file, I believe... I always forget =p).
Apache can then access files which it has permission to access just like any other user. So, if it's the owner or in the group, it uses those permissions. If it's not, it uses the "other" permission value.
A good example of this happens in Wordpress. With Wordpress, if it has the permissions, it'll automatically change the files directly when you do an auto-update of something. If it doesn't have the permissions, it'll ask for FTP information and use that to update the files.
Also, you keep saying "indexed", so I want to clarify, just in case.
"Indexed" usually refers to what search engines do (they index files in their databases).
"Indexes" is an Apache configuration. If it is enabled and you go to a directory that doesn't have a default document (index.html, etc), it'll show you a list of all files in that folder. If Indexes is off, it will give a 404 Not Found or 403 Forbidden error (depending on your settings, usually 404).
If you add a default document (index.html, etc) to every folder, it basically has the same effect because they'll get this page instead of a 404/403. This is usually a preferred method because you can do something like redirect them to your home page from this file, instead of just giving them an error.
It's best to do both.
Also, be careful with setting your directories to "read-only" (which would be 4). If they have a PHP file in them, it won't work if it's set to 4. You need to make sure it's set to 5 (read and execute). You'll probably want to set all of your files to either 0775 or 0755. The first gives only the owner the ability to edit. The second gives the owner and anyone in the group the ability to edit.
Just for your (or someone else that comes along to this post) reference:
chmod values are in the order of owner-group-other (a.k.a. "the world").
The possible values are:
0 - No access
1 - Execute only [Rarely Used]
2 - Write Only [Rarely Used]
4 - Read Only
3 - Execute/Write Only [Rarely used]
5 - Execute/Read Only
6 - Write/Read Only
7 - Execute/Write/Read
(The values are binary flags, just in case that means anything to anyone reading this.
Apache only gives read-only permissions regardless to those user connecting it. They only way for a web user to alter/add/delete files or data is via a server-side script or add support for HTTP PUT and DELETE. No matter what you set the permissions to, as long as Apache can read them that is all that matters. A web user would only ever have read-only permissions even if you set it as 777. That permissions only affects the local system, not those connecting to the HTTP server known as Apache.
So what I said is true.
Okay, yes, I did mistake what you meant, a bit. However you should still worry about it for security if you have a server-side script that does do something to the local system because you could use the script to do something malicious if it isn't secure.
If you're talking about fully static HTML pages, then yes, you are 100% correct. As long as Apache has read access it can be read it, but it's always read-only.
css, images, js - not a lot you can do.
As for includes, I wouldn't put this inside the web root anyway, if it's what I think it is (for server side includes etc) - this should live outside the publicly accessible web root.
I've never understood where people got that even allowing directory access is a 'risk' -- but then I truly believe that if you don't want people to have access to static files...
WHAT THE DEVIL IS IT ON THE SERVER IN THE FIRST PLACE FOR!?!
ESPECIALLY when it comes to files like images, CSS, javscripts... The end user ALWAYS has access to them anyways.
Changing what the directory it's in is names isn't going to change that... especially since I can just hit "information" in opera to pull up links to CSS and Scripts, or 'document size' in the FF web developer toolbar to pull up EVERY link (assuming FF 3.5- since that's STILL broken 3.6+, making FF useless for me since that's about the only tool in it I use on a regular basis)
You're going to have to path to it in the markup or CSS ANYWAYS, so all they have to do is hit "view source" and if they can READ, they can find it. Goofy/obscure names are just going to make your job harder, and have ZERO impact on security.
Though... if you need an entire directory JUST for CSS, there's probably something wrong with your CSS... and you're probably uptree and/or root linking for the images making your directory structure more complex than need be.
next page →