How Plone's Security Works

Matthew Wilkes

How Plone’s security works

2011-11-04

Matthew Wilkes

• Zope / Plone core developer.

• Performance and Security work at the Code Distillery.

• Security teams for both Zope and Plone

2011-11-04

AccessControl

2011-11-04

Aww… here goes!

2011-11-04

ZServer gets request

Transaction start

Traversal

Get security definitions

Convert the permissions

to roles

Find roles in context

Error handling

mapply

Object Publishing

• Mostly handled by publish() in ZPublisher.publish.

• Traverses to the object (or method, or adapter, etc), potentially instantiating new methods.

• Checks roles required against the roles available to the user in context.

• Aborts or commits, as required.

2011-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 patches

2011-11-04

plone.app.protect

2011-11-04

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

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

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

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

You're doing it wrong

2011-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 hotfix

2011-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) repository

2011-11-04

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

The Code DistilleryBristol

Questions?

Or contact us on:[email protected] [email protected]

2011-11-04