How Plone's Security Works

354 views
291 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
354
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

×