I have two enduring loves beyond the commonly accepted ones of health and family: technology and fast cars. It’s hard to be passionate about these two and not lust after a GT-R so after some years of lusting, I bought one. Being a technology blog, it wouldn’t be right not to share some of the goodness found within this machine so allow me to give you a taste of what happens when you cram enough cycles of computing power into four wheels and forgive me if the excitement boils over just a little b...

I’ve been doing a number of smaller presentations to user groups and private audiences lately and one of the things I’ve been focussing on is trying to give a sense of how fundamentally broken the security of much of what we’re working with is. I’ve been focussing on three areas: broken web (easily discoverable flaws), broken developers (fundamental misunderstandings about important security concepts) and broken devices (vulnerable equipment on the web). This presentation was to the CIAOPS Virt...

This content is now available in the Pluralsight course "Secure Account Management Fundamentals" [http://www.pluralsight.com/courses/secure-account-management-fundamentals] Here’s the scenario – a user logs in to your website, comes back tomorrow and… has to log in again. The idea of the “remember me” feature – and let’s face it, we’ve all seen this before – is that their authenticated state is persisted beyond the immediate scope of use. What this means is that they can close the browser, turn...

A little while back I wrote about Hacking yourself first [https://www.troyhunt.com/2013/05/hack-yourself-first-how-to-go-on.html] and detailed a bunch of different ways for developers to seek out risks in their own apps, hopefully before attackers find them first. I’m extremely enthusiastic about this approach and believe that developers need to hone cyber-offence skills in order to properly understand – and protect their apps from – risks on the web. There’s a heap more content coming from me a...

I’ve been writing a bunch of content around HTTPS lately and recording videos to demonstrate the ease with which insecure implementations of SSL can be broken. For example, there was the piece on why you can’t trust SSL logos [https://www.troyhunt.com/2013/05/heres-why-you-cant-trust-ssl-logos-on.html], then how loading login forms over HTTP but posting to HTTPS is pointless [https://www.troyhunt.com/2013/05/your-login-form-posts-to-https-but-you.html] and most recently, why those mixed content...

Here’s the thing about security – you can’t just “do it” then move on. What I mean by this is that it’s a continuous process and thinking that you only need to just implement some secure coding standards or scan the website once before go live leaves a great big hole in your process. For example, the other day I wrote about how insecurity is easy [https://www.troyhunt.com/2013/05/security-is-hard-insecurity-is-easy.html] where I talked about how Black and Decker had exposed ELMAH logs. This is...

Ever see one of these? Or these? Or maybe this one? It means something is wrong with the website – very wrong – yet somehow we seem to keep building websites that do this. The problem, as you’ll see in the video below, is that it jeopardises the security of traffic going backwards and forwards over what otherwise appears to be a secure site, at least in terms of implementing SSL. This can lead to issues such as the theft of identity data, potentially including such personal information...

Cross site scripting (henceforth referred to as XSS) is one of those attacks that’s both extremely prevalent (remember, it’s number 2 on the OWASP Top 10 [https://www.troyhunt.com/2010/05/owasp-top-10-for-net-developers-part-2.html]) and frequently misunderstood. You’ll very often see some attempt at mitigating the risk but then find it’s easily circumvented because the developers weren’t fully aware of the attack vectors. Last week someone flicked me over a great example of this after having r...

There’s this debate that goes round and round about a process that’s commonly known as responsible disclosure or in other words, notifying the owner of a system that their security sucks and giving them the opportunity to fix it rather than telling the great unwashed masses and letting them have at a vulnerable system. The theory goes that responsible disclosure is the ethical thing to do whilst airing website security dirty laundry publicly makes you an irresponsible cowboy, or something to th...

One could argue that security is hard. Not all aspects of it, mind you, but the prevalence of website hacks would seem to indicate that plenty of people are struggling to get it right. On the other hand, insecurity can be very easy. What I mean by this is that sometimes it can be the smallest change to a website that blows the security wide open. Last week someone passed me a private note about Black and Decker, or more to the point, they passed me a link to an unsecured ELMAH log. For the uni...