Hello,

I got in the administration panel the following warning message after upgrading from 2.3.2b to 2.3.3:

"Folder /home/XXX/public_html/XXX/xoops_lib is inside DocumentRoot!. For security considerations, you are strongly suggested to move this folder out of Document Root." and,

"Folder /home/XXX/public_html/XXX/xoops_data is inside DocumentRoot!. For security considerations, you are strongly suggested to move this folder out of Document Root."


Any idea?.

Thank you.

Bascially it is saying that if you believe that your XOOPS installation will be more secure then move these folder to folder '/home/XXX/' of your website and in mainfile.php set the following defines to match the path name:

// Physical path to the XOOPS library directory WITHOUT trailing slash
define( 'XOOPS_PATH', '/home/XXX/xoops_lib' );

// Physical path to the XOOPS datafiles (writable) directory WITHOUT trailing slash
define( 'XOOPS_VAR_PATH', '/home/XXX/xoops_data' );

This should be a personal choice and the system should not bombard you with warning notices like this, personally I am not convinced yet and many Servers configs will not allow you to have folders and files outside the document root.

Catz

I get this too now. My xoops_lib and xoops_data folders are outside my xoops_root but inside my /public_html folder. I cannot move them any further away, i.e. below /public_html as I'm on a shared server and my host won't allow it.

However, in the module's security centre I can't see the security image (this is good!) and clicking the test-link throws a page not found message (this is also good!) and is as it should be.

I will be ignoring the message as Protector is working well for me in this configuration.

I'm just wondering why Joomla or Drupal hasn't actually implemented this feature if is supposed to increase security. Sorry not convinced about this yet, and I think it is going to take a lot for me to be too.

Catz

If you are leaving the xoops_lib and xoops_data folders inside your web root directory, you should rename them with a random prefix as eg b3f6_xoops_data and change the value in mainfile.php for it.

I also have doubts on how much security is gained with this separation to inside and outside webroot.

If it is really required, then you should not allow installation on servers, that don't offer the possibility of having directories outside the webroot and executing PHP code from it.
From my understanding, was the main purpose of this outside webroot idea, that one can not enter the site on this code and could not harm the site. This makes the programming in a way easier, because the program didn't have to be hardend for various kinds of attacks. You have only one interface (the code left in the normal module directory in the webroot) and this should gard the info passed on to the outside code.

But when you allow it anyway from inside the root, then there is no possibility for this kind of 'lazy programming' and the program should be hardened to its full (Ironically demonstrated by the countless website attacks on the Protector module these days).
With that, the need to have it on a separated directory is no longer much of a security gain.

I totally agree with you on this.

If the input information is sanitized properly, for example on $_POST and $_GET call to the server, then the risk of attacks and infection are less likely.

Most of the problem lay in the methods or input filtering (or the lack of it) within each and every module. Most are very lack lustre in their approach or tend to go over board and this is where the problem lies.

Xoops itself should show good coding practices regarding this issue and lead by example and offer methods of input filtering that can be used module wide and easy to understand.

I mentioned in another post that I am not a fan of Protector, why? I believe that the core should not have to resort to the whim of a module, just for something that should be taken for granted in a CMS. Security should be a top priority at all a times for the core.

This is not a good advert for XOOPS when you tell people to install a module to provide the basis of protection. Basically, I feel this just paints a picture of a unsecured CMS.

I personally do not feel that this 'outside the root' provides any more protection and we are misusing the whole concept of this purpose. Putting modules outside the root, waste of time. Protecting unsecured data as in database username and passwords, yes.

Catz

Quote:

I totally agree. It's nice that XOOPS downloads with Protector as an optional install, but I feel the same as your do.

Security should be a CORE issue, not an addon module