Next Event: NDC Security
“In Defence of PHP”
16-19 Jan 2023 @ Oslo, Norway
Hi, I’m an international speaker on the topics of security and development. I present fun and engaging talks, aiming to entertain and instruct the audience. At the end of a talk, I want the audience to leave with a smile on their faces, having learned something new and enjoyed themselves.
I’m always looking for more opportunities to speak in new places, so please reach out if you’d like me to speak at your conference or event.
You can find my various talks and presentations listed below, click through for full details, including recordings, slides and additional materials. Alternatively, you can find many of my recorded talks on on a YouTube Playlist.
Web browsers are magical creatures that include A LOT of features. Buried within this multitude, you’ll find a number of security tools waiting for you, kinda like the chatty stranger in the bar, trying to flog off their wares. Although unlike that stranger, the browser lets you use them all for free, and you can use as many as you want!
You might have heard of Content Security Policies (CSP), and HTTP Strict Transport Security (HSTS), and Same-Site Cookies, or seen headers like X-Content-Type-Options and X-Frame-Options in your web server configuration. What about the confusingly named CORP, COOP, CORS and COEP, or Trusted Types, and a Permissions-Policy?
The point is, like secrets in a cave, there are a lot of security tools hidden in your browser. You won’t want or need all of them on every site, but if you’re aware of what’s available, you’ll know what you can and should enable, to add that extra layer of security to your sites. I’m just not sure they’ll help you slay that dragon though…
When we think of our apps being hacked, we typically think of the common acronyms that cover technical vulnerabilities: XSS, CSRF, SQLi, etc. (Cross-Site Scripting, Cross-Site Request Forgery, SQL Injection, etc). While these vulnerabilities are important and we do need to be aware of how to avoid them, they aren’t the only threat we need to consider. We also need to consider the human vulnerabilities, the weaknesses that target the human between the keyboard and chair.
We will look at recent examples of social engineering, such as the attack of Twitter in 2020, and the many stories of cryptocurrency vaults being plundered through SIM-swapping. We’ll also look at password reuse, brute force attacks, and credential stuffing, and even some hardware hacks that fool victims the old-fashioned way. The common thread in all of these cases… The vulnerability existed between a keyboard and chair.
What happens if a hacker breaks through your app, and gets to your server? You missed one tiny thing, and now the hacker is doing whatever they want on your server… How do you stop this from turning into a catastrophic event?
When we think about web app security, we immediately think of writing secure code, but that’s only half the story. We also need to secure our servers. We need to make sure that if a hacker breaks in, we can limit the damage they cause.
So in this talk, we’re going to assume the role of a hacker who has broken through the code, and has access to the server. We’ll go from there, hacking our way around, seeing what we have access to. While at the same time, adding layers of defence (as the site owner) to try and stop an impending catastrophic breach. The goal is to keep thinking like a hacker so we can build and deploy secure apps on all levels.
“Let’s Hack!” Workshop
- WordSesh 2021 (3 hour interactive hacking workshop)
Thinking like a hacker is an important step to protecting your site, it helps you identify where your vulnerabilities are and what is (and isn’t!) important.
A great way to gain the hacker mindset is to hack a site yourself, so that’s what we’re going to do in this workshop!
We’ll hack into an intentionally vulnerable WordPress site, learn why the hack works, and how to defend against it. All you need is your web browser and you’re ready to be a hacker!
Laravel comes with many secure options enabled by default, and a bunch of helpful features that you can use to secure the rest. This helpfulness is a double-edged sword though, and you can easily begin to overlook the security implications of using specific features and end up writing insecure code without even realising it. There are plenty of guides and checklists online, such as the OWASP Top Ten, to teach you about web app security, however since a lot of people learn better by doing, we’re going to hack into a Laravel app to learn how to secure it!
We will target a vulnerable Laravel application, attacking common weaknesses and misconfigurations to compromise the app. After every attack, we will make the required changes to fix the vulnerability, and then attempt the attack again, hopefully unsuccessfully this time! The goal is to think like a hacker, learning what types of vulnerabilities exist and how they are exploited, so we can write secure code and protect our apps from attack.
Although they’ve been around for years, SameSite cookies hadn’t gained much attention until September 2019. The Chrome team announced their plans to set ‘SameSite=Lax’ on all cookies without the SameSite attribute in Chrome 80, scheduled to release in February 2020. The rollout was delayed due to COVID-19 until July 2020, and was finally completed in August 2020. With many developers still unaware of this setting and how it works, it is still likely to catch a lot of us unawares with broken sites and weird behaviours.
In this session we will learn about the SameSite cookie attribute and why it is so important to securing your site. We’ll see why ‘Lax’ is the best default to use, and when you’d want to use ‘Strict’ and ‘None’ instead. Additionally, we will cover the edge cases and weird behaviours that can easily cause confusion and seemingly weird bugs. By the end of the session, you’ll know how to properly configure SameSite on your cookies, to ensure your site takes advantage of the security benefits without breaking expected functionality.
“What could I have done to avoid being hacked?” is a question you’ll often hear after a site is hacked. In some cases the answer is complicated, but a lot of the time it’s relatively simple and there are many checklists and guides online outlining the ways sites can be hacked, plus how to secure them. However, a lot of people learn better from seeing and doing than reading (often boring) checklists. So rather than look at checklists on slides for 30 minutes, we’re going to hack into WordPress instead!
We will target a vulnerable installation of WordPress and attack the usual weaknesses to compromise the site. After every attack we perform, we will make the required changes to block the attack, and then attempt to compromise the site again, hopefully unsuccessfully this time! The goal is to think like a hacker, learning what types of vulnerabilities exist and how they are exploited, so we can better protect our sites and block hackers before they get in. By the end of the talk, we should have a secure site and an incredibly frustrated hacker.
- WordCamp Port Macquarie 2019
- Security, Identity, and Privacy Miniconf at linux.conf.au 2019
- WordCamp Brisbane 2018
Stephen has been working with the Wordfence Site Cleaning team part-time since early 2017, Fast-forward to the middle of 2018 and he’s recently stepped back from cleaning to join the Wordfence team full time as a developer, so now it’s time for him to tell us his story. He’ll share stories from the more memorable sites he’s cleaned, revealing his all-time favourite WordPress malwares, and the epic tale of the persistent attacker that almost thwarted them completely. Scattered throughout will be tips and ideas to help protect your site from compromise and keep everyone (except the bad guys!) happy.
- New Zealand PHP Conference 2015
As PHP developers, we often find ourselves managing our own web servers and performing the same commands over and over again for each new server and website that we wish to deploy. We’ve heard about the benefits of tools like Puppet and Chef, but the time and effort involved in learning, setting up, and using those tools is prohibitive and we usually decide that using SSH, relying on bash history and even some helper scripts is easier than learning something new. However, there is an alternative: Ansible.