[xwiki-devs] i did a bad thing on xwiki.org --> authentication/access control issue in xwiki 1.3
I thought I was "playing" with my xwiki install (same skin) but it turns out was actually playing with xwiki.org. 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. Specifically, http://www.xwiki.org/xwiki/bin/view/Scheduler/ has the following list: WatchList hourly notificationsNormalSun Mar 09 07:00:00 CET 2008*Infos* : view <http://www.xwiki.org/xwiki/bin/view/Scheduler/WatchListJob1> *Job* : pause<http://www.xwiki.org/xwiki/bin/view/Scheduler/?do=pause&which=Scheduler.WatchListJob1> delete<http://www.xwiki.org/xwiki/bin/view/Scheduler/?do=delete&which=Scheduler.WatchListJob1> unschedule<http://www.xwiki.org/xwiki/bin/view/Scheduler/?do=unschedule&which=Scheduler.WatchListJob1> WatchList daily notificationsNoneN/A*Infos* : view<http://www.xwiki.org/xwiki/bin/view/Scheduler/WatchListJob2> *Job* : schedule<http://www.xwiki.org/xwiki/bin/view/Scheduler/?do=schedule&which=Scheduler.WatchListJob2> delete<http://www.xwiki.org/xwiki/bin/view/Scheduler/?do=delete&which=Scheduler.WatchListJob2> WatchList weekly notificationsNormalSun Mar 16 00:00:00 CET 2008*Infos* : view<http://www.xwiki.org/xwiki/bin/view/Scheduler/WatchListJob3> *Job* : pause<http://www.xwiki.org/xwiki/bin/view/Scheduler/?do=pause&which=Scheduler.WatchListJob3> delete<http://www.xwiki.org/xwiki/bin/view/Scheduler/?do=delete&which=Scheduler.WatchListJob3> unschedule<http://www.xwiki.org/xwiki/bin/view/Scheduler/?do=unschedule&which=Scheduler.WatchListJob3> WatchList monthly notificationsNormalSat Mar 15 00:00:00 CET 2008*Infos* : view<http://www.xwiki.org/xwiki/bin/view/Scheduler/WatchListJob4> *Job* : pause<http://www.xwiki.org/xwiki/bin/view/Scheduler/?do=pause&which=Scheduler.WatchListJob4> delete<http://www.xwiki.org/xwiki/bin/view/Scheduler/?do=delete&which=Scheduler.WatchListJob4> unschedule<http://www.xwiki.org/xwiki/bin/view/Scheduler/?do=unschedule&which=Scheduler.WatchListJob4> IRC BotNormal *Infos* : view<http://www.xwiki.org/xwiki/bin/view/Scheduler/IRCBot> *Job* : pause<http://www.xwiki.org/xwiki/bin/view/Scheduler/?do=pause&which=Scheduler.IRCBot> delete<http://www.xwiki.org/xwiki/bin/view/Scheduler/?do=delete&which=Scheduler.IRCBot> unschedule<http://www.xwiki.org/xwiki/bin/view/Scheduler/?do=unschedule&which=Scheduler.IRCBot> When I click on "pause" it paused the job, and when I clicked resume, it resumed it with the following message: "Job *WatchList monthly notifications* *resumed*. Next fire time : *Sat Mar 15 00:00:00 CET 2008" *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." 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.Watc... action should be access-controlled and prevented anyways. In my case, it wasn't. 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." 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). 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? -- Niels. http://nielsmayer.com PS: Is there a document describing the security architecture of Xwiki?
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.Watc... 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.
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.
On Mar 9, 2008, at 9:04 AM, Guillaume Lerouge wrote: [snip]
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).
I've checked the scheduler code quickly and it doesn't check for any right. I think the assumption is that if you want to secure the Scheduler pages you'll do this by securing the Scheduler space or individual pages. I think the rationale is that some people will want to have different rights for their scheduler feature. However I think I agree in that we should only allow non read actions to admins by default. WDYT? Thanks -Vincent
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 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.Watc... the 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. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Sun, Mar 9, 2008 at 2:20 PM, Vincent Massol <[email protected]> wrote:
On Mar 9, 2008, at 9:04 AM, Guillaume Lerouge wrote:
[snip]
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).
I've checked the scheduler code quickly and it doesn't check for any right. I think the assumption is that if you want to secure the Scheduler pages you'll do this by securing the Scheduler space or individual pages.
I think the rationale is that some people will want to have different rights for their scheduler feature.
However I think I agree in that we should only allow non read actions to admins by default.
WDYT?
This sort of functionality (or a safeguard in a sense) is also present in default mysql installation where 4 default accounts are created without passwords (i think 2 accounts with 'root' username and two accounts with empty username). The idea is to get the user to read the manual and make his installation secure by himself. I'm not sure whether i'm correct with this argument, but it feels like this is something that has to be left as it is. ( Moral : read the docs! ) Thanks. - Asiri
Thanks -Vincent
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.Watc... 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.
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. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Niels, Thanks for reporting here what you did! :) Several points: 1) This was a xwiki.org setting only. By default when you import the Scheduler application or when you use the default XWiki Enterprise XAR the Scheduler space is not even viewable by non admins. 2) Could you open a jira issue mentioning that the actions should only appear when the user has the rights to execute them? Thanks a lot for your testing! -Vincent On Mar 9, 2008, at 7:01 AM, Niels Mayer wrote:
I thought I was "playing" with my xwiki install (same skin) but it turns out was actually playing with xwiki.org.
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.
Specifically,
http://www.xwiki.org/xwiki/bin/view/Scheduler/ has the following list:
WatchList hourly notifications Normal Sun Mar 09 07:00:00 CET 2008 Infos : view Job : pause delete unschedule WatchList daily notifications None N/A Infos : view Job : schedule delete WatchList weekly notifications Normal Sun Mar 16 00:00:00 CET 2008 Infos : view Job : pause delete unschedule WatchList monthly notifications Normal Sat Mar 15 00:00:00 CET 2008 Infos : view Job : pause delete unschedule IRC Bot Normal Infos : view Job : pause delete unschedule
When I click on "pause" it paused the job, and when I clicked resume, it resumed it with the following message: "Job WatchList monthly notifications resumed. Next fire time : Sat Mar 15 00:00:00 CET 2008"
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."
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.Watc... the action should be access-controlled and prevented anyways. In my case, it wasn't.
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."
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).
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?
-- Niels. http://nielsmayer.com
PS: Is there a document describing the security architecture of Xwiki? _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (4)
-
Asiri Rathnayake -
Guillaume Lerouge -
Niels Mayer -
Vincent Massol