9 Mar
2008
9 Mar
'08
9:04 a.m.
Hi Niels,
thanks for your testing, even though doing so on XWiki.org is not such a
good idea indeed ;-)
Unfortunately, I "hit" some buttons on
xwiki.org and the actions I did
should have been prevented by access-control,
but they weren't. The actions assoc'd with these button should probably be
available only to 'Admin' (or someone w/ programming rights) and not
available to me logged in as 'NielsMayer' (
http://www.xwiki.org/xwiki/bin/view/XWiki/NielsMayer )
Given that I just recently registered and I'm not a "committer" (yet) I
assume I should not have programming Access rights. Unfortunately, it let me
perform the actions anyways as if I did have these rights.
I think it's only a problem of display -> basically, you cannot create new
jobs (this would add groovy code to the page and indeed require programming
rights, which you do not have). However, there must be a missing check
before the button you hit (something akin to #if
($xwiki.hasAccessRight('program') == 'true') button #end). So this is a
bug
in the watchlist application rather than in the rights setting of the wiki.
I think that had you tried the .../bin/delete/... URL you would have
received a "you do not have the rights to perform this action" message. In
the worst case, the page wouldn't have get lost thanks to the recent restore
page feature ; -)
*<snip>
*This is despite the printed warning at the bottom of the page:*
*"Job creation is reserved for programmers. It seems you do not have
programming access right allowed on the Scheduler space."
The last version of the watchlist was released a few days ago, meaning there
is probably some testing remaining. Please report this bug in JIRA (
http://jira.xwiki.org/) so that it can be fixed by the watchlist app
developer.
Xwiki.org <http://xwiki.org/> says it's running "1.3-rc-1.8082"
---------------------------
This leads me to wonder how such administrative functions are secured. It
makes sense to condition presentation of pause/delete/unschedule/schedule
on whether Administrative/programming-access is available to the logged-in
user. (i.e. don't present UI capabilities which aren't accessible to the
given login/role).
However, if someone were to just enter the URL
http://www.xwiki.org/xwiki/bin/view/Scheduler/?do=pause&which=Scheduler…
action should be access-controlled and prevented anyways. In my case, it
wasn't.
We absolutely agree on this. Most of the time XWiki has script that checks
the user rights prior to displaying specific parts of the UI (for instance
on the topbar menu -> the menu is not the same depending on the user being
logged in as a reader, an admin...)
Anyways, sorry about doing this by accident. Hopefully no damage was done (I
did resume the job i paused).
I assume this is a "bug" I've discovered, and not a "feature."
Then it means you'll have the joy and priviledge of playing with our JIRA
instance soon ;-)
I guess further explorations in this area should be done on my own instance
rather than xwiki.org ....
( no, i didn't test "unschedule" or "delete" given the potential
that
they'd actuallty work).
Thanks ! :-) If you really want to test XWiki online you can use
http://playground.xwiki.org/xwiki/bin/view/Main/ instead (it's almost always
running on the latest version of XWiki)
If this is a bug, it would probably make good sense to review other
instances where this might happen (aka "security
walkthrough" of code).
Is there any automated functional testing of the entire system (as opposed
to unit testing) to ensure such access control issues aren't lurking in
other areas?
We're always working on adding new tests. Your help would be greatly
appreciated in this area should you have the possibility to write some of
them. I'll let someone else tell you whether this one in particular already
exists.
-- Niels.
http://nielsmayer.com
PS: Is there a document describing the security architecture of Xwiki?
I didn't found it on XWiki.org, meaning someone will have to write it. If
you feel like it, you can start one at
http://dev.xwiki.org/xwiki/bin/view/Drafts/ if you want to.