5 Aug
2013
5 Aug
'13
1:46 p.m.
Hi Chris,
On Mon, Aug 5, 2013 at 3:50 AM, Christian Meunier <
christian.meunier(a)magelo.com> wrote:
Hi everyone,
I have played some more with Xwiki over the week-end, and some security
issues came up, namely:
1) User own profile:
Any given user has the right to edit his own profile, so far so good when
the given user is in normal mode and the edit defaults to the inline form.
Now things get ugly when he switches to the advanced mode and suddenly can
add/update/delete objects and rights. For example he can delete his
Xwiki.users object and instantly completely break his account. He can mess
up with permissions, like granting others permissions to his profile.
Deleting this object is like deleting the profile, we have
http://jira.xwiki.org/browse/XWIKI-4391 which is also related to the rename
issue (see below).
I am using a custom authentication/sso mechanism and when I create the
user on the fly, I among other things, store the userId from our system
into the XWiki.users (added one Int property). Suddenly, the user can even
change that value...
When you need to store sensitive information in user profile, or you feel
the current behavior does not fit your needs, you may use this workaround:
- disallow users access to their own profile by adding an allow right at
document level for admins only at creation time
- create a "sheet" accessible to all users that have programming right and
allow changing their profile with the limitation you want. (XWikiUsersSheet
is a good base for that)
He can also rename his profile, effectively renaming his username... which
in a sandbox environment might not be too much of an issue, even if I find
it a little weird that users can change their identity on their owns as
often they want but when the wiki system in coupled with another system,
it's just a disaster...
Have you really try it ?, see http://jira.xwiki.org/browse/XWIKI-4290 and
be careful to http://jira.xwiki.org/browse/XWIKI-3398
2) User in advanced mode
Generally speaking, users in advanced mode seems to be able to do things
that I didnt foresee with just the edit permission :
- I could grant myself the delete permission on pretty much any page I
have edit permission and therefore deleting the pages
- I could add/update/delete pretty much any objects on any page I have
edit permission including XWiki.XWikiRights instances which seems to cover
the ACL specific to the page. I granted there myself programming rights, it
does not seem to work however the ACL is saved just fine...
This is a old discussion, see http://jira.xwiki.org/browse/XWIKI-2184.
Programming right are only evaluated at the FARM (Main wiki) level, which
means that you need edit right on XWikiPreferences of the main wiki to
alter them.
Regarding the ACL, I strongly suggest that on the
Access Rights page, when
the permission is blank (delegating upstream), the given permission should
be still visible (with a tooltip indicating from where the permission has
been inherited), maybe in parenthesis just after the checkmark box. It is
crucial that on any page/space/wiki, an admin is able to review the
effective permissions of that given page/space/wiki. Otherwise, it makes
reviewing permissions a nightmare really quickly.
This is no more an easy one to implement since the new security
authorization module is now pluggable, which means that the way inheritance
and tie rules can be interpreted with different algorithms. But you are
right, this is a must have, I used to have that for the old module through
an extradocs tab.
3) HTML macro
This is more a question on the best way to make sure the HTML macro will
filter out specific stuff to prevent script injection ? From what I
understand, the macro cannot be removed at the moment but I am not sure
what is the best way to secure it.
Regarding 1 & 2, hopefully I am overlooking something but I looked around
and could not find any thing obvious.
Using Xwiki Enterprise 5.1
See http://markmail.org/thread/otve3fzgnvjg53c4
Thanks in advance for your help !
--
Chris
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO