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