joomla security

Hi!

I have several joomla installations on Dremhost. As Joomla is releasing new security updates, im trying to follow and update as quickly as I can. I try to follow recommended security options for securing my own sites and not to harm servers in any way.

I would like to ask how to change php registering_globals for my sites. I would like to set it to OFF for best security. I tried to alter .htacess file by adding "php_flag register_globals off" but it doesnt help.

Do you have any recommendations what should i do?
thank you in advance

Sounds like you are trying to do the right thing, and I'm sure you have found that neither the PHP4 or PHP5 installation on Dreamhost follows Joomla's recommendations completely (though they differ in *what* way they confilict with Joomla recommended configuration).

You could install your own PHP, and set it up any way you want, but I think you might be just as happy, and be able to do what you want, by following the process described in this article detailing how to use your own customized php.ini, which seems to me to be a lot simpler

--rlparker

Were you able to resolve this? I'm running into this error.

I'm a newb.

I followed the instructions in the link and it worked great as a guide, but could someone please show me what code I would need in the php-update.sh file to maintain the register globals setting to Off?

Also, does anyone have a solution for the same issue with the RG_EMULATION setting in the globals.php file?

Thanks!

What version of PHP are you running? By default, on DH, register_globals=on in PHP4, and register_globals=off in PHP5. What you insert in the .sh script depends on what you are trying to set, and we need to know which version of PHP you are using to respond.

In reply to:

---

does anyone have a solution for the same issue with the RG_EMULATION setting in the globals.php file?

---

That is a setting you can edit in the joomla config - good instructions for that are available at joomla.org.

--rlparker

Thanks for your reply. I'm running php 4.4.2. I don't remember why I made that choice, but that's what I'm running on this domain.

I just installed the latest release of Joomla as well and I haven't launched it yet. Do you think I should switch to php 5?

In reply to:

---

Do you think I should switch to php 5?

---

The jury is still out for me on that one...I'm running both (on different domains) with Joomla, and I'm not sure yet which I lilke. Either way, Joomla's install reports *something* as not being optimal for security.

With PHP4, it's the register_globals (which you can address with the previously discussed php.ini customization, or just go with it as it is using the Joomla php based workaround where you "renane" the "globals" file for emulation of the "off" condition - discussed on Joomla.org and in the docs).

WIth PHP5, magic-quotes pop up, though the default is set for register_globals=off. Again, you can address this with the customized php.ini

My take on the whole issue is that , right now, some apps work "better" with php4 (some won't work "at all" with PHP5 - depending upon hopw they are coded), and some work better with PHP5 (some *require* PHP5), so it really depends upon what you are doing.

*Most* of my sites running Joomla are still running PHP4 and it seems to be working well for me, however YMMV. I guess that is a bit of a "dodgy" answer, but I don't know what else to tell you

--rlparker

Thanks again for your reply.

That's what I seem to remember about php4 and 5. I was thinking that maybe with the new joomla release, it was time to make the switch to 5, but I guess I'll just wait. Everything is working.

I took care of the globals.php. Thanks. That's one less error to bug me, and if I'm reading you correctly, that is an attempt to counter the fact that register globals is ON.

As I mentioned before, I set up the php-update shell file per the example for increasing max upload, but I don't understand the sytax enough to modify it to set register globals to off. If I did, would that effectively solve all the security risks (assuming all my components and module still function)?

Also, wouldn't the server have to be re-booted for php to fire up again?

Jeff

I'm a firm believer in the old saying, "If it's not broken, don't 'fix' it!", which is why *most* of my Joomla sites are still running PHP4.

Yes, you understood correctly about the glpbals.php tweak; it does attempt to mitigate register_globals=on. Whether or not it is more/less effective than actually setting them off is somewhat debatable - it *does* seem to plug the potential hole.

In reply to:

---

set register globals to off. If I did, would that effectively solve all the security risks (assuming all my components and module still function)?

---

I don't know that it is *ever* correct to say that *anything* "would ...effectively solve all the security risks", as anything accessable on the web risks being subjected to continual attacks. Think of it as an "arms race" - we plug an exploted bit of code, the bad guys find another attack vector, rinse, and repeat. Traditionally, the register_global=on setting has been popular with attackers, and changing it *does* eliminate that exposure, so it *is* a "good thing(tm)"

The code you need to change in the script is to add a "substitution" regular expression, similar to the one used to modify the max upload - if you will be patient with me, I'll inspect the PHP4 php.ini file for what is needed, and post a code snippet later tonight for inclusion in the script.

There won't be any need for apache to be rebooted, as (I assume!) you *are* running PHP as CGI - all of this depends upon that. It *would* need to be rebooted if you were running mod-php as an apache module. When running PHP as CGI, the php.ini is read upon execution of the php.cgi, so apache doesn't care.

--rlparker

Wow, you've explained a lot. Thank you very much for your attention and detailed responses.

I'll be more than patient, you've help a lot already. If you find the time to post that code, that would be great and far above and beyond.

I definitely am inclined to stay on top of security as much as my limited knowledge will allow. Probably because of the paranoia created by my limited knowledge!

Plus I can't stand seeing error messages everytime I log into admin. Drives me nuts! (I guess its supposed to!)

Thanks again!

Jeff

Ok, here is an edited version of the php-update.sh script referenced in the wiki article for using your own "custom" php.ini discussed earlier in this thread (will set the register_globals=off in the DH PHP4.4.2 setup):

er, uh... Doh! I obviously didn't "proof" this as well as I should have (but this proves I *did* test it, he he )-

2nd and 3rd lines should read:

CGIFILE="$HOME/yourdomain.tld/cgi-bin/php.cgi"
INIFILE="$HOME/yourdomain.tld/cgi-bin/php.ini"

Where:

"yourdomain.tld" = your domain name-

Sorry, bout that!

--rlparker

Thanks a lot for taking the time to post that. I finally got around to implementing it this morning and ran into an additional problem.

I realized that I wasn't calling the file in the .htaccess with :
AddHandler php-cgi .php
Action php-cgi /cgi-bin/php.cgi

When I add those lines to .htaccess I get a 404:

"Forbidden
You don't have permission to access /cgi-bin/php.cgi/index.php on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request."

I'm using the .htaccess file for SEF that came with JOOMLA 1.0.11 and I didn't edit it at all to get SEO/SEF functioning properly. Only change is the addition of those lines to route through php.cgi.

cgi-bin is in the webspace and cgi-bin and php.cgi permissions are set to 755. Is this the problem?

If so, what should the permissions be for the cgi-bin and the files it contains for this to function properly and still be secure?

Thanks for your help.

Jeff

No problem, I was happy to post it (I only had to write one line )

Ok. You have a couple of problems here:

1) Your use of the apache re-write rules to make the "SEF" or "pretty" urls is "borking" the path to the cgi-bin/php.cgi program. In order to correct this, you will need to add a re-write rule to account for it's presence - a guide to that process (using the DH /stats directory as an example is available on the DH wiki) Look half-way or so down the page for the "stats" fix, and modify as needed to fix for /cgi-bin/php.cgi. This can get a bit sticky, so you may want to consider abandoning the SEF urls if it gives you grief (there is considerable debate whether they actual help you with modern search engines, and they do increase server load while decreasing page display speed!). My "test" installation, where the script(s) as posted *work*, does not use the SEF option.

I have had sites with both "standard" Joomla! urls, and SEF - and have yet to see a difference in the way google handles them

2) Your permissions for the cgi-bin directory, and the php.cgi file within it should be 755.

Additionally, you might want to consider throwing an index.html or index.php file into your cgi-bin to prevent it from being casually browsed - I'm not sure it is that big a deal, but I don't see any reason to encourage inspection of the php.ini file.

Good luck!

Edited by rlparker on 09/15/06 08:33 AM (server time).

Unfortunately for me, I'm trying to rebuild a site built on a proprietary system with a joomla installation, and the current site has spectacular search engine rankings I don't want to lose or jeopardize so I want to use openSEF to help maintain them if at all possible.

Unfortunately for me as well, I'm unclear on the goal here.

The only rewrite rule required in the htaccess file to make the SEF work is this rule:
RewriteRule ^(content/|component/) index.php
Does this rule say that:
"if the URI has content/ or component/ in it to send it through root index.php"?

Sorry, I'm trying to actually learn and not just apply things here.

If that is indeed the case, what would I want the condition and rule to accomplish (Not asking you to code it, I'd actually like to try to figure that out myself).

Thanks for your time,

Jeff

Jeff,

Re-write is not one of my strong areas of knowlege, and I have not looked at the particular rules your SEF package uses (I have looked at the "built-in" Joomla! "SEF" .htaccess, but it has been awhile ).

It just looked to me from your previous post that the path to ./cgi-bin/php.cgi had been "borked" by a re-write rule (note the index.php in the error message - a typical tip-off with many of these packages that re-write has been involved).

I think the "goal" is to determine what line has to be entered into the .htaccess, and where it has to go, to *not* modify that url. It should be a good exercise to decipher that from wiki/web apache re-write information sources and inspection of the re-write code your SEF mod uses (is it a componet? - that might complicate things a bit), and determine the fix.

Good luck with it, and let me know how it goes, or if you want me to dig into it deeper .

--rlparker

Success!

Thanks rlparker.

For anyone who might be watching this thread -

I added the handler as the first item in the code - before any rewrite begins:
AddHandler php-cgi .php
Action php-cgi /cgi-bin/php.cgi

Commented out "Options FollowSymLinks"

and before the rewrite rule added the condition that the URI not include the directory cgi-bin (and is not a failed auth.) These lines are per the example in the wiki about the stats dir:

RewriteCond %{REQUEST_URI} !^/cgi-bin/(.*)$ [NC]
RewriteCond %{REQUEST_URI} !^/failed_auth.html$

The "register globals" warning is absent from the admin login.

Now, whether or not openSEF will work with this config remains to be seen. I haven't set it up yet.

Again, Thanks rlparker for the help!

Congratulations! I'm very happy to see you have it working. I worried a bit that I didn't give you much concrete direction with my last response, just pointing you , instead, in the general direction (I used your statement that *you* wanted to sort it out as my excuse to be "lazy" in my response, and I felt confident you could solve the remaining issue ).

Looking at the way you have done it (and recognizing the importance of position of entries in the .htaccess file) I don't expect the OpenSEF stuff will give you problems as long as you put the SEF rules after the conditions that preserve the location of the php.cgi.

You did a good job, and are now well qualified to write your own DH Wiki article on the whole thing (In all your spare time!)

--rlparker

Spare time, HA!

Thanks for your help and support, its exactly what I wanted. I'm sure you have as little spare time as I, and your willingness to help is above and beyond. People like you are the reason Joomla succeeds and grows! Hope our discussion is of help to the community.

Jeff