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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
