As part of my general wish to be a good netizen and advocate of website security, I made a responsible disclosure the other day, you know, the kind where you privately email an organisation and pass on security flaws in their online presence that they might not otherwise be aware of. Anyway, the response was, well, you decide: > To date we've not had a single security issue stemming from [insert risk I sent to them here] Really? Not a single one? Clearly whatever defences this particular org...

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...