[pmwiki-users] Spam Defacement Protection

Patrick R. Michaud pmichaud at pobox.com
Fri Mar 4 12:12:27 CST 2005


On Fri, Mar 04, 2005 at 06:56:50AM -1000, Sivakatirswami wrote:
>  I'm advocating that we require registration and issue passwords, or at 
> least some very simple "gateway"... I tend to be cautious and place a 
> "high impact" value on a risk assessment issues like this. Others want 
> to make it open to the world based on the "conventional wisdom" that 
> "wiki's rarely get defaced."  and "let's just see what happens, it the 
> site gets defaced, we will face it then."

A completely open wiki is very likely to be defaced by spam robots,
so you'll want something to protect it.  However, there are many
forms of protection available, including registration.  However,
registration isn't a cure-all, since malicious users can register
and then perform their defacements (although spammers typically
don't do this).  Still, here are some insights...

> 1) likelihood of spamming-defacement ( pmwiki.org itself for example, 
> is wide open.) is the "rarely" still a valid truism? 

No.  I like to divide the issue into two types of defacement --
"vandalism" and "spamming".  Vandalism is defacement where someone
is simply out to make an impression on the site.  That still tends
to be fairly rare, although it does occur, and it tends to be
targeted at specific systems as opposed to broadcast at large.

Spamming defacement, however, has become extremely common and
is a major concern among all of the "user contributed content" 
systems, including wikis, blogs, talkbacks, guestbooks, etc.  
Spammers have an economic motivation for what they do, and 
thus they have an incentive to impact as many systems as possible.
If you put up an open wiki site, you're likely to be spammed.

Vandals want to change the "message" of a site; spammers
just want a place where they can store links that will increase
their search engine rankings.  Vandalism can be largely controlled
by vigilance and the existing page rollback mechanisms; spamming
is typically done on a larger scale and needs additional work.

PmWiki.org resolves the spamming issue through a variety of mechanisms,
the most effective being "url approvals".  PmWiki.org maintains
an "approved urls" page (http://www.pmwiki.org/wiki/Main/ApprovedUrls);
any references to external sites that do not appear on this list
are not converted to links.  Instead, unapproved urls are rendered
with an "approval needed" link; anyone with appropriate privileges
can then use this button to add the url to the approved list.  Many
people in the PmWiki community know the approval password ("quick"),
so keeping this up to date is not a problem.  This preserve authors'
ability to edit page content without knowing a password, with the
caveat that any external urls they enter won't be converted to links
until the url has been approved.

PmWiki.org further resolves the issue by summarily blocking any post
that contains more than a few unapproved urls in it.  Posts can
contain any number of approved urls; it's only the unapproved urls
that are checked.  Since spammers tend to want to fill pages with
lots of external links, this has been a fairly effective deterrent
since it was implemented.  (However, it may just mean that spammers
will escalate to some other approach -- we'll see.)

> 2) Revert options for someone who doesn't know PHP... in the latest 
> version of PMWiki? Is it a simple matter now?

Yes, PmWiki can revert to previous versions of a page (has always
had this capability).  So far we haven't implemented an ability 
to do a "mass rollback" of all pages on a site, but it's also the
case that nobody has written to say "I really need this feature"
until just this past Tuesday.  At any rate, it isn't difficult to
add the capability if we really need it.

> We want to delegate certain levels of admin to those actually 
> responsible for the content.  [...]

Indeed, this was my main motivation for writing PmWiki.  :-)

> If reversion is *not* simple, and experienced 
> admins tell us "it's happening, you will have to deal with it... don't 
> think you won't"  then we'll probably go for  some level of initial 
> access protection.

Because of the nature of wikis (or any user-contributed content
system), I think that easily reversing changes is a basic
requirement, and thus PmWiki has always supported it.  However,
whether reversion is sufficient for managing the risks is something
that each site has to determine for itself.

Personally, I find access controls to be annoying and prefer
to avoid them whenever the cost of maintaining the access controls
(including the cost of reduced contributions from authors)
exceeds the risks of not having them in place.

I'd be very pleased to answer any further questions on this
topic.  (In fact, just last night I gave a presentation about 
wiki security to the Dallas/Ft. Worth Unix Users Group, so your
question is timely.  :-)

Pm



More information about the pmwiki-users mailing list