On 4/18/07, Patrick R. Michaud <[EMAIL PROTECTED]> 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 _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
