Hi Denis ! On 8/5/2013 19:46, Denis Gervalle wrote:
Hi Chris,
On Mon, Aug 5, 2013 at 3:50 AM, Christian Meunier < christian.meunier@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). Well like is the not the same as equals :) You end up with many orphans such as the 'page' holding the user as well as all instances, acl etc... of that page
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)
Thanks for this, it seems to be what I need. I will investigate how to do what you mentioned.
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
Yes I tried :) And this is really bad, I can touch a page, rename my username, touch another page, rince and repeat. In the end, you will have many different usernames touching many pages when in facts, there is only one user....
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.
Ya programming right cant be stolen that easily but you can do so much harm with just the edit permission... I can wipe out an entire wiki, I can deny pretty much anyone any page, create abitrary instances of objects etc... I cant even understand how people can use Xwiki for a public wiki, it seems so easy to mess up the whole thing. And preventing people being in advanced mode does not do anything because it's just a presentation mode, meaning, you can still access the various editors if you know how to modify the url...
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.
Saw something very similar to my request in Jira already. Only thing that is not captured by the jira issue is the source of the rights so you know where to look into if something is not right.
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
Thanks for link, it seems related to a more global issue regarding the script injection using xwiki syntax which hopefully should cover the HTML macro as well.
Any chance of incorporating this in the 5.1.1 release ? Also in the meantime, is there a way without touching the jar to secure the Html Macro alone ? And thanks again Denis for your reply. I must admit that I am a bit scared of using Xwiki for a public wiki. I can probably find some workarounds and hack into to secure the above mentioned points but Xwiki is a beast from code perspective and I have only scratched the surface. There is no way to tell if there are no other easy or not so easy exploitable issues... I understand that this goes for pretty much any software but I was really surprised that I could do so much harm so easily. That being said, I am not giving up and hopefully will find an acceptable solution to all those points and will review and test some more.