next »

[nutballs]

I have a website...
it has an .htaccess in the root of the site.
Can i include rules from another file elsewhere in the directory structure, into that root htaccess file?

This is because I want to be able to change the rules for my sites via PHP. Of course I could change the permissions on the root htaccess so that it would be writeable by php, but that gives me the willies, and also complicates my deployment procedure slightly.

[perkiset]

According to this:
http://httpd.apache.org/docs-2.0/mod/core.html#include

you can't. And some threads like this:
http://www.usenet-forums.com/apache-web-server/38177-possible-include-files-htaccess.html
talk about the problems with it, and then there's some workaround like this:

http://ravenphpscripts.com/article-566--0-0.html

Essentially, it doesn't look like the Include directive can be used in .htaccess at all. But if you can Include afile.txt or *.inc or something, and hax0rs figure that part out (if they're that deep, this is trivial) then your perms are meaningless anyway. So I guess what I am saying is if the Apache instance can modify files that are included in .htaccess, you're in the same boat no matter what. So why not just change the perms for .htaccess, bend over and enjoy it?

[vsloathe]

I have a website...
it has an .htaccess in the root of the site.
Can i include rules from another file elsewhere in the directory structure, into that root htaccess file?

This is because I want to be able to change the rules for my sites via PHP. Of course I could change the permissions on the root htaccess so that it would be writeable by php, but that gives me the willies, and also complicates my deployment procedure slightly.

PHP and your web user should have different perms...Unless you have some major injection vectors in your PHP scripts, no you're not opening yourself up to any serious vulnerabilities by allowing your .htaccess to be written by PHP. Give PHP full perms to .htaccess, user can never touch PHP afaik since Apache instantiates scripts...

I could be wrong though.

[nutballs]

bah. i only want to change perms on 1 thing, not 2!!!!! This will make my manual process 2 times longer!!!

LOL

i figured as much. bleh.

So whats the real threat from an htaccess being 777?

The attacker would need to insert code into a page on the site via injection or something? I have no forms anywhere, so this is out. There is 1 vector I can think of, but they would have to know the specific url to attack it, and thats unlikely at least.

@vs, this is going to be used on an unknown system, with no configuration access. only FTP access. all interaction after the initial upload is via php webpage automations.

[perkiset]

PHP and your web user should have different perms...Unless you have some major injection vectors in your PHP scripts, no you're not opening yourself up to any serious vulnerabilities by allowing your .htaccess to be written by PHP. Give PHP full perms to .htaccess, user can never touch PHP afaik since Apache instantiates scripts...

The PHP instance is running as a child process of Apache... so it would have identical perms AFAIK... if Apache as access to write to the file then PHP can... which is where the hole comes in.

I would not make it 777, because anyone that gets access to the box can then modify it. I'd modify it so that the owner is you (your user name) and your user group includes the apache user - then make it 664 or even 660 for increased security. Then you can modify it and so can the Apache instance - but for someone to modify it other than you they'd have to BE Apache.

[nutballs]

ok, this shifts me to another question about security of directories.

I have a single directory under my root directory, which is where I am dropping a large amount of files generated by the main.php webpage that gets run. Basically, think a Search Engine Spam site, that is caching all the pages.
I cant drop them into root, because the root wont allow me to ( and thats just a bad idea anyway).
So I make a subfolder, lets call it CACHE.
It seems the only thing I can do to the subfolder to allow my webpage to write to it, is set that CACHE folder to 777. Which i know is bad, but it seems I have no other alternative? only access is via FTP and webpages.

i guess I could chown possibly? but I would need to know the apache name, which might be different on every host...

i am 99% certain that I just being a complete retard here. So enlighten me and it might help answer my htaccess questions as well.

[perkiset]

I just gave this a cursory think, but I believe you are right, given what I know of what you are trying to do. Since you don't know all the details of all the places that this highly significant and unspammy information might be hosted, you probably need to risk the 777 perms.

I'd make sure that there's nothing there that someone can read and gain access to the mothership my friend.

[nutballs]

yea. all those files are purely content. The single file that does all the coms is in the root with standard permissions. So i think I am safe there. The only concern would be a file drop into the "public" folder, which could then print out the main file in the root.

[thedarkness]

Would symbolic links and sudo maybe help here (at least with the issue in the OP)?

Cheers,
td

[vsloathe]

PHP and your web user should have different perms...Unless you have some major injection vectors in your PHP scripts, no you're not opening yourself up to any serious vulnerabilities by allowing your .htaccess to be written by PHP. Give PHP full perms to .htaccess, user can never touch PHP afaik since Apache instantiates scripts...

The PHP instance is running as a child process of Apache... so it would have identical perms AFAIK... if Apache as access to write to the file then PHP can... which is where the hole comes in.

right right, sorry. Was thinking in Windows terms. Windows has a default web user account when you install IIS that is separate from any other.

[nutballs]

yea and under IIS with ASP i know how to completely lock it down. its this apache/nix/php shit that has me all wonky. It's been long enough to where I remember things, but not enough to be helpful.