Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
How Plone’s security works                              Matthew Wilkes2011-11-04
Matthew Wilkes             •   Zope / Plone core developer.             •   Performance and Security work at the Code Dist...
AccessControl2011-11-04
Aww… here goes!2011-11-04
Object Publishing                                                                ZServer gets             •               ...
AccessControl             •   C and Python implementations of security.             •   ImplPython is much more verbose, a...
ClassSecurityInfo             •   The most important class for doing security in Plone.             •   All your classes s...
plone.app.protect2011-11-04
CSRF Overview             •   Making people do things they don’t want to without them                 noticing            ...
POSTonly not enough             •   But do it anyway.             •   Possible to fake POST request using javascript (but ...
User specificity + gotchas             •   Dont share CSRF tokens between users.             •   Especially, don’t publish ...
SQL^W Python injection             •   Were (mostly!) safe from SQL injection             •   Its not the only kind of inj...
Youre doing it wrong2011-11-04
Mistakes             •   Relying on magic to ensure class security is set up (call                 InitializeClass explici...
Yet more mistakes             •   Accidentally making methods publishable (missing                 underscore, or a docstr...
How we hotfix2011-11-04
How Plone hotfixes             •   A problem is reported             •   When possible, we give advance warning of the patc...
Structure             •   Applied in __init__             •   Provide a log message to say its applied (check for this!)  ...
The Code Distillery                                           Bristol             Questions?               Or contact us o...
Upcoming SlideShare
Loading in …5
×

How Plone's Security Works

429 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

How Plone's Security Works

  1. 1. How Plone’s security works Matthew Wilkes2011-11-04
  2. 2. Matthew Wilkes • Zope / Plone core developer. • Performance and Security work at the Code Distillery. • Security teams for both Zope and Plone2011-11-04
  3. 3. AccessControl2011-11-04
  4. 4. Aww… here goes!2011-11-04
  5. 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 handling2011-11-04
  6. 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. 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 patches2011-11-04
  8. 8. plone.app.protect2011-11-04
  9. 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 20102011-11-04
  10. 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 token2011-11-04
  11. 11. User specificity + gotchas • Dont 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 theyre invalid). • Don’t generate a token unless you have to.2011-11-04
  12. 12. SQL^W Python injection • Were (mostly!) safe from SQL injection • Its not the only kind of injection. • We’ve had two pickle injection vulnerabilities. • Never trust user input (this includes URLs!)2011-11-04
  13. 13. Youre doing it wrong2011-11-04
  14. 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. 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. 16. How we hotfix2011-11-04
  17. 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) repository2011-11-04
  18. 18. Structure • Applied in __init__ • Provide a log message to say its applied (check for this!) • Mostly dont 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. 19. The Code Distillery Bristol Questions? Or contact us on: alan@thedistillery.eu matt@thedistillery.eu2011-11-04

×