Mailing-List: contact jspwiki-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: Vaughan Schmidt <vschmidt@schmidtusa.com>
Organization: The Schmidt Group, Inc.
To: jspwiki-user@incubator.apache.org
Subject: Known Security risks?
Date: Mon, 21 Jul 2008 10:15:04 -0400
User-Agent: KMail/1.9.9
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200807211015.04713.vschmidt@schmidtusa.com>


This may not be quite the right forum to look for this information, but I'll 
ask anyways:

Wikis in general are notably insecure as it is in their nature to be open, 
editable, and accessible.  The permissioning and ACL features of JSPWiki seem 
to allow much more granular control that would be usefull in a corporate 
intranet environment.

(I know this is a broad question) What - if any - are known weaknesses within 
JSPWiki security?  Primarily concerned with unauthorized users viewing 
content or even portions / snippets of content they should never know exist.

One particular question (I could model this and test...) - When a user enters 
a search, are the Lucene results filtered by the user's permission to view 
that page?

I am currently uninstalling a competitive package because of just that 
weakness.  

For example:  Joe User searches for term "employee layoffs" and the search 
results show that this term is indeed contained on the page "2009 Business 
Plan" which he normally can not access.  But at least now, he knows that such 
a page does exist and does contain that search phrase - although the link to 
the page is non-functional per the ACL definition.

I'm asking the mailing list because some of these little security loopholes 
are hard to stumble across just in "sandbox" testing - a lot of them require 
the user to do something slightly unexpected to bring them to light.

Thank you-

Vaughan Schmidt