On Fri, Dec 12, 2014 at 4:16 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
To be more precise, I am currently facing this issue
when trying to
implement
http://jira.xwiki.org/browse/XWIKI-11416 and I need to remove
the
PR check in the wiki script service to be able to edit wiki descriptors in
a subwiki, hopefully without unwanted security holes.
Thanks,
Eduard
On Fri, Dec 12, 2014 at 4:47 PM, Eduard Moraru <enygma2002(a)gmail.com>
wrote:
Hi devs,
We are all waiting for signed scripts to come to the rescue, but until
then, we have pretty much agreed that it is a good idea to remove PR
checks, which don`t work in subwikis (see activity stream [1], wikis
module
[2], etc.)
However, once we do that, we open up a big security problem, such as
"trap
pages". These are basically documents
containing malicious usage of our
services, that are written by regular users and that are waiting (or
tricking) for admins (or users with privileges) to access them by
mistake.
Since those script services will be looking only
at the current user's
rights, they will be executing the malicious code and the security will
be
compromised.
What options do we have here?
On some modules (like the wiki module) it might be useful to check the
context security document (sdoc) and see if its author is an admin (of
the
wiki descriptor that is being saved) or a global
admin, thus replacing a
PR
check on the current document with an "admin
check on the current
document".
Using sdoc instead of just doc avoids attempts of using proxy documents
(e.g. default ones like /bin/view/someDocument?sheet=SomeBadDocument or
custom ones created by the usage of the display or include macros), but
unfortunately that is not set by default by XWiki's actions and is only
available in a handful of locations, meaning we can not rely on sdoc.
A mechanism similar to CSRF protection API but for script services to
confirm that the user really intended to execute them might be another
idea, but I`m not sure how that might be implemented without allowing
easy
bypass by directly providing the challenge
result. CAPTCHA for sensitive
script services? :) That might be too extreme and completely ruin the UX.
Any ideas?
Thanks,
Eduard
----------
[1]
http://jira.xwiki.org/browse/XWIKI-10446
[2]
http://jira.xwiki.org/browse/XWIKI-11416
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs