Back in September last year we saw the emergence of the padding oracle vulnerability which suddenly got a whole lot of ASP.NET developers very nervous. The real concern with this vulnerability was that there really wasn’t much you could do at the code level beyond a couple of little tweaks – what was really needed was for patches to get installed on servers and fast.

The problem back then was that, well, you couldn’t always trust your hosting provider. Hosting providers take all sorts of different shapes; corporate servers managed by IT groups, dedicated machines with dedicated hosts, shared co-tenanted machines and now more and more frequently, cloud based solutions. But one thing remained constant and that was that the patch Microsoft had quickly released needed to get onto the machine.

Back then I talked on my blog about how to remotely detect the patch. But what I didn’t talk about was that I’d written an app to automate this check. Like many with responsibility for a number of sites, I was too busy making sure things were patched to get that little piece of software into a form suitable for sharing. Today, things are a little different…

Just when you start thinking we’ve seen out the last of the major security breaches for 2011, Christmas day brings us one final whopper for the year: Stratfor. Much has already been said about why they might have been hacked and who might (or might not) have done it, but the fact remains that there are now tens of thousands of customer passwords and credit card details floating around the web. Oh, and apparently about 5 million internal emails ready to be released.

So what do we take from this as website builders? The benefit of hindsight gives us a good opportunity for reflection as we watch the fallout unfold from the last major breach of the year. Let me share the 5 lessons I’m taking away from this.

This entire series is now available as a Pluralsight course.

Writing this series was an epic adventure in all senses of the word:

Duration – 19 months to complete a blog series, for crying out loud!

Content – approaching 50,000 words, not including all the discussion in comments.

Effort – some of the posts, such as transport layer security, probably approached 100 hours of reading, trialling, experimenting and finally, writing and proofing. This is why there was a four month “hiatus” before that post!

But most of all, it was an epic learning adventure for me. Writing the series forced me to know this content in depth, not just the depth that facilitates casual conversation and allows me to send people off to figure out how to fix their flaws, but the depth to really get to grips with these risks, ensure I could exploit them and then make sure I could fix them again.

For example, I knew – and many of us know – that unsalted hashes are vulnerable to a rainbow attack but I’d never actually executed one of these attacks myself. So I did. Same again on sniffing packets; knowing that lack of transport protection leaves network traffic vulnerable is one thing, sitting in the car outside McDonald’s and actually capturing wifi traffic and hijacking the session (my own, that is!) is another thing altogether.

Looking back on it, I’m really happy with what I’ve produced. It’s been a great experience for me and by all accounts, it’s been very well received by the .NET and OWASP communities as well. It turns out I might have actually produced something pretty useful!

So I decided to turn it into an eBook. Oh – and give it away for free. No strings attached. So here it is, 255 pages of .NET web development security goodness. Please share it generously, chuck it on your eBook reader, email it to your mates, quote me, force your developers to print and read every page – whatever – it’s all yours:

[ click to download ]

If you find it useful, leave me a comment, flick me an email or fire me through a tweet as the feedback really is appreciated. Happy reading and happy holidays everyone.

This entire series is now available as a Pluralsight course.

And also as a free eBook.

In the final part of this series we’ll look at the risk of an unvalidated redirect or forward. As this is the last risk in the Top 10, it’s also the lowest risk. Whilst by no means innocuous, the OWASP Risk Rating Methodology has determined that it takes last place in the order.

The practice of unvalidated redirects and forwards, also often referred to as an “open redirect”, appears fairly benign on the surface. However, it can readily be employed in conjunction with a combination of social engineering and other malicious activity such as a fraudulent website designed to elicit personal information or serve malware.

What an unvalidated redirect does is allows an attacker to exploit the trust a user has in a particular domain by using it as a stepping stone to another arbitrary, likely malicious site. Whilst this has the potential to do considerable damage, it’s also a contentious vulnerability which some organisations consciously choose to leave open. Let’s take a look at how it works, how to exploit it then how to protect against it.

I’ve had a lot of conversations with folks recently about web app performance. Often these conversations have been around the assertion that a content distribution network (here forth referred to as a CDN), is something you need to deploy early on in the optimisation process of a website. Personally, I see a CDN as a last resort; it’s what you turn to when all other performance tuning alternatives have been exhausted and you need to eke out that last little bit of latency by moving the content closer to the audience. It’s not a replacement for good website optimisation, it’s an enhancement.

One of the main problems with a CDN is simply this: people still have crap connections. It doesn’t matter if I can put the content in the same city as the audience, if they’re in a location where “broadband” is a 1Mb connection or even if they’ve got a super-fast service but the 3 kids are all simultaneously downloading torrents, you’ve got a problem. How well optimised the site is now matters a lot more than how close the content is to you.

The point I’m making is this: well optimised content is king. If you can get that video down from 2Mb/s to 500Kb/s (sounds like a lot but I frequently see this sort of scenario), or dramatically slash the number of HTTP requests and the content size on a web page, you’re going to reap those benefits under any circumstances. This is where you have to start; get this right first because it’s the fastest, cheapest way to add performance.

So it got me thinking: how much improvement can be made on an already well-optimised site, I mean one that scores very well against existing performance yardsticks? How much faster can you go without spending dollars on a CDN? Turns out there are big gains to be made very quickly – and it costs just a tiny bit of development time.

Websites get hacked. Lots. This year alone we’re looking at some absolute whoppers; Sony, EVE Online, Sony, pron.com, Sony, MySQL.com, did I mention Sony?

Many times, the gateway to successful website exploits is simple misconfiguration. Custom errors were left off and thus leaked internal code. Or request validation was turned off which opened up an XSS flaw. These risks are often then leveraged to do other nasty stuff.

The thing is, many of these are also easily remotely detectable – certainly the bad guys know this. What I mean is that configuration vulnerabilities are apparent just by making the right requests to the website. Not “hacking” it in any sort of malicious context, just simply making some innocuous requests and inspecting the responses. This is what ASafaWeb does – the Automated Security Analyser for ASP.NET Website - and I’m very happy to now introduce it at asafaweb.com