GIJoe,
Yes, we know this very well, and we recommend every time to place XOOPS_TRUST_PATH outside of the DocumentRoot!

If you read our Installations Guidelines, as well as our "A Guide to Make your XOOPS Installation even more secure" it's stated there again and again.

However, some of our users don't have the ability to do it due to their host. Of course, they can change the host. Or others might not read it, because they never read instructions.

We received a report from Digital Security Research Group, and we acted on that. I think, it's a responsible thing to do and I think it's better to prevent a problem and help a user, than tell the user "You're stupid and it's your fault that you placed XOOPS_TRUST_PATH inside the DocumentRoot".

This the same way why we have airbags and safety belts in the car. As a car manufacturer you could say: "Everybody knows that they should drive carefully, and if they don't know how to drive, it's not our problem". But because accidents happen, that's why we install the extra safety measures, and thus save lives.

You can claim that ImpressCMS knows better about security, but they have their share of security breaches and vulnerabilities as well:

http://www.securityfocus.com/archive/1/498734
http://community.impresscms.org/modules/smartsection/item.php?itemid=261

so I don't think that your statement is fair.

You're the best Security expert in the XOOPS community, and everybody in the community respect you for it, and it would be nice if you could share your know-how with us and help us to support our users, instead of shooting at us. We never had any other intentions than to help our users!

We believe that as a Open Source project we have the responsibility to help our users and look after them. And that's exactly what we've done here. Yes, if their XOOPS_TRUST_PATH is outside of DocumentRoot, they don't have to worry. But if we would do today a survey, we would find out that there are many users who still didn't place it outside.

And for this reason we believed that it's "Better safe than sorry" and that's why we've provided this patch. If we save even one user from being hacked, then it was worth it for us!

Quote:
I have to agree with Mamba on this point.

Even with ImpressCMS it's possible to have the XOOPS_TRUST_PATH inside the DocumentRoot. ImpressCMS can create it outside DocumentRoot automatically (if allowed by host), but a user can enter a path inside DocumentRoot manually.

Hi All,

Honestly, I was expecting such discussion ^^
and only wonder how long it will take to be public.

Xoops.org is not Xoops2 but Xoops Sphere
DJ and Mamba are doing the same as Herko
and the guys of Impresscms did some time ago
- patchwork and misinforming community to
capitalize the project for own benefit.

Both Xoops Sphere and Impresscms are forks
of original Xoops2 and both are not secure.
Too bad that you just get it now !

XOOPS Cube is the logical suite of Xoops2
Minahito rewrite the code from scratch.
XC founder is also the one of Xoops2.

To be fair to the community, from the front page of xoops.org
we should have the original logo of Xoops2 and a short information
explaining the events: "Since the founder left in 2005 Xoops has multiple forks"
followed by the logos of XC Legacy, Xoops Sphere and Impresscms

Nobody is perfect. But we can try to be honest and do better.

Have Fun

To prevent misunderstandings, I've written the original post in Japanese.
If you feel some questions, translate/read the original.

First, I write the dead line I cannot compromise.
The privacy of XOOPS_TRUST_PATH is notr a target to effeort but a spec

Certainly, some hosting services disallow directory outside of DocumentRoot.(A)
And some hosting services ignores .htaccess just under XOOPS_TRUST_PATH.(B)

But, you have to understand this thesis must be false.
"Existence of servers with (A) AND (B) makes a WebApplications which need private area vulnerable".

If it is true, almost all WebApplications might be vulnerable.
eg) Cake, Ethna and almost all frame works need private folders.


And you should learn the news entry itself is logicaly wrong.
Because, it is far from a problem of Protector but a problem with missing cares about XOOPS_TRUST_PATH.

If you have to alert, the target must be installer or documents.


And the patch for Protector you made looks stupid.
Why do you insert "SANITIZE"?

Though this stupid code using heavy preg_replace() is out of debate of course, the code like
cannot be granted for me.

Because inserting such a code will be a falseness for skilled developpers can understand the necessity of private area and agree with XOOPS_TRUST_PATH.

If Protector is corrupted by such codes, the other D3 modules should be corrupted also.
And inside XOOPS_TRUST_PATH, there are a lot of libraries, caches, uploaded files, logs, and sessions. All of them are out of assuiming direct accesses then they should be placed private area.
Do you have any ideas for (A) AND (B) servers?
I can even proof XOOPS cannot be secure with "(A) AND (B) server".


And I don't know servers with (A) AND (B) at all.
If it exists really, all developpers just say "cancel the server right now".


I've just released Protector-3.22 with a checker XOOPS_TRUST_PATH is private or public.
And I rejected mamba's wonderful patches.

This is my final answer.

Gijoe,
As a user of xoops what I would like to know is since my webhost does not allow creating folder outside rootfolder, what according to you should i do to fix this issue.

hi nitinshah12

Quote:Just "create"?
If you mean create/read, it might be the open_basedir restriction.

Then you have to make XOOPS_TRUST_PATH inside your "rootfolder" (DocumentRoot) then put .htaccess "DENY FROM ALL".

You can check whether the .htaccess works fine via Protector's "Security Advisory".

Normally, you will get 403 error.
This means OK.
If your host disallows (not ignores) .htaccess, then you will get 500 error (Internal Server Error).
It is OK also.

Quote:
Thanks a lot