> > Topic

Security .htaccess and php.ini protection rules

Sep 19, 2006 / madlyr
Apr 7, 2012 / guest
 

Attached files

.htaccess.txt
4932 bytes / ID 2114 / Sep 19, 2006
Show Details
php.ini.txt
6434 bytes / ID 2115 / Sep 19, 2006
Show Details
 
Streber project management contains usually secret data. It is very important to secure server and database access as good, as possible.
Employ good admin, use good providers.

If you are brave enough, then you may secure Streber yourself, but always check your configuration and read manuals.

We provide two template files for installation with Apache 2:
  • .htaccess.txt - rename it to .htaccess
  • php.ini.txt - rename it to php.ini

12 Comments

madlyr:Please check this files in your configurations and feel free to add some comments or new directives.

9 years ago

I think those files should be added to repository and placed in every streber installation.

binder:i would be carefull with this!

9 years ago

Problem is, not everybody has/needs the same configuration. And there are some differences between Windows-PHP-Servers and LINUX-PHP-Servers.
Last, the php.ini could (or even should) differ between different versions of PHP.

Therefore we should add some comments to the manual on how to lock up strebers installation, but adding configuration files for webservers is too dangerous in my opinion. Not every admin is that good, to see the danger in replacing php.ini. Perhaps on the same server there are different applications running and for them the php.ini (or .htaccess) was edited for.

long story short: i agree with making an "streber server security HowTo", but i don't agree with making .htaccess and php.ini part of the repository or install-version.

madlyr:Reply to i would be carefull with this!

9 years ago (2. update 9 years ago)

It's not my intension to add this files in "executable" form, it would by dangerous. I propose just add them as template with txt extension.

In these files there is clause - it's for Apache style Unix like servers. We could add some Windows rules later.

php.ini - usually there is configuration, which allows addd php.ini to any directory and is activ in that directory and their subdirectories, so this php.ini template is just for this kind of placement and will be active for streber only.

I agree - different servers, different configurations, sometimes tighlty bounded with particular provider. I added in many places comments like RTFM ;-) - ask provider, admin, read manual of YOUR configuration.

Danger of giving this files to people who does not know a lot about servers and security is that it could see for them so easy.
But doing even some security enhancements is better, than not doung anything.

Streber installation is really easy and I'm shure there will be some people installing and using streber without admin and without necessary knowledge.

Security "How to's", yes.

Do we have native english persons? My english is not for public documents :-(.

tino:Reply to Reply to i would be carefull with this!

9 years ago

Do we have native english persons? My english is not for public documents :-(.

Mine too! ;-)

But 3 or more people can write it better than one, can't they?

pixtur:Good idea!

9 years ago (2. update 9 years ago)

I like the idea although in can understand binder's hestitation. We definitelly need a wiki page on hot to secure streber installations. I read some books on PHP-security but I am not really good with apache and server issues.

Attaching the .htacces file is ok. I am not sure if adding the php.ini file to the release is the right we. We should place a big link to the docu-page and provide a download-link there.

Otherwise some people will complain that installation did not work on there special server (and I don't want to take care of those problems...)

madlyr:IF we add any .htaccess or php.ini file to repository, then alays all lines should be commented

9 years ago (2. update 9 years ago)

... or we add template files with txt extension as atteched files.


pixtur:Hi madlyr

9 years ago

Could you write some documentation on the changes you made in the two files at the description of this item?

madlyr:Reply to Hi madlyr - I'll try but...

9 years ago (2. update 9 years ago)

  1. I'm not security specialist, let some people check, what's inside :_)
  2. Inside of the files there are many comments and some hyperlinks to other pages - those files should be self documented. Aren't they? If they are self documented, then what more I should add to the doc page?
  3. I'll have 2 weeks holidays break. Probably I'll have some time to add some support to streber but... I'm not shure... :-).

madlyr:php.ini has too big restrictions - upgrade is not allowed

9 years ago (2. update 9 years ago)

Warning: require_once() [function.require-once]: open_basedir restriction in effect. File(/install/../std/common.inc.php) is not within the allowed path(s): (.) in /install/install.php on line 43

Warning: require_once(/install/../std/common.inc.php) [function.require-once]: failed to open stream: Operation not permitted in /install/install.php on line 43

Fatal error: require_once() [function.require]: Failed opening required '/install/../std/common.inc.php' (include_path='.:/:/usr/pear') in /install/install.php on line 43
Try to investigate, which function is not allowed.

pixtur:Reply to php.ini has too big restrictions - upgrade is not allowed

9 years ago

ups...

So it does not support the up dir relative path? Not sure, how to fix this a installation.

madlyr:Reply to Reply to php.ini has too big restrictions - upgrade is not allowed

9 years ago

It seems, that option:

from php.ini

; open_basedir - Limit the files that can be opened by PHP to the specified directory-tree, including the file itself.
; This directive is NOT affected by whether Safe Mode is turned On or Off.
; http://us3.php.net/manual/en/features.safe-mode.php#ini.open-basedir
open_basedir = .

gives this message.
I try to check if instead "." path "/" path will sufficient for install script.

pixtur:Mind the sub directories

9 years ago

Starting at root (ie. changing all require_once-paths from "." to "/") would not work, because streber could be installed in a sub directory of the domain. It do this for most of my installations.

Maybe would could implement a function like "getStreberDirectory()" to check to a mappging for this.