SecurityModules:Wikka

Wikka Security Modules

see also:

WikkaSpamFighting

Where 'Related user contributions' are mentioned, this is for informational purposes, referring to them for valuable ideas or possible solutions - there is no implied guarantee that these would be included in a future version of Wikka. However, if ideas or code from these were to be used, the authors would of course be credited for their contribution.

This page collects links to security-related functionality under development; this comprises both anti-spam measures and other security features. The goal is to monitor and discuss the development of what might become an improved "security" package to release with future versions of WikkaWiki.

Access Control

Current release: 1.1.6.0
The first line of defense for access control would be firewall rules; this is outside the scope of Wikka though - and hence of this page.

Files

.htaccess
handlers/page/acls.php

Current features

site level:

stop referrer spam by keyword matching on the referrer URL (.htaccess)

page level:

page ownership (page owner determines ACLs; admin rights exceed rights of page owner)

separate Access Control Lists (ACLs) for reading, writing and commenting a page (admin rights exceed these)

Beta Features

site level:

deny access by IP address (.htaccess) (version: -)

To do or under development

utility to create/update referrer spam keywords in .htaccess (possibly based on referrers to be banned - see AdvancedReferrersHandler)

functionality to add/update IP addresses to ban referrers or users in .htaccess (now manual only - see also Users - To do)

facility to ban access by IP address in Wikka itself (as an option when .htaccess cannot be used)

for denying access by IP address, see also Content - To do

Related user contributions

none

Referrers

Current release: 1.1.6.0

Files

handlers/page/referrers.php
handlers/page/referrers_sites.php
handlers/page/delete_referrer.php
handlers/page/review_blacklist.php

Current features

view referrers or referrer domains for page or for site

blacklist a referrer domain

review blacklisted domains

delete domain from blacklist

Beta Features

AdvancedReferrersHandler (version: 0.8)

handlers/page/referrers.php - new, advanced referres handling with searching and filtering as well as an accessible form and results table (and more secure as well); obsoletes handlers/page/referrers_sites.php

handlers/page/review_blacklist.php - review blacklisted domains, seamlessly integrated with referrers handling, more accessible and secure

handlers/page/delete_referrer.php - blacklist a referrer domain, more secure and better integrated with referrers handler

RegisterReferrerIpAddress (to be documented - version: -)

IP logging for the referrer

To do or under development

Related user contributions

none

Search Engines

Current release: 1.1.6.0

Files

actions/header.php

Current features

Don't let old pages get indexed: old page versions, referrers listings and the sandbox all get a <meta name="robots" content="noindex, nofollow, noarchive" /> tag to tell Search engine robots to completely ignore the page

Beta Features

none

To do or under development

(optionally) add the rel="nofollow" special attribute to external links so (cooperating) search engine bots will not count these as incoming links for the referred-to page

whitelisting of 'good' domains which will not get this attribute

facility to maintain such a whitelist (admin-only page or plain text file)

Related user contributions

Refining Redirection / nofollow modification for links (IanAndolina)

Email spambots and email spam

Current release: none

Files

none

Current features

none

Beta Features

none

To do or under development

the BadBehavior plugin can stop known spambots or detect them by observed behavior

where an email address or email link must be displayed, make sure the email address is obfuscated (as strongly as possible)

Related user contributions

apply random tokens to the FeedbackAction form (in actions/feedback.php) so a user must at least be "present" on the site (and have accepted a cookie to establish a session) in order to be able to send feedback (IanAndolina)

Content

Current version: none

Files

none

Current features

none

Beta Features

URLThrottling (to be documented) (version: -)

handlers/page/edit.php
limits the number of (new) URLs that can be added to a page; if there are more (new) links than the set limit the user gets a friendly warning but the edit is not accepted.

handlers/page/addcomment.php
limits the number of (new) URLs that can be included in a page comment; if there are more (new) links than the set limit the user gets a friendly warning but the edit is not accepted.

To do or under development

make the limits for URLThrottling configurable via the configuration file (currently hard-coded)

record User name or IP address of people exceeding the URLThrottling limit

(maybe) make the applied limits a random value within a range so a spammer cannot easily find the actual limit by trial and error

extra column 'userip' in pages table

extra column 'userip' in comments table

log IP address used for every page edit (see also Access control - To do )

log IP address for every comment added (see also Access control - To do )

Related user contributions

DeleteSpamAction (MovieLady) (needs some refinement)

Spam Block for Saving pages (IanAndolina) (should be extended with a facility to maintain the blacklist)

Users

Current release: none

Files

none

Current features

none

Beta Features

RegisterUserIpAddress (to be documented) (version: -):
IP logging at user registration in actions/usersettings.php using extra column in users table.
Although it's rare, it does happen that people sign up for an account just to be able to put spam on ACL-protected pages. Although banning the user access by username would be preferable to banning by IP address, it remains possible the same person signs up for a new account. By logging IP address at registration, as well as for each page edit and comment addition (see Content - To do) IP banning becomes possible as a last-resort option to ban spamming registered users (especially if the same IP address is used to register after banning and this "new" user spams again using the same IP address).

To do or under development

extra column "status" in users table ('active|disabled|banned')

functionality to ban user by name

functionality to add/update IP addresses to ban user by IP in .htaccess (now manual only - see also Access control - To do and Content - To do)

Related user contributions

none

CategoryDevelopmentSecurity CategoryDevelopmentAntiSpam
CategoryDevelopmentArchitecture CategoryDevelopmentActions CategoryDevelopmentHandlers

Comments

Comment by DbieL

2006-03-11 16:34:19

Any thoughts on adding email address confirmation to the registration process to prevent users from registering with bogus or with someone else's email address

Comment by DarTar

2006-03-12 05:42:33

DbieL, I think someone had come up with a patch to allow email confirmation - not sure, though, I'd need to check. You might also want to consider Nils' patch for user registration based on a registration key: http://wikkawiki.org/UserRegistration

Comment by RaffaR

2007-09-13 02:36:06

here is a (german) page about email spam protection: http://www.fob-marketing.de/marketing-blog-108-online-marketing-2007-wer-hat-den-besten-spam-schutz.html

the moin moin wiki has a nice feature (MailTo-Macro): if you are not logged in, you will see an emailadress like this: Firstname DOT Lastname AT example DOT net
logged-in users will see the real mailto-emailadress.
http://moinmoin.wikiwikiweb.de/HilfeZuMakros/MailTo

Wikka : SecurityModules