[pmwiki-users] ZAPauth & PmWiki

The Editor editor at fast.st
Tue Oct 17 05:06:02 CDT 2006


Part 1: Restricting ZAP

Ok, I've had some time to tinker with the code, and have these lines
at the beginning:

$PageAttributes['passwdzap'] = 'Set ZAP forms password: ';
$DefaultPasswords['zap'] = 'id:*';
$HandleAuth['zap'] = '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) {


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:

SDV($ZAPauth[login], "read");
SDV($ZAPauth[read], "read");  //read data/log values
SDV($ZAPauth[forms], "zap");  // only need this if HandleAuth doesn't work
SDV($ZAPauth[upload], "upload");
SDV($ZAPauth[email], "admin");
SDV($ZAPauth[files], "admin");  // create/destroy pages

So on an email form, you could for that one page set ZAPauth[email] to
say 'read' to allow general form submission.  To lock out the various
functions, the recipe would include lines like:

if(CondAuth($pagename, $ZAPauth['email'])) {
     ... authorized features...
     }

It does require me to resort the features by security levels, but
should serve to speed up processing, as all unauthorized features will
be put within conditionals and skipped.

Anyway, does the code above look right?


Part 3. Securing ZAP Forms

In the case where more risky features would need to be available to
unauthenticated users, I need a fix around the vulnerability of forged
headers (say hijacking a contact form for site visitors to send spam).
 I'm considering an optional lock=field1,field2=value,field3 parameter
available in creating the form and saving that as a session variable.
Then, the ZAP engine would retrieve if set, and simply ignore any
fields not in the list. Note, with the above I could also concievably
lock values. I could also instead define a ZAPlock string in a local
config.

But what happens if a user decides not to submit the form?  What
mechanism would be used to destroy the lock? Link the lock to the
pagename? (Thanks for any input as I try to think this though).


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.

Any last thoughts around this problem--the last but most fundamental?
Maybe it is unsolvable--as any authentication information string set
has to either be passed through the form (random number), or retrieved
automatically ($pagename), for form authentication to take place.
(Does encryption offer possibility?  Do I need https?)  If it is
unsolvable, perhaps relying on ZAPauth and the lock mechanism
described above will suffice.

Feeback? Nearing a full release for ZAP 3.  Just want to get this
worked out along with 6-7 other minor but identified tricky code
improvements.  This will indeed one day be CME (Caveman's Magnificent
Engine).

Cheers,
Caveman




More information about the pmwiki-users mailing list