[pmwiki-users] anti-spam multi-page-restore tool

[Peter & Melodye Bowers]

> Just because this bugs me a bit... I have trouble imagining
> using WikiSh on any site that allows a substantial number of
> non-admins to edit pages.  I think it's just far too easy for
> someone to inadvertently or maliciously exploit WikiSh and
> cause serious damage to the site (or server).
> 
> For a site that has a very small number of highly trusted
> authors and where the entire site is locked down, WikiSh might
> be okay.  But for any site where editing is distributed,
> I'd be really concerned about (inadvertently) making WikiSh 
> capabilities available to them.

I fully agree that there is cause for concern -- WikiSh is a sharp tool and
sharp tools can do good work but they can also cut the user if they aren't
used carefully.  This is why in the installation and security sections I
strongly recommend giving write privileges to the WikiSh recipe only on
groups/pages which are password protected and that warning is not a "don't
cut the tag off your pillow" kind of a warning -- it really needs to be
observed.

To help avoid potential problems there are 3 primary levels of protection
built in to any edit of any page within WikiSh.  (1) Regular pmwiki auth
restrictions are always upheld, (2) $EnableWikiShWritePage must be true
before any write can occur, and (3) only pages/groups explicitly allowed
through $WikiShWriteList can be written to.  Having #2 & #3 restrictions
significantly cuts down on the usefulness of WikiSh in general, but there
obviously needs to be some security mechanism and it needs to default to
being tight.  The default installation of WikiSh allows pages to be written
*only* in the WikiSh group on the assumption that probably very few sites
have a group with that name already so there's no danger to existing pages.

If people have thoughts on how security could be tightened or alternate
mechanisms for allowing/disallowing writing to various pages I am wide open
to suggestions.  For instance, perhaps the default installation perhaps be
to not allow any writes and then the administrator can explicitly give them
out as needed?

If you look at the actual code you will see that I have carefully limited
ALL writes to going through a single function and a single call to
UpdatePage() in order to be sure that there is no inconsistency allowing an
unauthorized write.  But, again, I am very open to suggestions, on- or
off-list.

If there are security concerns beyond page-writes I'd be interested in those
as well -- I observe pmwiki auth restrictions in all reads (the only
function I use to read a page is RetrieveAuthPage() with either 'read' or
'edit') so I kind of assume there's not a lot of danger there...

The idea of WikiSh, as I envision it, is a tool generally open to the
administrator (with appropriate write permissions given through
$WikiShWriteList within a carefully password protected group, normally
WikiSh.*) and then available on other pages only with read privileges.  If
it was installed with full write privileges on a page or group without
password protection then there is significant danger from a malicious user -
no doubt about that -- but I would think that almost any recipe with write
capabilities would have potential security problems if it was incorrectly
administered...

Even if an administrator simply set $EnableWikiShWritePage to false for
everyone it would still be a potentially valuable tool for form validation
and other applications, so I'm not sure it's fair to say that sites with
non-admin editors shouldn't use it.  The non-admin editors should certainly
not have global write privilege, but I think the tool itself can be valuable
if correctly administered.  Let's not throw the baby out with the
bathwater...

-Peter