O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
When we talk about security,
what do we really mean?
• You have sites
• They have intended purposes
• We want them to focus on those purposes and not be co-opted for other
• Preventing this co-opting of your sites is the starting point of security
What are we securing against?
• Physical intrusion
• Code vulnerabilities
• Server (stack), application, customization
• Vulnerabilities (XSS, SQLi, escalations)
• Bad actors
• Human and not so human
Why aren’t we talking about physical security?
• Very few of us are managing/running our own datacenter(s)
• Physical security is almost always out of your direct control
• Any reputable hosting solution will have this covered for you
Keeping Trusted Packages Secure
• Be aware of security releases for important stack software, plugins,
• mailing lists, alerts, regular update checks, etc.
• Have a regular update schedule, or use automated updates
• Use checksums/trusted package managers when applicable!
• Be vigilant - security patches happen for a reason
WordCamp US 2016 Presentation
What to Look For in Code Review
• Validation, sanitizing, escaping
• Cross-site scripting vulnerabilities
• Smart fetching of remote data
• Outright nasty code - did someone access code who shouldn’t have?
How to Do Code Review
• Refer to last year’s presentation
• Biggest recent improvement: code review on GitHub
• Protected branches
• Use continuous integration tools and tests!
• No-one merges their own changes?
• Single-dev is both more and less dangerous
Forced Login Protection
• Repeated attempts by bad actors to test logins to your site
• Several pre-packaged service solutions available to help with this
• Jetpack Protect
• Twice as many steps!
• Requires access to a physical device
• Lots of good solutions
• Jetpack/WordPress.com SSO
• Best to use an app, not SMS
• Remind users to have their backup codes!
Reducing Your Administrators
• Only give admin access to people who absolutely need it
• If there is a feature non-admins cannot access and want to:
• Do they really need it?
• Will it give them access to other things they should not have?
• Are they using two-step authentication?
• Consider experimenting with and using custom roles
Reducing the Damage Users Can Do
• Remember that admins can do EVERYTHING
• Consider custom code restricting or disabling some features:
• Code editors
• Site settings
• Load and activate plugins via code, not UI
• The default user system is great for a large number of WordPress sites,
but it might need some tweaking for your sites or projects
• Limit access to datastores as much as possible
• Limit access to any credentials you need to store as well
• Code review! Again!
• Observe best practices for local security for any local copy of your data
Backing Up Your Sites
• Database dumps
• sqldump + scripting
• Various backup plugins
• Backup installations
• Hosting provider backups
• What does your host provide?
• Using a “cloud” backup solution