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

See http://markmail.org/thread/otve3fzgnvjg53c4

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.

https://github.com/xwiki/xwiki-platform/pull/122

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.

Hello Vincent, I understand what you are saying and I totally agree however there is a need to have a fine line as to where everyone can go and can do. And for sure, the line is different for a public wiki or an enterprise wiki. With Mediawiki or Dokuwiki, I cannot delete a page which is not mine and I cannot change the permissions of a page which is not mine. Right now I can do both with Xwiki which imho is not an expected behaviour for a public wiki. Of course one can argue than you can always edit and leave the page blank but at least the history will be here and the page can be rollbacked. And it's not as easy as just clicking a delete button. When you delete a page in xwiki, it will delete everything associated with that page meaning all the rights, the instances and the classes. Is there an history for all of thoses ? I am kinda under the impression that only the content of the page is versionned and can be rollbacked... And it just does not make sense that anyone who can edit, can touch the rights at all and to some degree, same goes for the instances. And again, unless I am wrong, you cant rollback those... In order to secure things I want to hook into the XWikiRightServiceImpl, but it does not seem to be used. Could you point me to the service that is responsible for the authorizations/rights ? Also if you could explain me how I can secure the HtmlMacro without touching its jar that would be very helpful. From looking around and the discussion, I was under the impression that it was possible but I just dont know how... Thanks ! -- Chris On 8/6/2013 16:30, Vincent Massol wrote:

Hi Christian,

On Aug 6, 2013, at 5:07 AM, Christian Meunier <christian.meunier@magelo.com> wrote:

[snip]

...

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. [snip]

This is exactly what a wiki is for: an easy site to modify content. The reasons wikis are powerful is precisely because of that: low barrier to contribution and ability to easily modify content.

The promise of a wiki is that it's easy to rollback changes (easier than for someone to deface it).

You can find a lot of instances of public wikis on the web that work quite well. Just to cite 3 public instances using 3 different wiki engines: * wikipedia (mediawiki) * xwiki.org (xwiki) * https://www.dokuwiki.org/ (for ex go to https://www.dokuwiki.org/features and click the edit pencil) (dokuwiki)

Now obviously, for this to work you need community members that watch for vandalism (http://en.wikipedia.org/wiki/Wikipedia:Vandalism).

But when you use a wiki, you want collaboration and this is small price to pay in exchange. Obviously if your vandalism rate is higher than your contribution rate you should ask yourself questions and take some actions! ;) But in general it's good to keep things open till there are problems since closing things down will slow down contributions.

Now XWiki is more than a wiki and we need to address all use cases. We currently have a contributor working 100% of his time on security aspects. He's made a lot of pull requests recently; some have been applied and others are being reviewed. To answer one of your point, we've identified the need to require some permissions for adding/modifying some xobjects.

Thanks -Vincent

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On Aug 6, 2013, at 1:40 PM, Vincent Massol <vincent@massol.net> wrote:

On Aug 6, 2013, at 1:12 PM, Christian Meunier <christian.meunier@magelo.com> wrote:

...

Hello Vincent,

I understand what you are saying and I totally agree however there is a need to have a fine line as to where everyone can go and can do. And for sure, the line is different for a public wiki or an enterprise wiki.

With Mediawiki or Dokuwiki, I cannot delete a page which is not mine and I cannot change the permissions of a page which is not mine. Right now I can do both with Xwiki which imho is not an expected behaviour for a public wiki.

You need delete right in xwiki to be able to delete a page too so that's not an issue.

BTW if you want to verify this you can register a user on http://playground.xwiki.org/ and you'll see you won't have delete rights… Thanks -Vincent

...

Of course one can argue than you can always edit and leave the page blank but at least the history will be here and the page can be rollbacked. And it's not as easy as just clicking a delete button.

When you delete a page in xwiki, it will delete everything associated with that page meaning all the rights, the instances and the classes. Is there an history for all of thoses ? I am kinda under the impression that only the content of the page is versionned and can be rollbacked...

And it just does not make sense that anyone who can edit, can touch the rights at all and to some degree, same goes for the instances. And again, unless I am wrong, you cant rollback those…

You can rollback anything.

...

In order to secure things I want to hook into the XWikiRightServiceImpl, but it does not seem to be used.

There's a new security module since 5.x: See http://extensions.xwiki.org/xwiki/bin/view/Extension/Security+Module

...

Could you point me to the service that is responsible for the authorizations/rights ?

Also if you could explain me how I can secure the HtmlMacro without touching its jar that would be very helpful. From looking around and the discussion, I was under the impression that it was possible but I just dont know how…

This is a work in progress. There's a pull request from Thomas Delafosse about this but it's not been applied yet AFAIK.

BTW if you wish to report security issues and vulnerabilities the best is to use the security mailing list and not the user or dev list since they're public, see http://dev.xwiki.org/xwiki/bin/view/Community/MailingLists#HPrivateMailingLi...

Thanks -Vincent

...

Thanks !

-- Chris On 8/6/2013 16:30, Vincent Massol wrote:

...

Hi Christian,

On Aug 6, 2013, at 5:07 AM, Christian Meunier <christian.meunier@magelo.com> wrote:

[snip]

...

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. [snip]

This is exactly what a wiki is for: an easy site to modify content. The reasons wikis are powerful is precisely because of that: low barrier to contribution and ability to easily modify content.

The promise of a wiki is that it's easy to rollback changes (easier than for someone to deface it).

You can find a lot of instances of public wikis on the web that work quite well. Just to cite 3 public instances using 3 different wiki engines: * wikipedia (mediawiki) * xwiki.org (xwiki) * https://www.dokuwiki.org/ (for ex go to https://www.dokuwiki.org/features and click the edit pencil) (dokuwiki)

Now obviously, for this to work you need community members that watch for vandalism (http://en.wikipedia.org/wiki/Wikipedia:Vandalism).

But when you use a wiki, you want collaboration and this is small price to pay in exchange. Obviously if your vandalism rate is higher than your contribution rate you should ask yourself questions and take some actions! ;) But in general it's good to keep things open till there are problems since closing things down will slow down contributions.

Now XWiki is more than a wiki and we need to address all use cases. We currently have a contributor working 100% of his time on security aspects. He's made a lot of pull requests recently; some have been applied and others are being reviewed. To answer one of your point, we've identified the need to require some permissions for adding/modifying some xobjects.

Thanks -Vincent

On 08/06/2013 08:22 AM, Sergiu Dumitriu wrote:

On 08/06/2013 07:40 AM, Vincent Massol wrote:

...

On Aug 6, 2013, at 1:12 PM, Christian Meunier <christian.meunier@magelo.com> wrote:

...

Hello Vincent,

I understand what you are saying and I totally agree however there is a need to have a fine line as to where everyone can go and can do. And for sure, the line is different for a public wiki or an enterprise wiki.

With Mediawiki or Dokuwiki, I cannot delete a page which is not mine and I cannot change the permissions of a page which is not mine. Right now I can do both with Xwiki which imho is not an expected behaviour for a public wiki.

You need delete right in xwiki to be able to delete a page too so that's not an issue.

Yes, but a user that can edit a page can give himself the delete right.

But IIRC we recently disabled delete rights at the page level, so a user would need to have access to the space configuration to actually gain delete rights.

...

...

Of course one can argue than you can always edit and leave the page blank but at least the history will be here and the page can be rollbacked. And it's not as easy as just clicking a delete button.

When you delete a page in xwiki, it will delete everything associated with that page meaning all the rights, the instances and the classes. Is there an history for all of thoses ? I am kinda under the impression that only the content of the page is versionned and can be rollbacked...

And it just does not make sense that anyone who can edit, can touch the rights at all and to some degree, same goes for the instances. And again, unless I am wrong, you cant rollback those…

You can rollback anything.

...

In order to secure things I want to hook into the XWikiRightServiceImpl, but it does not seem to be used.

There's a new security module since 5.x: See http://extensions.xwiki.org/xwiki/bin/view/Extension/Security+Module

...

Could you point me to the service that is responsible for the authorizations/rights ?

Also if you could explain me how I can secure the HtmlMacro without touching its jar that would be very helpful. From looking around and the discussion, I was under the impression that it was possible but I just dont know how…

This is a work in progress. There's a pull request from Thomas Delafosse about this but it's not been applied yet AFAIK.

BTW if you wish to report security issues and vulnerabilities the best is to use the security mailing list and not the user or dev list since they're public, see http://dev.xwiki.org/xwiki/bin/view/Community/MailingLists#HPrivateMailingLi...

Thanks -Vincent

...

Thanks !

-- Chris On 8/6/2013 16:30, Vincent Massol wrote:

...

Hi Christian,

On Aug 6, 2013, at 5:07 AM, Christian Meunier <christian.meunier@magelo.com> wrote:

[snip]

...

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. [snip]

This is exactly what a wiki is for: an easy site to modify content. The reasons wikis are powerful is precisely because of that: low barrier to contribution and ability to easily modify content.

The promise of a wiki is that it's easy to rollback changes (easier than for someone to deface it).

You can find a lot of instances of public wikis on the web that work quite well. Just to cite 3 public instances using 3 different wiki engines: * wikipedia (mediawiki) * xwiki.org (xwiki) * https://www.dokuwiki.org/ (for ex go to https://www.dokuwiki.org/features and click the edit pencil) (dokuwiki)

Now obviously, for this to work you need community members that watch for vandalism (http://en.wikipedia.org/wiki/Wikipedia:Vandalism).

But when you use a wiki, you want collaboration and this is small price to pay in exchange. Obviously if your vandalism rate is higher than your contribution rate you should ask yourself questions and take some actions! ;) But in general it's good to keep things open till there are problems since closing things down will slow down contributions.

Now XWiki is more than a wiki and we need to address all use cases. We currently have a contributor working 100% of his time on security aspects. He's made a lot of pull requests recently; some have been applied and others are being reviewed. To answer one of your point, we've identified the need to require some permissions for adding/modifying some xobjects.

Thanks -Vincent

-- Sergiu Dumitriu http://purl.org/net/sergiu/

Hi Sergiu, Are you really sure about that ? I am not aware of that change, I do not see it in sources, so, I suspect this is just a rumor. Very curious to see the commit about it, and the vote as well. Christian, if you are willing to apply a patch for that, this one is easy: http://pastebin.com/w1dt3me2 Regards, On Tue, Aug 6, 2013 at 2:47 PM, Christian Meunier < christian.meunier@magelo.com> wrote:

Hi Sergiu,

Any chance you can link the github commit of that ? Would very much like to have a look and integrate it myself... Thanks in advance !

On 8/6/2013 20:23, Sergiu Dumitriu wrote:

...

but a user that can edit a page can give himself the delete right. But IIRC we recently disabled delete rights at the page level, so a user would need to have access to the space configuration to actually gain delete rights.

______________________________**_________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>

-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

Hi Denis, Thanks for the snippet ! The drawback with that solution is that the creator of the page cannot delete his page anymore. So I end up creating another Right called 'advedit' and then I just patched a single method in org.xwiki.security.authorization.internal.XWikiCachingRightService :

https://gist.github.com/Tlvenn/6165646

And now works like a charm and any advanced edit is secured and out of reach of regular users. Regards, On 8/6/2013 21:09, Denis Gervalle wrote:

Hi Sergiu,

Are you really sure about that ? I am not aware of that change, I do not see it in sources, so, I suspect this is just a rumor. Very curious to see the commit about it, and the vote as well.

Christian, if you are willing to apply a patch for that, this one is easy: http://pastebin.com/w1dt3me2

Regards,

On Tue, Aug 6, 2013 at 2:47 PM, Christian Meunier < christian.meunier@magelo.com> wrote:

...

Hi Sergiu,

Any chance you can link the github commit of that ? Would very much like to have a look and integrate it myself... Thanks in advance !

On 8/6/2013 20:23, Sergiu Dumitriu wrote:

...

but a user that can edit a page can give himself the delete right. But IIRC we recently disabled delete rights at the page level, so a user would need to have access to the space configuration to actually gain delete rights.

______________________________**_________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>

On 8/6/2013 23:54, Denis Gervalle wrote:

Sure, just be careful that the XWikiCachingRightService is a temporary bridge that will be progressively deprecated in favor of the AuthorizationManager and an upcoming "ContextualAuthorizationManager". Moreover, the mapping between action and right will be moved to the Action module, once available.

By the way, you may provide your new right without patching anything by calling AuthorizationManager#register, and you can change XWikiCachingRightService from xwiki.cfg using xwiki.authentication.rightsclass=...

Ha great, thanks for the tip ! I have to patch Right unfortunately since I want both Admin and Program Right to inherit my AdvEdit right (impliedRight). Might be interesting to have some kind of inversion of control when one right can push itself as implied right to others.

On Wed, Aug 7, 2013 at 2:49 PM, Denis Gervalle <dgl@softec.lu> wrote:

On Wed, Aug 7, 2013 at 12:44 PM, Christian Meunier < christian.meunier@magelo.com> wrote:

...

On 8/6/2013 23:54, Denis Gervalle wrote:

...

Sure, just be careful that the XWikiCachingRightService is a temporary bridge that will be progressively deprecated in favor of the AuthorizationManager and an upcoming "**ContextualAuthorizationManager** ". Moreover, the mapping between action and right will be moved to the Action module, once available.

By the way, you may provide your new right without patching anything by calling AuthorizationManager#register, and you can change XWikiCachingRightService from xwiki.cfg using xwiki.authentication.**rightsclass=...

Ha great, thanks for the tip !

I have to patch Right unfortunately since I want both Admin and Program Right to inherit my AdvEdit right (impliedRight). Might be interesting to have some kind of inversion of control when one right can push itself as implied right to others.

Very interesting proposal, I am curious to know what others think about that inversion of control. The worse will be that it needs another API breakage, but I see it as a good improvement... grrr... I should have though about it before !

I agree it's a needed change.

...

______________________________**_________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>

-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

Hi Vincent, Can you point me to the PR from Thomas ? I have already integrated the XSS PR but it does not secure the Html Macro out of the box right now. Looks like a @Named("securehtml") component who be needed in order to provide a secured Html macro, has anyone started working on it already ? Thanks !

...

...

Also if you could explain me how I can secure the HtmlMacro without touching its jar that would be very helpful. From looking around and the discussion, I was under the impression that it was possible but I just dont know how…

This is a work in progress. There's a pull request from Thomas Delafosse about this but it's not been applied yet AFAIK.

...

Thanks -Vincent

Hello Christian, It's nice to see that you are interested in XWiki security :) As for the secure html macro I've been working on, there's no PR made for it (the issue was that it was breaking a lot of panels that were using unsafe html code thanks to this macro), but I would try to create a branch on github with the corresponding code when I have time. To sum up what I've done, I just used a library called JSoup which allows to easily deal with whitelists (see http://jsoup.org/apidocs/org/jsoup/safety/Whitelist.html for example). And as I wanted to let users with Programming Rights use the HTML macro without restriction, I had to put my "secure" html macro in xwiki-platform instead of xwiki-rendering, so that my whitelist check is not used against these users. BTW let me know if there any issue you get with my other XSS PR and don't hesitate to contact me if you have questions or suggestions about what I've done there (or for other security matters !). As Vincent said, I'm in holidays right now, so I could be slow to answer, but I won't forget you ;). Thanks ! Thomas On Wed, Aug 7, 2013 at 5:32 PM, Vincent Massol <vincent@massol.net> wrote:

On Aug 7, 2013, at 5:30 PM, Christian Meunier < christian.meunier@magelo.com> wrote:

...

Hi Vincent,

Can you point me to the PR from Thomas ? I have already integrated the XSS PR but it does not secure the Html Macro out of the box right now. Looks like a @Named("securehtml") component who be needed in order to provide a secured Html macro, has anyone started working on it already ?

I'll let ThomasD answer this since I'm not sure where it is… (Note: Thomas might be on Holidays ATM)

AFAIR he's using tagsoup as a htmlcleaner filter (configurable through xwiki configuration files).

Thanks -Vincent

...

Thanks !

...

...

...

Also if you could explain me how I can secure the HtmlMacro without

touching its jar that would be very helpful. From looking around and the discussion, I was under the impression that it was possible but I just dont know how… This is a work in progress. There's a pull request from Thomas Delafosse about this but it's not been applied yet AFAIK.

...

Thanks -Vincent

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Thomas or someone else, any hint on how i can retrieve who is the owner of the current macro block ? I injected the Execution component in order to get the ExecutionContext in the hope that it should help me figure out who is the owner of the macro block and if he has programming right or not. I cant seem to find a way to know the author... Thanks in advance for your help ! -- Chris On 8/10/2013 10:19, Christian Meunier wrote:

Hi Thomas,

Thanks for taking the time during your holiday to reply me back !

Ya if you can create a branch or even simply create a gist with your secure html macro, it would be great. Otherwise in the meantime, I will come up with a simpler version (no check against users with programing rights) that leverage Jsoup.Whitelist...

For now, the only security PR i merged on my own is your wiki syntax XSS one and I did put a comment for a little bug I found (Tlvenn is my pseudo on github) :

...

https://github.com/xwiki/xwiki-rendering/pull/6#discussion-diff-5632662

Thanks again and enjoy your holidays !

On 8/10/2013 05:10, Thomas Delafosse wrote:

...

Hello Christian,

It's nice to see that you are interested in XWiki security :) As for the secure html macro I've been working on, there's no PR made for it (the issue was that it was breaking a lot of panels that were using unsafe html code thanks to this macro), but I would try to create a branch on github with the corresponding code when I have time. To sum up what I've done, I just used a library called JSoup which allows to easily deal with whitelists (see http://jsoup.org/apidocs/org/jsoup/safety/Whitelist.html for example). And as I wanted to let users with Programming Rights use the HTML macro without restriction, I had to put my "secure" html macro in xwiki-platform instead of xwiki-rendering, so that my whitelist check is not used against these users. BTW let me know if there any issue you get with my other XSS PR and don't hesitate to contact me if you have questions or suggestions about what I've done there (or for other security matters !). As Vincent said, I'm in holidays right now, so I could be slow to answer, but I won't forget you ;).

Thanks !

Thomas

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

There is no macro block author / owner directly associated afaik. What you have is a "source" meta data on the XDOM (that contains the macro block) which specifies the document the content (including the macro) comes from. The author of the source document is considered the author of the macro, but in practice this is not true most of the time as you can edit a document without touching the macros. Vincent and ThomasM know best how macro blocks work but unfortunately both are in holidays right now. On the same topic, if I understood correctly, ThomasD handled the macro author / owner "issue" in his branch for signed scripts (to fix programming rights issues) by adding a signature object to the document containing the (script) macro. The signature includes the last author and he makes sure the signature is updated whenever the (script) macro content is edited. Hope this helps, Marius On Tue, Aug 13, 2013 at 2:07 PM, Christian Meunier <christian.meunier@magelo.com> wrote:

Little bump in case a dev can help me out on this one.

Thanks in advance !

On 8/11/2013 02:19, Christian Meunier wrote:

...

Thomas or someone else, any hint on how i can retrieve who is the owner of the current macro block ? I injected the Execution component in order to get the ExecutionContext in the hope that it should help me figure out who is the owner of the macro block and if he has programming right or not. I cant seem to find a way to know the author...

Thanks in advance for your help !

-- Chris

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi Christian, On Sep 17, 2013, at 8:16 AM, Christian Meunier <christian.meunier@magelo.com> wrote:

Hi Thomas,

Hope you had good holidays !

I was wondering if you could give me an update on the work you started for the html macro ? Btw, have you noticed my comment on https://github.com/xwiki/xwiki-rendering/pull/6#discussion_r5632662 ?

Also, question for the devs, I see that the 5.2 is near the corner and yet many of Thomas's security PRs are still pending..

Several have been applied (by Marius).

Shouldnt those security PRs be a priority ? Is there a roadmap/target for those ?

FYI ThomasD was working lately on signed scripts which will fix a lot of current potential security issues. This is a big piece of work. I said "was" because Thomas is now going abroad in the context of his school studies and will probably be less available. The good news is that Denis Gervalle has agreed to carry on his work and more generally to focus on security issues for the coming 3 months at least. So you should see progress in this area :) Thanks -Vincent

Thanks !

-- Chris

On 8/10/2013 05:10, Thomas Delafosse wrote:

...

Hello Christian,

It's nice to see that you are interested in XWiki security :) As for the secure html macro I've been working on, there's no PR made for it (the issue was that it was breaking a lot of panels that were using unsafe html code thanks to this macro), but I would try to create a branch on github with the corresponding code when I have time. To sum up what I've done, I just used a library called JSoup which allows to easily deal with whitelists (see http://jsoup.org/apidocs/org/jsoup/safety/Whitelist.html for example). And as I wanted to let users with Programming Rights use the HTML macro without restriction, I had to put my "secure" html macro in xwiki-platform instead of xwiki-rendering, so that my whitelist check is not used against these users. BTW let me know if there any issue you get with my other XSS PR and don't hesitate to contact me if you have questions or suggestions about what I've done there (or for other security matters !). As Vincent said, I'm in holidays right now, so I could be slow to answer, but I won't forget you ;).

Thanks !

Thomas

On Sep 17, 2013, at 10:26 AM, Christian Meunier <christian.meunier@magelo.com> wrote:

Thanks Vincent for the heads up !

Any chance Marius or some other dev can have a look the XSS in wiki Syntax PR ?

...

https://github.com/xwiki/xwiki-rendering/pull/6#discussion_r5632662

I have tested it, beside the bug I have spotted, it worked just fine for me.

Would be nice to include this one in 5.2 because right now, it just too trivial to do XSS injection with the wiki syntax..

It seems too large a patch to make it in 5.2 now (we're reaching RC1) but it could go in 5.3M1. Thanks -Vincent

Thanks !

-- Chris

On 9/17/2013 14:43, Vincent Massol wrote:

...

Hi Christian,

On Sep 17, 2013, at 8:16 AM, Christian Meunier <christian.meunier@magelo.com> wrote:

...

Hi Thomas,

Hope you had good holidays !

I was wondering if you could give me an update on the work you started for the html macro ? Btw, have you noticed my comment on https://github.com/xwiki/xwiki-rendering/pull/6#discussion_r5632662 ?

Also, question for the devs, I see that the 5.2 is near the corner and yet many of Thomas's security PRs are still pending.. Several have been applied (by Marius).

...

Shouldnt those security PRs be a priority ? Is there a roadmap/target for those ? FYI ThomasD was working lately on signed scripts which will fix a lot of current potential security issues. This is a big piece of work. I said "was" because Thomas is now going abroad in the context of his school studies and will probably be less available. The good news is that Denis Gervalle has agreed to carry on his work and more generally to focus on security issues for the coming 3 months at least.

So you should see progress in this area :)

Thanks -Vincent

...

Thanks !

-- Chris

On 8/10/2013 05:10, Thomas Delafosse wrote:

...

Hello Christian,

It's nice to see that you are interested in XWiki security :) As for the secure html macro I've been working on, there's no PR made for it (the issue was that it was breaking a lot of panels that were using unsafe html code thanks to this macro), but I would try to create a branch on github with the corresponding code when I have time. To sum up what I've done, I just used a library called JSoup which allows to easily deal with whitelists (see http://jsoup.org/apidocs/org/jsoup/safety/Whitelist.html for example). And as I wanted to let users with Programming Rights use the HTML macro without restriction, I had to put my "secure" html macro in xwiki-platform instead of xwiki-rendering, so that my whitelist check is not used against these users. BTW let me know if there any issue you get with my other XSS PR and don't hesitate to contact me if you have questions or suggestions about what I've done there (or for other security matters !). As Vincent said, I'm in holidays right now, so I could be slow to answer, but I won't forget you ;).

Thanks !

Thomas

On Aug 6, 2013, at 1:12 PM, Christian Meunier <christian.meunier@magelo.com> wrote:

Hello Vincent,

I understand what you are saying and I totally agree however there is a need to have a fine line as to where everyone can go and can do. And for sure, the line is different for a public wiki or an enterprise wiki.

With Mediawiki or Dokuwiki, I cannot delete a page which is not mine and I cannot change the permissions of a page which is not mine. Right now I can do both with Xwiki which imho is not an expected behaviour for a public wiki.

Of course one can argue than you can always edit and leave the page blank but at least the history will be here and the page can be rollbacked. And it's not as easy as just clicking a delete button.

When you delete a page in xwiki, it will delete everything associated with that page meaning all the rights, the instances and the classes. Is there an history for all of thoses ?

Yes, if a standard user deletes a page he isn't be allowed to remove it from the trash and thus it can be put back. You need to be admin or have the undelete right to restore a page. See http://platform.xwiki.org/xwiki/bin/view/Features/DocumentLifecycle#HDelete Thanks -Vincent

I am kinda under the impression that only the content of the page is versionned and can be rollbacked...

And it just does not make sense that anyone who can edit, can touch the rights at all and to some degree, same goes for the instances. And again, unless I am wrong, you cant rollback those...

In order to secure things I want to hook into the XWikiRightServiceImpl, but it does not seem to be used. Could you point me to the service that is responsible for the authorizations/rights ?

Also if you could explain me how I can secure the HtmlMacro without touching its jar that would be very helpful. From looking around and the discussion, I was under the impression that it was possible but I just dont know how...

Thanks !

-- Chris On 8/6/2013 16:30, Vincent Massol wrote:

...

Hi Christian,

On Aug 6, 2013, at 5:07 AM, Christian Meunier <christian.meunier@magelo.com> wrote:

[snip]

...

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. [snip]

This is exactly what a wiki is for: an easy site to modify content. The reasons wikis are powerful is precisely because of that: low barrier to contribution and ability to easily modify content.

The promise of a wiki is that it's easy to rollback changes (easier than for someone to deface it).

You can find a lot of instances of public wikis on the web that work quite well. Just to cite 3 public instances using 3 different wiki engines: * wikipedia (mediawiki) * xwiki.org (xwiki) * https://www.dokuwiki.org/ (for ex go to https://www.dokuwiki.org/features and click the edit pencil) (dokuwiki)

Now obviously, for this to work you need community members that watch for vandalism (http://en.wikipedia.org/wiki/Wikipedia:Vandalism).

But when you use a wiki, you want collaboration and this is small price to pay in exchange. Obviously if your vandalism rate is higher than your contribution rate you should ask yourself questions and take some actions! ;) But in general it's good to keep things open till there are problems since closing things down will slow down contributions.

Now XWiki is more than a wiki and we need to address all use cases. We currently have a contributor working 100% of his time on security aspects. He's made a lot of pull requests recently; some have been applied and others are being reviewed. To answer one of your point, we've identified the need to require some permissions for adding/modifying some xobjects.

Thanks -Vincent

Hi Valdis, see my comments below and thanks for your contribution to this topic ! On 8/6/2013 03:29, Valdis Vītoliņš wrote:

We could argue, that if user has learned to use advanced edit mode, then he probably knows what he is doing (because actually he can only mess his own profile only without hurting others). Well that's not true, using advanced edit mode, user can mess up any page that he can edit up to deleting it... And for a wiki, that means pretty much any page.

I am trying to setup a public wiki and this scenario is a nightmare, because if it's possible, it's bound to happen. I dont want to wake up one day with the whole wiki being in the recycle bin... And there is a lot of other way to mess up the wiki once the user is in advanced edit mode...

But for more strict case, I had simple workaround, by setting user profile to read-only, when profile is created by external authentication: ... BaseObject userObj = userDoc.getObject("XWiki.XWikiUsers"); ... // set user profile to read-only, to not allow changing his // name and surname BaseObject rightsObj = userDoc.getObject("XWiki.XWikiRights", 1); rightsObj.set("allow", 0, context); ... See more in http://odo.lv/git/munixwiki/tools/xwiki-authentication-sts/

Thanks for the snippet, will help me figure out how to do this properly !

Of course, user then loses ability to change his e-mail and other valuable but not identity related fields, but for this application it was not so important.

Ya it's not an issue for me either, as all info is synced from a main system but there are a few wiki prefs that it would be nice to still have. Denis mentioned the use of sheets to better to let people edit specific fields, I will look into that.

Ideally read-write/read-only for profile's owner identity-related and other fields could be parametrized in xwiki.cfg or WebPreferences page.

Or an ACL at the field level...

Valdis

...

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.

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...

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...

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...

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.

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 in advance for your help !

-- Chris

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs