1. How Plone’s security works
Matthew Wilkes
2011-11-04

2. Matthew Wilkes
• Zope / Plone core developer.
• Performance and Security work at the Code Distillery.
• Security teams for both Zope and Plone
2011-11-04

3. AccessControl
2011-11-04

4. Aww… here goes!
2011-11-04

5. Object Publishing
ZServer gets
•
request
Mostly handled by publish() in
ZPublisher.publish.
Transaction
start
• Traverses to the object (or method, or
Traversal
adapter, etc), potentially instantiating new Get security
methods.
definitions
Convert the
permissions
•
to roles
Checks roles required against the roles
available to the user in context. Find roles in
context
• Aborts or commits, as required. mapply
Error
handling
2011-11-04

6. AccessControl
• C and Python implementations of security.
• ImplPython is much more verbose, and supports
VerboseSecurity, great for debugging.
• Documentation pretty poor.
• Open by default.
• If you don’t think about it explicitly, you will have
problems.
2011-11-04

7. ClassSecurityInfo
• The most important class for doing security in Plone.
• All your classes should have one of these declarations.
• Provides declarePublic, declareProtected, declarePrivate
• Sets the information onto the class itself in __roles__
• Confused by subclasses and monkey patches
2011-11-04

8. plone.app.protect
2011-11-04

9. CSRF Overview
• Making people do things they don’t want to without them
noticing
• Example: visit evilsite.com and end up changing your
password on myintranet.com
• Number 5 on the OWASP top 10 for 2010
2011-11-04

10. POSTonly not enough
• But do it anyway.
• Possible to fake POST request using javascript (but not
read the response)
• Better, but not best, for that we need a token
2011-11-04

11. User specificity + gotchas
• Don't share CSRF tokens between users.
• Especially, don’t publish your secret (e.g. in github), or
evilsite.example will start generating your tokens.
• Causes problems when scaling/restarting (users filling in
forms can suddenly be told they're invalid).
• Don’t generate a token unless you have to.
2011-11-04

12. SQL^W Python injection
• We're (mostly!) safe from SQL injection
• It's not the only kind of injection.
• We’ve had two pickle injection vulnerabilities.
• Never trust user input (this includes URLs!)
2011-11-04

13. You're doing it wrong
2011-11-04

14. Mistakes
• Relying on magic to ensure class security is set up (call
InitializeClass explicitly!)
• Enabling features in external packages by accident
(zope.traversing)
• XSS via tal:content="structure whatever"
2011-11-04

15. Yet more mistakes
• Accidentally making methods publishable (missing
underscore, or a docstring)
• Thinking not publishable is an excuse for no security
• Attributes added at runtime are usually publishable
• Incorrect security declarations (typos, monkey patches)
2011-11-04

16. How we hotfix
2011-11-04

17. How Plone hotfixes
• A problem is reported
• When possible, we give advance warning of the patch
date
• We work on the patch in a shared (secret) repository
2011-11-04

18. Structure
• Applied in __init__
• Provide a log message to say it's applied (check for this!)
• Mostly don't break things if you install them on the
wrong versions. Mostly.
• Release as an old-style product, to make it easier.
• Try and provide eggs.
2011-11-04

19. The Code Distillery
Bristol
Questions?
Or contact us on:
alan@thedistillery.eu
matt@thedistillery.eu
2011-11-04