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 where I talked about how Black and Decker had exposed ELMAH logs. This is the tiniest of security misconfigurations which can easily happen at any time but it meant that they ended up with the credentials from a significant portion of their customer base publicly accessible – ouch! Ok, this also involved storing plain text passwords in cookies in order to facilitate the “remember me” function (no, really), but the point is in how easy it was to make a simple change that blew a massive hole in the side of their security profile.

This brings me to the point of the post: security misconfiguration happens and you need to start looking for it bang after you publish the site. Exposed ELMAH logs is one thing but simple security misconfiguration changes you can screw up on release of an ASP.NET website go well beyond that; custom errors, tracing, request validation and the way your cookies are configured to name but a few. Each of these can be configured to leave a site vulnerable in literally just a few seconds.

For the last couple of years I’ve provided a service to detect these problems in a live site – ASafaWeb. The value proposition of ASafaWeb has always been that on demand, you can scan your live ASP.NET website and it will report on these security misconfigurations. Now I’m very happy to share how ASafaWeb has been integrated into OnCheckin (the brainchild of Doug Rathbone) to provide continuous deployment for ASP.NET websites as a cloud-based service.

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 as social security numbers. Fortunately there’s a channel to report potentially fraudulent activity except that, well, this video explains it best:

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) 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 read my previous post Here’s why we keep getting hacked – clear and present Billabong failures. In that post I pointed out the ease with which you could decorate Billabong’s registration page with the beautiful Miranda Kerr and a slightly stoned looking Bugs Bunny. In this post here, the ramifications of getting XSS wrong means stealing someone’s session and pulling out their personal details, all because of this:

I’ll come back to that, let’s first go back to the title and focus on input sanitisation and output encoding contexts. If XSS is an entirely new concept to you, start by taking a look at my post on it here then come back to this one.

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

But of course these things are not black and white. On a daily basis I’ll see tweets about how a website is storing credentials in plain text: “Hey [insert name here], what’s the go with emailing my password, aren’t you protecting it?”. Is this “responsible”? I think it’s fair to say it’s not irresponsible, I mean the risk is obvious, right?

How about security risks such as an XSS flaw which might be a little more grey, but is still shared frequently in public? It’s not exactly going to land you the mother lode of sensitive data in a couple of clicks, but it could be used as part of a more sophisticated attack. Or move right on to the other end of the scale where serious flaws lead to serious breaches. It might be default credentials on an admin system or publicly accessible backups, the point is it’s in another realm of risk and impact altogether.

Anyway, the reason for this post is that a number of events over recent times have given me pause for what I consider responsible disclosure. These events are numerous and include incidents where I’ve ticked every responsibility box in the book and incidents where I’ve been accused of being, well, a cowboy. I wanted to capture – with as much cohesion as possible – what I consider to be responsible disclosure because sure enough, I’ll be called on this again in the future and I want to have a clear point of view that simply won’t fit into 140 characters.

I’d like to start with two disclosure stories that took very different tacks with different outcomes for both the sites and me personally. Here’s what happened:

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 uninitiated, ELMAH logs and their discovery via Google is something I’ve written about before. In fact in this very case it was someone simply searching for some info on ELMAH that lead to this discovery – it’s that easy.

Now I want to stress that this is not intended to be all about Black and Decker and before posting this I did privately contact them and they have now correctly secured the logs. In fact there are tens of thousands of Google results for publicly exposed ELMAH logs so clearly this is a very prevalent risk. Let me first share the video on what you can do with exposed ELMAH logs then I’ll come back around to the point of this post:

For many of you, Scott Hanselman will need no introduction and is a very familiar face, voice and writer. Among the many good things that Scott does to support the web development community (and that’s not just the Microsoft folks either), he’s also the man behind the Hanselminutes podcast which I was very happy to join him on recently. In fact this remains one of the very few podcasts where I actually listen to every episode – regardless of the direct relevance to me – simply because it’s delivered in such a professional manner and I know I’m going to learn something each time.

The podcast has gone out under the title Are you secure? WiFi Honeypots, Pineapples and SSL with Troy Hunt which is pretty self-explanatory. As per the title, we mostly discuss the risks presented by using public wifi plus the importance of HTTPS for those of us who are building web apps. Let me share some supplementary material which I’ve either touched on in that talk or will be of relevance to interested listeners:

1. SSL is not about encryption
2. OWASP Top 10 for .NET developers part 9: Insufficient Transport Layer Protection
3. 5 ways to implement HTTPS in an insufficient manner (and leak sensitive data)
4. Your login form posts to HTTPS, but you blew it when you loaded it over HTTP
5. The beginners guide to breaking website security with nothing more than a Pineapple
6. Pineapple Surprise! Mixing trusting devices with sneaky Wi-Fi at #wdc13

There’s a lot more related content beneath those but that’s a good starting point. I hope you enjoy the podcast!

Here’s an often held conversation between concerned website user and site owner:

User: “Hey mate, your website isn’t using SSL when I enter my password, what gives?!”

Owner: “Ah, but it posts to HTTPS so your password is secure! We take security seriously. Our measures are robust.” (and other random, unquantifiable claims)

Loading login forms over HTTP renders any downstream transport layer security almost entirely useless. Rather than just tell you what’s wrong with this, let me show precisely why this is with a site that implements this pattern:

The unfortunate reality of the web today is that you’re going to get hacked. Statistically speaking at least, the odds of you having a website without a serious security risk are very low – 14% according to WhiteHat’s State of Web Security report from a couple of weeks ago. Have enough websites for long enough (as many organisations do), and the chances of you getting out unscathed aren’t real good.

There’s this great TEDx talk by Jeremiah Grossman titled Hack Yourself First where he talks about the importance of actively seeking out vulnerabilities in your own software before the evildoers do it for you. In Jeremiah’s post about the talk, he makes a very salient point:

Hack Yourself First advocates building up our cyber-offense skills, and focusing these skills inward at ourselves, to find and fix security issues before the bad guys find and exploit them.

I love this angle – the angle that empowers the individual to go out and seek out risks in their own assets – as it’s a far more proactive, constructive approach than the one we so often see today which is the “after it breaks, I’ll fix it” approach. Perhaps that’s not always a conscious decision but it all too often turns out to be the case. It also advocates for the folks writing our apps to develop the skills required to break them which is a big part of what I’ve been advocating for some time now and features heavily in many posts on this blog as well as throughout the Pluralsight training I recently released. If developers do not understand the risk – I mean really understand it to the point where they know how to exploit it – then you’re fighting an uphill battle in terms of getting them to understand the value of secure coding.

It’s not just the dedicated security folks talking about hacking yourself first. The other day I was listening to Scott Hanselman talking about WordPress security on his podcast and he made the following point:

I know when I’m writing code I’m not thinking about evil, I’m just trying to think about functionality.

Which of course is perfectly naturally for most developers – we build stuff. Other people break stuff! But he goes on to say:

When was the last time I sat down and spent a day or a week trying to break my site?

And we’re back to hacking yourself first or in other words, making a concerted attempt to find vulnerabilities in your own code before someone else does. As Jeremiah referred to it, building up cyber-offense skills for developers. Developing the ability to detect these risks is easy once you know what to look for, in fact many of them are staring you right in the face when you browse a website and that’s what I want to talk about here today.

Let me share my top picks of website security fundamentals that you can check on any site right now without doing anything that a reasonable person would consider “hacking”. I make this point for two reasons: firstly, you really don’t want to go messing up things in your own live site and testing for risks such as SQL injection has every chance of doing just that if a risk is present. The other reason is that by picking non-invasive risks you can assess them on other peoples’ sites. I’ll come back to why I’m saying this and the context it can be used in at the end of this post, the point is that these are by no means malicious tests, think of them as the gateway drug to identifying more serious risks.

This is going to be a lengthy one so let me give you a little index to get you started:

1. Lack of transport layer protection for sensitive data
2. Loading login forms over an insecure channel
3. Secure cookies
4. Mixed mode HTTP and HTTPS
5. Cross Site Scripting (XSS)
6. Password reminders via email
7. Insecure password storage
8. Poor password entropy rules
9. Denial of service via password reset
10. HTTP only cookies
11. Internal server error messages
12. Path disclosure via robots.txt
13. Sensitive data leakage via HTML source
14. Parameter tampering
15. Clickjacking and the X-Frame-Options header
16. Cross Site Request Forgery (CSRF)

Remember, every one of these is remotely detectable and you can find them in any website with nothing more than a browser. They’re also web platform agnostic so everything you read here is equally relevant to ASP.NET as it is PHP as it is Java – there are no favourites here! I’m going to draw on lots of examples from previous posts and live websites to bring this back down to earth and avoid focussing on theory alone. Let’s get into it.

XSS protection: check!

No SQL injection: check!

Proper use of HTTPS: check!

Clickjacking defences: uh, click what now?!

This is one of those risks which doesn’t tend to get a lot of coverage but it can be a malicious little bugger when exploited by an attacker. Originally described by Jeremiah Grossman of WhiteHat Security fame back in 2008, a clickjacking attack relies on creating a veneer of authenticity under which lies a more sinister objective.

Imagine you visit a website and see the following:

Free stuff is always good so you click on the big button and WAMMO! You’ve just been clickjacked. You see, whilst you think you just clicked a “WIN” link, in reality you just clicked this instead:

This, of course, is your bank. You are logged in and your bank provides a handy option to transfer all your money with a single click. But of course you don’t know you you’ve just given Mr Dotcom all your money because you never even saw the link. This is a very simple example of a clickjacking attack, let’s take a look at the mechanism underneath and then talk about defences.

A couple of days ago I wrote about Why I am the world’s greatest lover (and other worthless security claims) and it  really seemed to resonate with people. In short, whacking a seal on your website that talks about security awesomeness in no way causes security awesomeness. Andy Gambles gets that and shared this tweet with me:

So let’s check out exactly what’s going on here and you really need video to understand the fatal flaw in the logic of SSL logos coming down over HTTPS:

So there you go – it can be that simple. How I MiTM’d the page so easily is not really the point, the point is that an SSL logo on an unprotected page is as good as worthless (and frankly they’re not much good on protected pages either).