[pmwiki-users] Security and post

[Patrick R. Michaud]

On Wed, Apr 18, 2007 at 08:59:05AM -0400, The Editor wrote:
> On 4/18/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> >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.  [...]
> 
> 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.

You'd be wrong, or at least missing the point.

Security is not determined by whether session variables or post
values are used as part of the access control system.  What
matters is that every access is authorized using something that
cannot be easily forged or intercepted by an attacker.

IIRC, the early versions of ZAP sufferred from the problem that
the keys used to authorize access were obtained from the form
submission itself.  Thus an attacker could easily forge a
working security key as part of submitting form data -- it
wasn't necessary to intercept one first.  (Yes, I believe this
problem has been fixed in ZAP/Acme.)

But a claim that any system that uses POST values as part of
its access control mechanism must therefore be less secure
is inaccurate.  In fact, at the lowest level, even PmWiki
relies on POST variables (and cookies) for authorization --
session variables are just a way to reduce the number of times
that information gets transmitted across the wire.

> 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.

It helps, but if you really haven't studied what the other
forms processing engines are doing, perhaps it would have been
better to leave the comparison out of the description.  Something 
like "ZAP maintains authorization credentials using session variables
to reduce vulnerabilities" is workable, without the direct
implication that other recipes are therefore less secure than ZAP.

Pm