Jon Pentland: Security considerations for Plone providers

published Oct 06, 2023

Talk by Jon Pentland at Plone conference 2023, Eibar, Basque Country.

Our company PretaGov did an accreditation process. We have lots of government contracts, so this got important. It is a self assessment process.

What I want to do in this talk is talk about holistic security, the kinds of things we needed to do for the accreditation.

Organisational security

How do you manage your secrets? High quality, unique passwords. Not written down. We use a password manager across the organisation. This also finds compromised passwords.

Secure your devices: firewalls, antivirus, automatic updates, have a software policy (what software can you install, do you need approval for this), no out of date/legacy software. Last part is tricky when you still need to maintain Plone 4.3 sites. We worked around this by doing it on Docker, so at least our own development machines are not vulnerable.

Cloud/Saas: have an audited list of services, individual accounts where possible, don't give admin access to everybody, close unused accounts, use MFA if possible.

Infrastructure security

Define the scope: understand what you have, for example by creating an image with users, machines, internet boundaries, cloud services, networking equipment.

Secure servers and cloud infrastructure. Control the access to servers. A VPN with two factor can help here. Have a minimum required access. Keep servers up to date, firewall, antivirus where applicable. Backup and disaster recovery system: if your data is encrypted and held ransom, you want to be able to get back a recent version.

Web security

The browser goes to the proxy or load balancer and then your app (Plone). It is 2023, every site must be encrypted with https, this is free with lets encrypt, including auto-renewal.

Think about the Cipher suites. Older suites are insecure to for example the heartbleed or beast attacks. You should use TLSv3. You might need an older version if you need to support older browsers. Check the security with automated tools.

Setup https strict transport security. This tells the browser to remember that this site uses https. This makes the site harder to spoof when an attacker controls the wifi. Check https://hstspreload.org/

Click jacking: tricking users to click somewhere that they did not mean. Can be done with invisible iframes. Prevent this by setting X-Frame-Options header, either DENY or ALLOWORIGIN. Cookies should have the Secure setting so it will not be sent on http and in some cases the httpOnly setting so it can't be read from javascript.

XSS, Cross Site Scripting Attack. Plone protects you from this usually, and the security team looks at this. You can set a Content-Security-Policy header. It can be tricky as it can disable functionality that you rely on. You can set "report-to" to get browsers to send you a report about things it would have blocked, so you can try your policy for a while. Check https://www.uriports.com/

If you see security problems in plone, mail security@plone.org.

Plone security

Change the default admin password. Block access to the ZMI (manage, manage_*), you should normally not need this. Install hotfixes, see https://plone.org/security/hotfixes. Use Python 3. If you really still need Python 2, your OS vender may offer paid support.

Protect logins. collective.PasswordStrengthPlugin, there is a branch for Plone 5/6. collective.googleauthenticator, also here Plone 5/6 support coming. Products.LoginLockout: brute force protection, after some failed logins, block the user for a time. Or block all  users except a few specific ones. pas.plugins.authomatic hands off your authentication to Google or GitHub, etc.

Volto security

Content-Security-Policy gets tricky because Volto sets inline scripts and styles, so this requires "unsafe-inline" in the policy. @plone-collective/volto-csp and volto-middleware-helmet help here, they are coming soon.

CORS, Cross Origin Resource Sharing. A lot of browsers block javascript from accessing other domains. Volto needs to access data from the Plone api, so if you host this api on a different domain, you will need to set headers with Access-Control-Allow-Origin and Credentials. Configure this on the backend. Only use a single origin. You can use *.example.com, but then the Credentials will not be passed.

Security for the build stack. Use cookiecutter-plone-starter for a good base setup. Use dependandabot to warn you about vulnerabilities in packages that you use. Use a CI/CD setup to ease rolling out fixes.

Assorted security

Some more things that are worth doing.

Rate limiting, for example with haproxy, to prevent someone hammering your site. Fail2Ban, mostly just getting rid of traffic you do not want. See also Fail2Ban.WebExpoits for custom checks.

Email: SPF, DKIM, DMARC.

Feature Policy Header let's you control what javascript features are allowed on your site, for example disable microphone and camera.

With a Referrer Policy Header you can instruct the browser to not send a Referer header to the next site.

Audience: