Security has been a hot topic the past month with Morten Von Seelen of Deloitte presenting at the Umbraco DK Festival and just recently, well-known Australian security expert, Troy Hunt ran a two-day security workshop in Copenhagen. We sent three of the HQ developers to join Troy and learn all about securing your websites, through the art of hacking yourself. We’ll let Mikkel tell you what it was like to be a hacker for two days, and how we can apply Troy’s lessons to Umbraco, for the better health and security of your web projects. Mikkel will also give you some tips on securing your site!
The workshop was structured in such a way, that in order to teach the attendees security, they had to act like hackers. That way, we were able to figure out exactly how a site could be exploited, and how this can be prevented. The workshop was a great mixture of hands-on exercises and real world examples of where the things we had just hacked ourselves, have been exploited.
Over the two days, we covered subjects such as Cross Site Scripting(XSS), Sql Injection, Https, Brute force attacks and Content Security Policy(CSP). With these different subjects, the workshop didn't just teach us the exploitation methods but perhaps more importantly, the prevention methods to avoid these hacks from happening in the first place.
One of the main takeaways was that when developing a new site, security is often thought of as the last thing you do. At that point, both the budget and time for the project is usually spent, leaving security behind. Security therefore needs to be something that is built into the development process early on.
Keeping Umbraco Secure
Keeping Umbraco secure is one of our top priorities as we want you to be confident in all our systems, services and products. One of the things we do to ensure this is to have a third party security firm do penetration tests on a regular basis. These are tests where the firm acts like a hacker, and tries every possible way to break into the systems. If a security hole is reported we make sure to fix it straight away.
In Umbraco HQ we have most of this covered, and we are trying to encourage developers to also keep their code up to date. One of the ways we do this is through the Health Check dashboard in the backoffice. With this Health Check feature you can check whether the current site is configured properly. Among these checks are ensuring it runs Https, and whether you are sending too many headers along with the requests.
We have added the new Health Check dashboard to give you a better overview of the security needs of your site. Most of the security fixes can be handled with a single click - if not, then there’ll be a guide to help you. Security is important so that’s why we want to make it as hassle free for developers as possible. We will be extending the security checks on the dashboard in the coming versions, and pull-requests are already rolling in for new Health Checks options.
It is important for Umbraco HQ to keep our developers at the cutting edge of security, and attending workshops like these helps further our education, and improve the products we make, ensuring they are up-to-date on the latest security requirements. For more information about how we handle security in Umbraco, check umbraco.com/security
Security tips for you
Throughout the workshop, a lot of time was spent talking about passwords and how to manage these. Everyone needs passwords in their daily life. And when you, as a developer, create a site where the user needs to create a login, you take on the responsibility of storing these personal credentials however, indirectly, you also take on the responsibility to store their personal credentials for all their accounts, that being banking, social media, shopping etc. The reason for this is that most people tend to use the same password across all of the services they sign up for. This is a huge responsibility that you need to be aware of as a developer.
From a developer's point of view, you should therefore calculate whether it is worth the risk, and if you do decide on saving the passwords, you need to do it as securely as possible.
For the end user, the lesson is that you really need to have different passwords for all the places you have logins. This can be easily managed by a password manager such as 1password or LastPass which helps you generate unique passwords that only the program knows.
This part will be a bit technical. When implementing password storing in your systems there are multiple ways of doing so. At the workshop we had a look at different ways and how difficult it would be to decrypt a password. The idea is never to store the password itself, but instead store a hash of the password. This takes away some of the risk, being that only the user knows the full password and the system just knows a hash. An example would be the password: kitten2016 which hashes to “$2a$06$QWZybVPc7nIfhkngieOTBeQ1P9bU1clokxMSNudQyuApkNLjFos5W”
Hashing of a password is done by applying a hashing algorithm to the password. For this purpose we have previously relied on SHA-1 with a salt. During the workshop we were shown just how vulnerable that algorithm is - it was even called useless. Instead, a more modern algorithm like bcrypt or PBKDF2 is a requirement.
An enumeration attack is identified when registering a user, retrieving a password or the likes, and from the response messages, the hacker can figure out whether an account exists or not. This is especially important for sites where you might not want other people to know that you have an account, like a dating site for adultery (think Ashley Madison).
Many sites will implement the “reset password” page making an enumeration possible. The page will have an input field where the user can insert their email, and if the email exists, the page will write something like: “Instructions for resetting your password has been sent to your email”. And likewise, if the email doesn’t exist, it will let the user know, e.g.: “The email wasn’t found in our systems”. That last message is the problem, as the hacker (or wife ;) ) now knows whether that email has an account on the system or not. Based on this information the hacker can start entering all known emails in order to get an insight into the site’s user base.
The fix for this issue is to use the same feedback message to the users, whether the email exists or not. This message then won’t reveal anything to a potential hacker.
As you can see, we really came away with a lot of interesting input from this two-day course with Troy Hunt. Some of the things were even quite easy to implement once we got back to the office, which makes the takeaway even more satisfying. I hope that this blog post will inspire you to focus more on security on your website - perhaps you’ll even handle the security holes I mention above straight away ;)
Take care and stay safe
- Mikkel Holck Madsen