In XWiki 1.8RC1, this "security issue" doesn't seem to be the case by default. For one, if you look at the page's Rights (/xwiki/bin/edit/XWiki/ResetPassword?editor=rights) you'll note that the XWikiAllGroup is explicitly prevented from editing, as are "Unregistered Users". This seems to have the side-effect of turning off programming rights for any logged in users. Thus when any registered or unregistered user accesses the page, they get this error (including XWiki.Admin) This page requires programming rights to work, which currently isn't true.
Please notify an administrator of this problem and try again later.
In fact, I'm not sure what it would take to make the page's rights such that it has "programming rights." Nor how one could setup a standalone "Space-based" app that can run by unregisterded users w/o giving unecessary editing or scripting privileges to those that shouldn't have them -- for example the "Polls" application that is the topic of another conversation. Speaking of security, it is unfortunate that an unregistered user can see script code (e.g. xwiki/bin/view/XWiki/ResetPassword?viewer=code). IMHO, there should be a separate priv alongside "view/comment/edit/delete/admin" which should be "codeview" (turn on/off access to seeing code to a document). It is also unfortunate that a lot of "switches" end up having security ramifactions rather than being able to set security on the basis of leading path-components --.e.g. different accesses for xwiki/bin/view than xwiki/bin/edit . With that model, the &viewer=code argument becomes a toplevel "directory", e.g. xwiki/bin/codeview/ with it's own access and priv capabilities... Niels http://nielsmayer.com On Sun, Feb 22, 2009 at 3:05 AM, Henning Sprang <[email protected]>wrote:
I just realized, the password recovery function unveils a user's password.
In a wiki with registration, and Email verification, where the XWiki space must currently be enabled to be viewed by everybdy, this could be used by spammers(and others who like to collect email addresses) to harvest email addresses by caling the resetpassword function for every user they see on the "AllUsers" page.
I'd propose to not show the Email address to which a password reminder is sent.