[pmwiki-users] ZAPauth & PmWiki

[Patrick R. Michaud]

On Mon, Oct 16, 2006 at 04:49:47PM -0400, The Editor wrote:
> On 10/16/06, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> > > On 10/15/06, The Editor <editor at fast.st> wrote:
> > > > I'm trying to improve the permissions systems in ZAP a bit to make it
> > > > tie in better with PmWiki.
> > > > ...
> > > > The question is, how do I access a given user's current auth level
> > > > within a recipe such that I could say something like,
> > > >
> > > > SDV($ZAPauth[email], "admin");
> > > > if( ~get users auth level~ == ZAPauth[email])  execute emailer()
> >
> > We can't ask a generic question such as "does the user have edit
> > permission".  We can only ask "does the user have permission to
> > edit page XYZ".  There's no such thing as general "read level",
> > "edit level", or "upload level" associated with a user -- one can
> > only speak of those permissions in reference to a particular
> > page.
> 
> So you would write something like the following then:
> 
> SDV($ZAPauth[email], "admin");
> if( ~user has $ZAPauth[email] /ie "admin"/ permission for current
> page~ )  execute emailer()
>
> Can you help fill in the code?

    SDV($ZAPauth['email'], 'admin');
    if (CondAuth($pagename, $ZAPAuth['email'])) execute emailer();

> > > > Also, on a related note, how does PmWiki avoid forged headers with an
> > > > upload form?  ...
> >
> > What do you mean by "forged headers"?  Or, put another way, PmWiki
> > doesn't rely on headers for authorization.
> 
> I'm thinking about the basic security vulnerability I have with ZAP,
> and wondering how you solved it for uploads (or edit forms for that
> matter).  Couldn't someone forge a form submission that has upname and
> upfile, etc., and all the right fields, fire it off and automatically
> upload a file to your server?  Surely you somehow check the form
> submission to ensure it genuinely came from a PmWiki page, and that
> the submitter has permission to upload.  

PmWiki doesn't care if the form comes from a PmWiki page or from
some other source (e.g. forged) -- that's not the basis for PmWiki's
security.

Using the upload example -- when someone (or something) makes a submission
to PmWiki to upload a file, the submitted form contains the upname, 
upfile, etc.  fields as you describe above.  At that point PmWiki 
asks the question "Is the submitter authorized to upload the file I've 
just received to the page specified by the form?"   It does this by 
making a call to RetrieveAuthPage, as in:

    $page = RetrieveAuthPage($pagename, 'upload', true, READPAGE_CURRENT);

RetrieveAuthPage looks at any authid/authpw fields in the form
just submitted, as well as any credentials previously entered for
the session (stored in session variables) to determine if the
action is allowed.  The 'true' argument in RetrieveAuthPage
says that if the action is not allowed, then send back an
authorization form to obtain the credentials needed to
perform the operation.

If an authorization form is returned, that authorization form
contains fields for entering authid/authpw, as well as hidden
fields for all of the values that were submitted in the original
request.  The browser of course displays this form, the author
fills in a username and/or password, and then resubmits the
authorization form (which contains all of the original data
plus the two new fields) back to PmWiki.  PmWiki then treats
this as a new request, checking to see if the submission has
sufficient credentials to proceed with the action, and
returning another authorization form if it doesn't.

So, PmWiki never needs to keep track of "which forms have been
sent out" -- it only looks at incoming requests.  In order
to perform the operation, either the request must contain an
authid/authpw that grants permission, or the request must
contain a cookie that associates the request with a previously
submitted authid/authpw stored in the session.


You may reasonably ask why I suggested the "keep track of
which forms have been sent out" approach in an earlier mail 
on this topic.  The answer is that ZAP seems to want a
different approach to access control -- ZAP wants to allow
people to create and modify pages even if they don't have
edit permission in the PmWiki sense, and ZAP wants the
displayed input form to determine which page(s) the end-user 
is allowed to modify on a subsequent request.  That's a 
substantially different model (and has more room for unwanted 
surprises) than the "every-request-carries-its-own-credentials
or is prompted for them" model that PmWiki implements.

Still, this is a problem quite similar to the one I'm
having with ?action=insert, so it's possible that the core
will add "authorize based on having seen a given form in
the current session" abilities too.  But the authorization 
code is already such that I'm wary to make too many changes to it,
and I'm not keen on adding *yet another* dimension to the
core authorization code, since it has so many already.

Pm