From: Reini U. <ru...@x-...> - 2003-12-06 12:52:52
|
Carsten Klapp schrieb: > Modified Files: > WikiUser.php > Log Message: > Security bugfix (minor): Prevent BogoUser~s from saving extraneous > _pref object meta-data within locked pages. > > Previously, BogoUser~s who signed in with a (valid) WikiWord such as > "HomePage" could actually save preferences into that page, even though > it was already locked by the administrator. Thus, any subsequent > WikiLink~s to that page would become prefixed with "that nice little" > UserIcon, as if that page represented a valid user. > > Note that the admin can lock (even) non-existant pages as desired or > necessary (i.e. any DB page whose revision==0), to prevent the > arbitrary BogoUser from saving preference metadata into such a page; > for example, the silly WikiName "@qmgi`Vcft_x|" (that is the > \$examplechars presented in login.tmpl, in case it is not visible here > in the CVS comments). > > http://phpwiki.sourceforge.net/phpwiki/ > %C0%F1%ED%E7%E9%E0%D6%E3%E6%F4%DF%F8%FC?action=lock > > To remove the prefs metadata from a page, the admin can use the > EditMetaData plugin, enter pref as the key, leave the value box empty > and then submit the change. For example: > > http://phpwiki.sourceforge.net/phpwiki/ > _EditMetaData?page=%C0%F1%ED%E7%E9%E0%D6%E3%E6%F4%DF%F8%FC > > (It seems a rethinking of WikiUserNew.php with its WikiUser and > UserPreferences classes is in order. Ideally the WikiDB would > transparently handle such a situation, perhaps BogoUser~s should > simply be restricted to saving preferences into a cookie until his/her > e-mail address has been verified.) I think this should be another index.php option. if (!defined('REQUIRE_EMAIL_VERIFICATION')) define('REQUIRE_EMAIL_VERIFICATION',false); This would go for storing users in the External DB (if allowed), for the EmailNotification on page changes feature and saving prefs in the homepage. One might need to allow this without EMAIL_VERIFICATION. Regarding EMAIL_VERIFICATION: we need another url action with the sent id as get parameter (e.g.: phpwiki.sf.net/demo/UserName?verify=48731984718937489312749812) and we might need a table to store this pending request id. or would it be enough to store the verification id in the userpage metadata for this short time.? as long as the verify metadata in the users homepage is present, the preferences are restricted to cookies. So will need those new userpref classes: CookieUserPref, HomepageUserPref, ExternalFileUserPref and ExternalDbUserPref; dependent on where to read/write preferences. But on the contrary different classes where to read/write authinfo: AnonUserAuth, BogoUserAuth, AdminUserAuth (questionable), CookieUserAuth, HomepageUserAuth, ExternalImapUserAuth, ExternalLdapUserAuth, ExternalFileUserAuth, ExternalDbUserPref. One could throw away AdminUserAuth because the Anon- and BogoUserAuth class methods should check if the given username is the ADMIN_USER and force a password on this attempted login. All other classes require a password. Maybe we should provide a ALLOW_EMPTY_PASSWORD config option also, maybe also some kind of password strength restriction policy (min 6 chars, ...) Ok? -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |