[pmwiki-users] Why all this zapping?

[The Editor]

On 5/1/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Tue, May 01, 2007 at 11:40:33AM -0400, The Editor wrote:
> > On 5/1/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> > >On Tue, May 01, 2007 at 10:57:51AM -0400, The Editor wrote:
> > >> True.  As the ZAPsite recommends, ZAP should only be enabled on pages
> > >> where trusted users have access to edit permissions.  That is, either
> > >> lock down your site for editing and do all user interaction through
> > >> ZAP, or only enable ZAP on specific non-editable pages.
> > >
> > >This understates/misstates my point.  If ZAP is enabled on
> > >_any_ publicly accessible pages, then an author with edit permission
> > >to any other page on the site -- even pages where ZAP isn't
> > >"enabled" -- can use ZAP directives to modify any other page on
> > >the site.
> >
> > Not sure I see the difference, but we're aggreed ZAP should not be
> > enabled on any pages where untrusted users have edit privileges (ie
> > non admins) unless special precautions are taken involving one of the
> > various security layers available in ZAP.
>
> The key difference is 'pages' versus 'site'.
>
> Your statement seems to imply that it's okay for a site to
> allow editing of some pages by untrusted users (e.g., something
> like a WikiSandbox) as long as ZAP is not enabled on those pages.

Yes, that is correct, as I understand it...

> I'm saying that if ZAP is enabled _anywhere_ on a site that allows
> _any_ editing by an untrusted user, then the untrusted user
> can use ZAP to modify any other page on the site, and likely
> obtain the contents of otherwise read-protected pages.

How could they do that?  If ZAP is not enabled any ZAP form a person
created would do absolutely nothing.  No info retrieved.  No commands
executed.  No post processing.  Nothing.  So how could ZAP be used to
obtain the contents of read protected pages or anything else for that
matter--via editable pages ZAP is not enabled on?

It might be possible with the {(sectionlist)} markup cause that
doesn't require a form submission, but it hasn't even been released
yet, and it will certainly be fixed before it comes out. The {(source
)} might also need some tweaking to beef it up, but even then it's
already blocked where the source is blocked.

> > Also about the source markup expression...  If a page is blocked for
> > reading, is it automatically blocked for source?  If so a page might
> > be read protected but not source protected, making the source markup
> > expression a vulnerability. (It only checks source permissions, not
> > read permissions). Is this correct?
>
> PmWiki doesn't have anything called 'source' permissions.  I think
> you're confusing permissions here with ?action=source, and the
> default permissions for ?action=source are indeed 'read' permission.
> This is controlled by the setting of $HandleAuth['source']
> (which defaults to 'read', meaning that read permissions are
> required to view a page's source via ?action=source).

Well, I may have expressed myself unclearly but you can check if a
person has access to view the source of a page with this code you gave
me (it works!)

	if (! CondAuth($p, $HandleAuth['source'])) return '';

My question was if a page was read protected but the source action was
not blocked, could a person by pass the read permissions this way?  At
least that's what I was meaning.  If so, I need to add a second check
for read permissions, just in case an admin read protects a page
without blocking the source.

Cheers,
Dan