I hadn't heard of these before but all of them of them appear to require some run-of-the-mill good coding practices and a few are helped by Zope Unvaliated input - don't trust input from users if you use it to construct, say, a SQL query. Zope attempts to mitigate/enforce this by encouraging you to use special DTML tags for SQL methods. Many other things exist here as well. Broken access control - set Zope security up properly. Broken auth and session management - use SSL only and don't store cookies persistently. XSS - Zope's ZMI is resistant to this, you'll need to make sure your own app is too. Huge topic, not always fixable. Buffer overflows - none known that are exploitable via Zope itself. Injection flaws - a nonissue for Zope proper, it doesn't execute any system commands. Might be a problem for custom apps. Improper error handing - turn off debug mode, get rid of VerboseSecurity. Insure storage - encrypt your content. Turn on password encryption in your user folder. Denial of service - totally a per-application sort of issue, you need to "think like a scumbag" to fix most of the issues. Insecure configuration management - Zope ships "default secure" AFAIK. - C On Fri, 2005-03-18 at 13:34, Bill Seitz wrote:
Are any of the OWASP guidelines either (a) a non-risk by default in Zope, or (b) documented in terms of specific Zope practices to follow/avoid?
http://www.owasp.org/documentation/topten.html
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )