[xwiki-devs] [Discussion] Replacing the use of PR checks. Is it really an option? How exactly?
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
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 <[email protected]> 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
On Fri, Dec 12, 2014 at 4:16 PM, Eduard Moraru <[email protected]> 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.
-1 to do so, and I have comment the ticket about my reasons.
Thanks, Eduard
On Fri, Dec 12, 2014 at 4:47 PM, Eduard Moraru <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
[Warning: this is just some incoherent Friday late evening thoughts with low information density ... well, now that I have written them down I will send the mail anyway. Executive summary: No, I did not have a good idea that solves the problem.] On 12/12/2014 03:47 PM, Eduard Moraru 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?
I have to admit that I did only thought about getting rid of PR checks in case of the "Activity Stream" use case, where the only need to have PR on the page is to skip read access restrictions in the HQL query. In such a case where it is only about proper reading data and only showing the user the data he/she has the right to see the "add an API script service and check things there" is possible, because the worst thing a malicious user can do is adding 1000 Activity-stream macros to the page and then have a very slow page ... However when it comes to an API where users can write things, then these checks are clearly not enough to prevent malicious users writing scripts that could be involuntarily triggered by sufficiently powerful users. I cannot even see how the user could be informed property that the action is really the one that this user wants to perform (i.e. the script might be really save the wiki description, but not from the values the user has typed in, but some garbage the script author has pulled, and it only does so on Friday 13th.) In case of XWIKI-11416 (wiki description admin) I vaguely thing that these pages should only be editable and visible to admins, (which is something that the Script-API might be able to check), and that might be an idea: do not require programming rights from the document author, but only the Admin rights that the user performing the actual action requires too - if the author is an Admin, too, he/she could have just gone ahead and make the change instead of building traps for the colleagues. However I feel that I am overlooking something here ... Aside of that I guess as one can not really limit what the script author is allowed to without making the scripting capability useless. Basically you have to trust the script author ... I first thought about something like checking on document save that the script contents have not been modified, and if that is the case, keep PR rights to the page, but then I figured out that all what I was trying is to reinvent a poor "signed scripts" solution :) Part of the problem in XWIKI-10446 is actually that the wiki pages belong to the user who has installed them, even thought the contents come from some archive, and it would be better if the pages belong to some "trusted installer" (maybe "superadmin", if only that one already exists), allowing local admins in subwikis to install extensions without having the need for PR themselves. But I guess that idea has already been dismissed? After all this does not handle the use case where an UI with pages requiring PR are installed, ant the local admin just wants to rename some button label. However at least they could install extensions ... Cheers, clemens
Thanks, Eduard
---------- [1] http://jira.xwiki.org/browse/XWIKI-10446 [2] http://jira.xwiki.org/browse/XWIKI-11416 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (3)
-
Clemens Klein-Robbenhaar -
Denis Gervalle -
Eduard Moraru