5 Aug
2013
5 Aug
'13
3:50 a.m.
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
5 Aug
5 Aug
12:21 p.m.
Vincent, Marius, someone... Any thoughts ?
On 8/5/2013 09:50, Christian Meunier 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.
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
6 Aug
6 Aug
5:07 a.m.
Hi Denis !
On 8/5/2013 19:46, Denis Gervalle wrote:
Thanks for this, it seems to be what I need.
I will investigate how to do what you mentioned.
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....
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...
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.
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.
Hi Chris,
On Mon, Aug 5, 2013 at 3:50 AM, Christian Meunier <
christian.meunier(a)magelo.com> wrote:
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
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 
10:30 a.m.
Hi Christian,
On Aug 6, 2013, at 5:07 AM, Christian Meunier <christian.meunier(a)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
1:12 p.m.
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(a)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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1:40 p.m.
On Aug 6, 2013, at 1:12 PM, Christian Meunier <christian.meunier(a)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.
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#HPrivateMailingL…
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(a)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
1:42 p.m.
On Aug 6, 2013, at 1:40 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Aug 6, 2013, at 1:12 PM, Christian Meunier <christian.meunier(a)magelo.com>
wrote:
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
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. 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#HPrivateMailingL…
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(a)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
2:22 p.m.
On 08/06/2013 07:40 AM, Vincent Massol wrote:
--
Sergiu Dumitriu
http://purl.org/net/sergiu
On Aug 6, 2013, at 1:12 PM, Christian Meunier <christian.meunier(a)magelo.com>
wrote:
Yes, but a user that can edit a page can give himself the delete right.
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. 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#HPrivateMailingL…
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(a)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 
2:23 p.m.
On 08/06/2013 08:22 AM, Sergiu Dumitriu wrote:
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On 08/06/2013 07:40 AM, Vincent Massol wrote:
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.
On Aug 6, 2013, at 1:12 PM, Christian Meunier <christian.meunier(a)magelo.com>
wrote:
Yes, but a user that can edit a page can give himself the delete right. 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. 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#HPrivateMailingL…
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(a)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
2:47 p.m.
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.
3:09 p.m.
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(a)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:
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
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(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
5:01 p.m.
On 08/06/2013 09:09 AM, 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.
I checked and it wasn't actually done. The vote (kind of ignored, so
failed) was http://markmail.org/thread/4kho2p4d6weesz2t
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(a)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.
>>
>>
--
Sergiu Dumitriu
http://purl.org/net/sergiu
5:42 p.m.
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 :
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(a)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(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
5:54 p.m.
On Tue, Aug 6, 2013 at 5:42 PM, Christian Meunier <
christian.meunier(a)magelo.com> wrote:
Hi Denis,
Thanks for the snippet !
The drawback with that solution is that the creator of the page cannot
delete his page anymore.
After reading Sergiu's reply, I was just about to tell you that.
So I end up creating another Right called
'advedit' and then I just
patched a single method in
org.xwiki.security.**authorization.internal.**XWikiCachingRightService
:
And now works like a charm and any advanced edit is secured and out of
reach of regular users.
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=...
Regards,
On 8/6/2013 21:09, Denis Gervalle wrote:
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
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(a)magelo.com> wrote:
Hi Sergiu,
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
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(a)xwiki.org
http://lists.xwiki.org/****mailman/listinfo/devs<http://lists.xwiki.org/…
<http://**lists.xwiki.org/mailman/**listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
7 Aug
7 Aug
12:44 p.m.
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.
2:49 p.m.
On Wed, Aug 7, 2013 at 12:44 PM, Christian Meunier <
christian.meunier(a)magelo.com> wrote:
On 8/6/2013 23:54, Denis Gervalle wrote:
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 !
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.
______________________________**_________________
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
2:56 p.m.
On Wed, Aug 7, 2013 at 2:49 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
--
Thomas Mortagne
On Wed, Aug 7, 2013 at 12:44 PM, Christian Meunier
<
christian.meunier(a)magelo.com> wrote:
I agree it's a needed change.
On 8/6/2013 23:54, Denis Gervalle wrote:
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 !
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.
______________________________**_________________
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6 Aug
6 Aug
2:52 p.m.
Hi Vincent,
Will not discuss the delete issue any further given that Sergiu already
answered it.
On 8/6/2013 19:40, Vincent Massol wrote:
That's good to know ! I wasnt
sure everything was versionned.
Great
thanks for the link !
Oky so my best bet is to hack the macro directly and publish my own jar
of it.
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#HPrivateMailingL…
Good to know, will make sure to report further discovery there.
Thanks
-Vincent
Thanks again !
7 Aug
7 Aug
5:30 p.m.
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
5:32 p.m.
On Aug 7, 2013, at 5:30 PM, Christian Meunier <christian.meunier(a)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
9 Aug
9 Aug
11:10 p.m.
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(a)massol.net> wrote:
On Aug 7, 2013, at 5:30 PM, Christian Meunier <
christian.meunier(a)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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10 Aug
10 Aug
4:19 a.m.
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) :
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
8:19 p.m.
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) :
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
13 Aug
13 Aug
1:07 p.m.
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
3 p.m.
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(a)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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
17 Sep
17 Sep
8:16 a.m.
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..
Shouldnt those security PRs be a priority ? Is there a roadmap/target
for those ?
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
8:43 a.m.
Hi Christian,
On Sep 17, 2013, at 8:16 AM, Christian Meunier <christian.meunier(a)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
10:26 a.m.
Thanks Vincent for the heads up !
Any chance Marius or some other dev can have a look the XSS in wiki
Syntax PR ?
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..
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(a)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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:34 a.m.
On Sep 17, 2013, at 10:26 AM, Christian Meunier <christian.meunier(a)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 ?
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(a)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
24 Sep
24 Sep
11:04 p.m.
Hello Christian,
Sorry to have been so long before answering ! Here's at least a
little patch that you can easily apply to make HTML macro secure. Note that
a lot of HTML macros that are in wikis default pages won't work anymore !
Note also that you need the JSOUP package (http://jsoup.org/download) in
your wiki libs to make it work, as this is the library I used for the
verification of the html macro content. For more liberty, you can instead
try to make a custom verification such as the one I made for the wiki
syntax, it's up to you :). To finish, note also that you should skip the
tests when building the new xwiki-rendering-macro-html package, as I didn't
adapt them (these test contains quite a lot of tags and attributes that
should be forbidden for security reasons).
As I probably said earlier, a cleaner way to do that is to put the html
macro in the platform code, and to add a check for programming rights. I
got something like that somewhere, but I should rework it a bit when I got
some time to do it. But at least this patch should let see how this is
supposed to work !
Of course if you have any questions, feel free to ask them, and I would try
to reply a bit faster this time ;)
Hope this helps !
Thomas
On Tue, Sep 17, 2013 at 11:34 AM, Vincent Massol <vincent(a)massol.net> wrote:
On Sep 17, 2013, at 10:26 AM, Christian Meunier <
christian.meunier(a)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 ?
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(a)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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6 Aug
6 Aug
3:08 p.m.
On Aug 6, 2013, at 1:12 PM, Christian Meunier <christian.meunier(a)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(a)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
5 Aug
5 Aug
9:29 p.m.
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).
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/
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.
Ideally read-write/read-only for profile's owner identity-related and
other fields could be parametrized in xwiki.cfg or WebPreferences page.
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6 Aug
6 Aug
3:42 a.m.
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:13 a.m.
Christian,
probably easier to you is to change user profiles using velocity (and
Groovy) scripts
Get list of users according to
platform.xwiki.org/xwiki/bin/view/DevGuide/velocityHqlExamples#HGettingobje…
then change rights properties, following
http://platform.xwiki.org/xwiki/bin/view/DevGuide/APIGuide#HAccessobjectsin…
If you want to set these changes after new user is created
automatically, you can add listener which changes object.
http://platform.xwiki.org/xwiki/bin/view/DevGuide/GroovyNotificationTutorial
Valdis
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4010
days inactive
4060
days old
34 comments
9 participants
participants (9)
-
Christian Meunier -
Denis Gervalle -
Marius Dumitru Florea -
Sergiu Dumitriu -
Sergiu Dumitriu -
Thomas Delafosse -
Thomas Mortagne -
Valdis Vītoliņš -
Vincent Massol