How Plone's Security Works
Upcoming SlideShare
Loading in...5

How Plone's Security Works






Total Views
Views on SlideShare
Embed Views



2 Embeds 3 2 1



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

How Plone's Security Works How Plone's Security Works Presentation Transcript

  • How Plone’s security works Matthew Wilkes2011-11-04
  • Matthew Wilkes • Zope / Plone core developer. • Performance and Security work at the Code Distillery. • Security teams for both Zope and Plone2011-11-04
  • AccessControl2011-11-04
  • Aww… here goes!2011-11-04
  • 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
  • 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
  • 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
  • CSRF Overview • Making people do things they don’t want to without them noticing • Example: visit and end up changing your password on • Number 5 on the OWASP top 10 for 20102011-11-04
  • 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
  • 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
  • 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
  • Youre doing it wrong2011-11-04
  • 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
  • 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
  • How we hotfix2011-11-04
  • 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
  • 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
  • The Code Distillery Bristol Questions? Or contact us on: matt@thedistillery.eu2011-11-04