• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

This needs to be checked: Main.TWikiRegistrationAgent can change Main.TWikiUsers. The agent topic is not locked down for edit. I am wondering if it is possible to hijack that account (add e-mail address?). If this is the case, the TWikiUsers can be changed, and with this the privilege of an admin can be gained.

-- PTh

*shrugs* Well, let's lock it down, for starters.

SVN 8505 / 8506 (UnknownUser, TWikiGuest, TWikiRegistrationAgent and TWikiContributor all locked to TWikiAdminGroup changes only, now).

-- SP

OK, three scenarios:

  1. No password manager - email stored in personal topic
    • SP has locked down the personal topic, so that's covered
  2. htpasswd manager
  3. third-party password manager
    • as long as an unknown account can't set emails, no problem.

I can't see any vulnerability here.

CC

CC, good idea listing the cases seperately. I have tested the usecases I could think of now, no problems.

The "no password manager" case is a bit tricky when testing, as it will basically receive a "true" from for all calls. That means it you will get a "success!!" reply for password reset, password & e-mail change - but of course it won't affect any authentication files. And as email addresses aren't copied to any of the built in topics (because of topic locking), I think there are no problems here.

I think the only weak cases in the scheme now are:

  • Setups that are authenticated using apache basic auth can be bruteforced if no apache module is installed to limit number of password tries. BlackListPlugin should cover the password reset form preventing a brute force attempt using template login (I suppose it does, haven't checked).
  • As the reset form only demands a WIKIUSERNAME, it is no problem resetting the password for a lot of users suddenly, causing a little abruption in the workflow of the user base. This could probably be enhanced by not resetting the new password at actual time of requesting the reset, but only send a "someone is trying to reset your password - press this link if you really want to reset your password", and then, when the link is clicked, send a yet another e-mail containing the reset / new password, allowing for changepassword as usual .. or something like that.

These cases do not concern me enough to take action on them, but they exist. I'll set this "Waiting for feedback" - in case you agree on it not being "major", please just close it.

-- SP

Once workflow is integrated into TWiki that sort of logic will be much easier to implement.

I tried doing a ResetPassword?username=TWikiRegistrationAgent, happily it failed with the complaint that the email address was not set.

We might want to log/notify the administrator of failed attempts to reset passwords.

-- MC

Thanks SP for locking down the topic.

-- PTh

ItemTemplate
Summary Possible to hijack TWikiRegistrationAgent?
ReportedBy TWiki:Main.PeterThoeny
Codebase

SVN Range Tue, 24 Jan 2006 build 8489
AppliesTo Engine
Component

Priority Normal
CurrentState Closed
WaitingFor

Checkins 8505 8506
Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r11 - 2006-01-27 - PeterThoeny
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback