[pmwiki-users] ZAP security vulnerability...

[Patrick R. Michaud]

On Wed, May 02, 2007 at 05:09:04AM -0400, The Editor wrote:
> On 5/1/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> >On Tue, May 01, 2007 at 08:02:01PM -0400, The Editor wrote:
> >> I suggested one possible (probably easy) fix off-list that could
> >> provide that back door. Allowing a simple string replacement array to
> >> be processed before doing markup processing on an imposed page.
> >
> >I'm not sure exactly what you mean by "imposed page", but
> >it sounds as though you mean "any page where the markup is
> >coming from somewhere other than the current one."  
> 
> I'm not even talking about disabling markup.  Only a way to run some
> kind of escape function. Like define a configurable str_replace (zap,
> zaap) or whatever that is run just before the markup--perhaps only
> when a user doesn't have write permission to the page that markup is
> imposed on. 

I'm afraid I don't understand what you're saying here.  I understand
the notion of "escape function", but I don't understand exactly
when you're wanting it to be run.  In particular, what do you mean
by "just before the markup" and "when a user doesn't have write
permission to the page..."  (which user?)

If you're just wanting a markup rule to be fired at the beginning
of markup processing, then just use '<_begin' as the $when parameter
to Markup().  That rule will then be executed before any other
markup rule.

If you're wanting to have a set of pattern replacements performed
on text coming from (:include:) or the pagelist fmt= parameter,
then $QualifyPatterns is what you want.  For example:

    $QualifyPatterns['/\\(:zap .*?)/e'] = "Keep(PSS('$0'))";

will cause all (:zap ...:) directives coming from an
include directive or pagelist template to be escaped.
But in this last case, as I said before...

> >I think that many admins and authors would find such limitations
> >to also be confusing and overly constraining ...


> [...] I'm just
> saying there should be a mechanism for this available for people
> wanting to do anything like this (any kind of forms processing in
> PmWiki is vulnerable to this). 

I disagree that "any kind of forms processing in PmWiki is vulnerable
to this".  Only those kinds of forms processing that that rely on
the rendering engine for authorization and seek to bypass PmWiki's 
edit permissions are vulnerable.

> I'm open to whatever suggestion you have, but you haven't been very
> forthcoming with recommendations . 

As I've said before, I don't have a good answer or 
recommendation for this, and I've been looking at the problem
for *months* [1].  If that's "not being very forthcoming with
recommendations" (i.e., because I don't have any), I apologize.  
It's not from a lack of trying.

I did recommend that we need to come up with a
better overall solution to bypassing edit permissions [2].

[1]  http://www.pmichaud.com/pipermail/pmwiki-users/2007-May/042505.html
[2]  http://www.pmichaud.com/pipermail/pmwiki-users/2007-May/042521.html

> In short, as far as I can see, since wiki markup can be imposed on
> page authors don't have edit permissions 

You still haven't told me exactly what you mean by "imposed page",
or how we can detect when something is being "imposed" versus
something being "intentional" by an author.

I am trying to be helpful, but you're not really answering the
questions that would help me to come up with an answer for you.

Pm