[pmwiki-users] New Acme recipe...

[The Editor]

On 4/18/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> > >> - Is it safe to use
> >
> > > No known security vulnerabilities or bugs.  All are fixed as rapidly
> > > as possible. In some ways it is more secure than other processors as
> > > it uses session variables for all it's major commands. [...]
> >
> > I would love to hear other's opinions on this. Especially about the
> > claim that using session variables makes it more secure.
>
> Security is a very complex topic, and in general there are limited
> ways to get it right and lots of ways to get it wrong.  The best
> measure of security is to have the code reviewed by others and to
> see how well it survives real-world attacks.
>
> The use of session variables doesn't automatically make a script
> "more secure" -- it depends on how they are used.  To give an example,
> a recipe might use session variables to store a captcha key, but
> if that recipe also transmits the captcha key in cleartext as
> part of an input form, then the use of the session variable hasn't
> increased security at all.  (In fact, in such a case the session variable
> will technically provide _less_ security, because the captcha value is
> available in even more places than it was before.)

Just to clarify: this is not what ZAP does. And I don't think Pm is
implying ZAP does this.

ZAP does send a key by a post value to the engine which is used to
access all the other values stored in a ZAP SESSION array. So a
malicious user could see the key (the form name, basically), but
unless he could set session values he would not be able to execute a
single advanced command in ZAP.

I have not studied the Fox security system in any degree, but if Hans
is only relying on POST values to give users access to page editing
functions, I'd say it is at the very least a potential security risk.
I have mentioned this to Hans and even offered code to help with it,
but it has not been used to my knowledge.

And again to reiterate, ZAP taps fully into PmWiki's password
permissions system for every form submission, meaning form submission
capabilities can be limited to any password, id, group, etc. And the
Site.ZAPConfig page makes it easy to instantly lock every toolbox
feature in ZAP for every page on your wiki except where specifically
enabled.

I make no claims about ZAP's security, but I've followed every
suggestion given to me and made it as tough as possible. If others can
identify specific vulnerabilities I'll promptly plug them. But until
something can be demonstrated, (with all due respect to my admittedly
limited programming knoweldge) I can honestly say it's at least
protected against all known vulnerabilities

Hope this helps to provide at least a bit of the evidence Pm requested
to explain my statement that ZAP may at least "in some ways" be more
secure than other processors. Emphasis on the word "MAY" as I have not
really studied other processors--and have no idea what mechanisms they
use to protect admins from forged headers or any other security risks.

Cheers
Dan