As Tom Eastman puts it, "If you're a web dev and you don't know about the OWASP Top 10, you're a liability to your project"; or as Richard Clarke put it, "If you spend more on coffee than on IT security, you will be hacked. What’s more, you deserve to be hacked."
Security is important. The recent spate of ransomware attacks has emphasised this even more, and our clients are naturally nervous.
Earlier this year, in addition to attending local OWASP meetups, following NZISM guidelines and internal training, all the Springload back-end developers flew to Auckland for the OWASP New Zealand Day 2017. OWASP is short for Open Web Application Security Project.
Secure coding can feel a bit abstract at first. As a developer you’ve read about the different vulnerabilities and you roughly know how the exploits are run but you're never completely sure that your app is fully secure or how to verify it is. Because not every client will be able to afford penetration testing to surface possible issues we need to make sure we cover as much as possible ourselves.
The training day was all about running the most common exploits yourself to get a better understanding on how they work and how you can protect and test your applications and websites. Funnily enough, the first task was copy the different training materials from a USB stick which every other developer has plugged to their computer before you. Luckily we weren't at Kiwicon and the training is about web security, not computer security so what could go wrong?
As the day goes on we successfully steal various users' credentials via Cross-Site Scripting (XSS), using Cross Site Request Forgery (CSRF) vulnerabilities to execute some actions on their behalf, and fetching information stored in databases via SQL Injections or even execute malicious code on the remote server.
If anything, it showed how vast the surface of attacks is and how you could think that you're protected when you're actually not. For example, you might naïvely filter out script tags from the user's input to prevent XSS, but the attacker could use the inline event handlers to bypass the filter.
It’s super important to stay informed, to keep learning and to share new findings as the scene is constantly changing. The obvious takeaway here is to not to roll your own solution as it's too easy to miss something. Rather we should rely on battle tested systems with as many contributors as possible.
This is one of the main reasons we use Django and Wagtail at Springload. The open source nature of these projects means there are many eyes and minds contributing to ensure every project is built with security in mind by default.
Day 2 started with the review of the OWASP Top 10, in particular the upcoming 2017 version. Lots of old faces here (Cross-Site Request Forgery, Cross-Site Scripting and various injections), a come back from 2004 (Broken Access Control) reminding us to always be vigilant and two notable new additions, Unprotected APIs and Insufficient Attack Protection.
APIs aren’t new but are definitely on a roll, and because you can’t see an API the same way you do for a web page, it might be easy to forget about some endpoints. However, not seeing it doesn’t mean it’s not discoverable and sooner or later, someone will find and exploit it.
In other words, treat your API the same way you would treat a regular application with secure communication (Secure Sockets Layer), a proper authentication/authorisation system, probably built upon an open-source framework (as explained above, many eyes and minds contributing to a secure base) rather than a roll-your-own, using some sensible defaults (use a project template to ensure all of them start on solid ground).
The second newcomer, Insufficient Attack Protection has had a lot of attention, not only during the opening talk, but throughout the day. Drifting away from a code vulnerability, it simply ask the questions “Do you know when you are under attack?” and “Do you know how to respond?”. Sure you have logs, but do they cover host, platform and application level security risks, including our beloved and trusted third party services like Content Delivery Networks (which as we’ve seen are, like everybody else, vulnerable)?
Logs are only part of the answer – they need to be proactively rather than retroactively examined (or be able to raise warning automatically) and a recovery scenario needs to be available to allow a quick response to an attack. Simple questions but not so simple answers.
Two factor authentication
Throughout the day, many speakers expressed their love/hate (mostly hate) relationship with passwords and how to do it right. The bottom line was that passwords aren’t enough anymore. Enable two-factor authentication for your users if you can or, if you’re willing to, hand over authentication to a third party like Google or Twitter. The latter can seem a bit extreme and depends on how much you trust that third party, but it also takes a thorn out of your side.
No matter how secure your authentication system is, you can’t be sure that whoever successfully signed in is the actual account owner. This is account takeover in a nutshell. Again, you can decide to deal with it yourself or choose to rely on the massive resources of the social giants allowing them to invest into machine learning for a more fine-grained detection.
Just when you think you have heard about all the terrible things you have to protect your app against, Michele Spagnuolo and Lukas Weichselbaum from Google showed us how Content Security Policy can be bypassed. Despite this, you should still use it. It might not be the perfect solution but it still offers an important layer of protection.
Finally, Charlie Gavey ran us through the competence journey to remind us that with security, because the dog is always chasing its tail, we might always be at the conscious incompetent stage so we need to stay vigilant and keep learning.