[pmwiki-users] ZAP security vulnerability...

[The Editor]

On 5/3/07, Hans <design5 at softflow.co.uk> wrote:
> Thursday, May 3, 2007, 8:26:10 PM, The Editor wrote:
>
> > One question is given the above assumptions, should I by default allow
> > forms to post data to the same page without a special unlock step.
> > (Seems to me Fox made this choice).
>
> I am just mulling over this choice, and suspect it is no good.
> As we seen, it is enough to include a form into a page by having it
> added to the GroupFooter for instance. Then someone can post to the
> page, even if it was protected.

One advantage perhaps of ZAP is that just making a page writable still
does mean it can be written to. That is, some specific command must be
enabled for the specific form page that can write to it, also... And
you can't (soon) write any kind of form that can write to another page
or use any other commands.  So it makes it a bit trickier for a
hacker... Still you may be right.

As for the GroupFooter kind of argument, I'm trusting the admin to be
very careful about leaving any page parts open if they choose the
riskier route of using ZAP on a wiki with editable pages...

> It always comes to the same point:
> The target page for posting content needs to carry a mark, an
> attribute or a string, which will make it a legitimate posting target.
> Or the admin can expand this by giving permission for posting to other
> pages (for instance via a page pattern array).

I don't like the target string approach.  I'm not going to use it.
What do you do for forums that have multiple pages, created by users
automatically?

> > And what about having an
> > automatically approved auth list--maybe groups like forum, blog, and
> > comments or something (Fox has also done this).  A malicious user
> > could impose text on those pages, but with no commands or targets for
> > those pages could not do much damage.
>
> For Fox it was an attempt to make it easier setting up comment pages.
> But I did not have feedback on this. I guess there are many ways of
> creating comment pages, tied to a document page. So maybe it is better
> to leave it blank. But I would be curious to hear others about this.

Yes, that's good. I'm also wanting to keep ZAP simple to use... As of
yet, I'm not sure I see the risk in having a default auth list if
other protections are in place. But I'll likely leave it off and
require the admin to manually change the Site.ZAPTargets page...

It's coming along well on this end--though the messaging system turned
to be more of a pest than the security problems...

Cheers,
Dan