[pmwiki-users] ZAPauth & PmWiki

[Patrick R. Michaud]

On Tue, Oct 17, 2006 at 06:06:02AM -0400, The Editor wrote:
> Part 1: Restricting ZAP
> ...
> Unfortunately it doesn't seem to work.  It shows up in the attr page
> with the right value but when I log out and try to submit a form, it
> allows it.  So line three doesn't seem to work.  Here is how the
> function is called:
> 
> $HandleActions['zap'] = 'ZAPengine';
> function ZAPengine($ZAPflag = 0) {

A function being called via HandleActions has to have the form:

    function ZAPengine($pagename, $auth='zap') { ... }


> Part 2: Customizing ZAP
> 
> My next goal was to connect certain ZAP features to different auth
> levels, but make these configurable, so you could allow more risky
> behavior in certain single group/page (form) situations.  Here are the
> suggested default settings:
> ...
> Anyway, does the code above look right?

I can't really tell from what's presented here.  

> Part 4. Authenticating ZAP Forms
> 
> The final security measure is some effort to try and authenticate ZAP
> forms--as having come from a genuine PmWiki page. The idea was to set
> a session variable when the form was marked up and then check when the
> form was submitted that that variable was properly set.  The variables
> also need to be linked to the page they were submitted from, and set
> up as an array in case there is more than one zap form on a page
> (common for me at least).
> 
> I tried a random number key--but gradually realized it only helps a
> little--as the number must be passed with the form to be submitted to
> authenticate. And while hackers can't set a session variable they can
> go to a page with a form, get the session variable set, retrieve the
> random number, and then forge their own form submission, and send it
> in.  In this scenario, protection would be dependent on whether or not
> they can spoof $pagename.  I suspect that is very flimsy protection.

You've stopped one level short.  The random number shouldn't be
sufficient to allow posting any form value -- it should only be
sufficient to post to the exact data pages that were authorized
for that number when the form was sent.

In other words, an attacker gets a form, gets the session variable
set, retrieves the random number, but that random number is good
only for posting to the data page(s) associated with the random number
in the session variables.  It doesn't matter if someone uses the
random number to forge a form submission -- they're still limited
to modifying the data page(s) that the random number enabled.

Pm