Thread: [Phpwiki-talk] RFC: HOW TO alternate security setups in PhpWiki

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Here is a draft security HOW-TO.  Please comment. There are some
outstanding questions (particularly about whether it is necessary to lock
group pages) and there is a bug in SetAcl (regarding removing groups from
an Acl) that I want to look into before completing this document.

Eventually, with cleanup, it could become a WikiPage in it's own right.

regards,
Charles

I hate WikiSpam!

Being technically minded and based in the Asia timezone while my
co-authors are mainly in Europe and some in the US, it became my
unofficial role to clean up the WikiSpam each day in a 1.2 based PhpWiki.
The WikiSpam that I see is mostly created during the evening in the US
timezone - which is the morning for me.

I started working on PhpWiki 1.3/1.4 with a view to upgrade our wiki
implementing security to:
* let anyone view our work,
* let anyone register themselves as users,
* but require new users to be authorised before editing or creating pages.

While testing and fixing bugs, I discovered some interesting and useful
things about security in PhpWiki that I hope will help others. This is the
recipie that I used. There are many variations that will work just as well
or even better for you.

1 - Generic secuity setup. For the configuration that I describe above,
the following parameters should be set in config/config.ini (and are
further documented there).

; require the new login code - the default
;ENABLE_USER_NEW = true

; allow ACL based permissions on pages - the default
;ENABLE_PAGEPERM = true

; allow unknown/anonymous users to by default read the content
ALLOW_ANON_USER = true

; prevent unknown/anonymous users from editing/creating pages
ALLOW_ANON_EDIT = false

; prevent users just creating a temporary user
; (I am skating over the complexities of this setting)
ALLOW_BOGO_LOGIN = false

; to require users to have passwords
; (this is not independent of the other settings above)
ALLOW_USER_PASSWORDS = true

; require passwords to have a minimum length
; I am not trying to protect national security,
; just encourage the vandals to go elsewhere
PASSWORD_LENGTH_MINIMUM = 6

; use a database to check user-ids and passwords.
; Note that there many other settings database settings that
; need careful attention but that is out of scope for this HOW-TO
USER_AUTH_ORDER = "Db"
USER_AUTH_POLICY = first-only

; Store group information in wiki pages
; there's no need to develop a complex front end for a database.
GROUP_METHOD = WIKIPAGE

; the master page listing the groups - I just used the default
; CATEGORY_GROUP_PAGE = CategoryGroup

; The following SQL queries/statements are stored in
; config/config.ini so that they can easily be changed
; if there an existing user database. Several of these have
; alternatives documented in config/config.ini
DBAUTH_AUTH_USER_EXISTS = "SELECT userid FROM user WHERE userid='$userid'"
DBAUTH_AUTH_CHECK = "SELECT IF(passwd=PASSWORD('$password'),1,0) AS ok
FROM user WHERE userid='$userid'"
DBAUTH_AUTH_CRYPT_METHOD = plain
DBAUTH_AUTH_UPDATE = "UPDATE user SET passwd=PASSWORD('$password') WHERE
userid='$userid'"
DBAUTH_AUTH_CREATE = "INSERT INTO user SET
passwd=PASSWORD('$password'),userid='$userid'"
DBAUTH_PREF_SELECT = "SELECT prefs FROM pref WHERE userid='$userid'"
DBAUTH_PREF_UPDATE = "REPLACE INTO pref SET
prefs='$pref_blob',userid='$userid'"

; I am paranoid about undiscovered cross-site scripting
; vulnerabilities so I prevent users injecting HTML directly into
; pages. It may be safe to allow the latter 2 options
ENABLE_RAW_HTML = false
ENABLE_RAW_HTML_LOCKEDONLY = false
ENABLE_RAW_HTML_SAFE = false

2 - User Group management
Create group pages in the wiki. First, in page CategoryGroup, add the name
of the group in the bulleted list.  This may either be a WikiWord or
enclosed in "[" and "]" and ther must be nothing else on the line. For
example, while editing CategoryGroup, add
* [Writers]
* UserManagement
and save (? does CategoryGroup have to be a locked page?). I will use
these two groups as examples.

Then create the group pages by clicking on the links in the CategoryGroup
page and add the list of users as a bulleted list (as above). (? do the
group pages have to be locked?). In the Writers group, list the users that
are allowed to edit and create pages. In the UserManagement group, list
the users that may authorise new users (or remove existing users).

New users may be added as required.

3 - change the default page permissions. This is the not so well
documented piece (as far as I can tell). Create a page named . to hold
these default permissions. Yes, named "." - this cannot be done directly
from normal web interface. (Note that these permissions may be over-ridden
at the individual page level.)

What I did was to
* export a Zip Dump via the PhpWikiAdministration page
* extract one of the files from this zip - initially, it might look like
==== start ==============================================
Subject: AppendText
From: foo@bar (PhpWiki)
To: foo@bar (PhpWiki)
Date: Wed, 5 Jan 2005 17:09:46 +0800
Mime-Version: 1.0 (Produced by PhpWiki 1.3.11pre-20050108)
Content-Type: application/x-phpwiki;
  pagename=AppendText;
  flags="";
  author=The%20PhpWiki%20programming%20team;
  version=1;
  lastmodified=1104916186;
  created=1104916186;
  author_id=The%20PhpWiki%20programming%20team;
  markup=2;
  charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<?plugin AppendText ?>

==== end ================================================
* rename and edit this file (I called it dot but this does not matter) and
the contents should look something like
==== start ==============================================
Subject: .
From: foo@bar (PhpWiki)
To: foo@bar (PhpWiki)
Date: Mon, 17 Jan 2005 15:54:59 +0800
Mime-Version: 1.0 (Produced by PhpWiki 1.3.11pre-20050108)
Content-Type: application/x-phpwiki;
  pagename=.;
  flags="";
  author=Admin;
  version=1;
  lastmodified=1105949000;
  created=1105949000;
  author_id=Admin;
  markup=2;
  acl="view:_EVERY; edit:_ADMIN,_OWNER,Writers,-_BOGOUSER,-_AUTHENTICATED;
create:_ADMIN,_OWNER,Writers,-_BOGOUSER,-_AUTHENTICATED; list:_EVERY;
remove:_ADMIN,_OWNER; change:_ADMIN,_OWNER; dump:_EVERY";
  charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

This page holds the default permissions for all pages

==== end ================================================
The author should be the name of the administrator account.  The important
line is the one starting "  acl=".

This lists the groups/login types allowed to perform various actions on a
page. Names starting with an _ and all in capitals are built
("_ADMIN","_OWNER" etc.). A - in front of the name means that that group
is not allowed perform an action,
so "edit:-_AUTHENTICATED" means that a user that has logged in is not
allowed edit a page (unless they are also a member of another group that
is allowed).

The example line acl above implements the policy that I described near the
start of this message.

* load the file back into the database through the PhpWikiAdministration
page.
* check the permissions are what you need in PhpWikiAdministration/SetAcl
* test the permissions work as expected.
* if you have to alter the acl, I suggest that you bump the values for
version, lastmodified and created before reloading.

* set any additional restrictions on an individual page by page basis. For
example, to have a limited list of users that can manage adding and
removing users from the Writers group, you could
- on pages Writers, UserManagement, CategoryGroup and CategoryCategory
- remove Writers from edit and create permissions
- add UserManagement to edit and create permissions
(Note, there seems to be a problem removing groups in the UI, so use the
dump page, manual edit and reload page mechanism documented above).

Thread: [Phpwiki-talk] RFC: HOW TO alternate security setups in PhpWiki

phpwiki-talk