And now for my fourth Pluralsight instalment: more OWASP! Wait – hasn’t this been done already?! Yes and no.

My first course from April last year was OWASP Top 10 Web Application Security Risks for ASP.NET and as the title suggests, it contains a heap of stuff on how OWASP applies to ASP.NET. In fact it contains so much stuff that it’s over 8 hours of in-depth training for developers on (almost) everything they need to know to protect their .NET web apps. By all accounts, the course has been extremely popular and has formed the basis for many an organisation’s default set of developer training resources. It’s also rated extremely well – month on month the viewership is going up and it’s rated 4.8 out of 5 by the hundreds of people that have taken the time to score it.

The big change with this latest course is that it is designed to appeal to a much broader audience in terms of both depth (detail of code) and breadth (range of technology stacks). In fact Pluralsight approached me to create this course based on popular demand for a “Big Picture” resource that could be consumed not just by those writing the code, but by their managers and their manager’s manager and basically anyone who has a vested interest in the security of their web assets. You can live in PowerPoint and Outlook and this will still make sense!

The way I decided to approach this is to stick to illustrations and higher-level explanations of each risk. I used the 2013 edition of the Top 10 this time (the previous course was the 2010 edition, although the content is very similar) and I broke each of the Top 10 risks into four parts. Let me explain:

Firstly, I give an overview of the risk explaining the attack vectors, security weaknesses and technical impacts. This is straight out of OWASP’s material and it helps contextualise the relative severity of each risk. I also outline a very high-level attack scenario. Here’s what it looks like for injection:

The second part of each module (each of the Top 10 risks have their own module) talks about understanding the risk in more detail. Of course it’s all accompanied by narration and transitions, but here’s the sort of thing I talk about with CSRF:

But of course all this is only any good if you get some guidance on how to protect against the risk so I outline 3 key areas in each module to be conscious of. This is technology agnostic and for people responsible for actually churning out code, they’ll want to then delve into the earlier course on OWASP for ASP.NET or locate other resources for other technology stacks. Here’s what the common defences section looks like:

Finally, I’m a very firm believer that people really only understand the significance of security when they see it go wrong. This is why I do so many demos both on my blog and at conferences and it’s always a big hit. For this course, I’ve pulled real world examples of where each risk has been exploited in spectacular style, for example the Facebook et al credential harvesting via the Tunisian government due to lack of SSL on the login pages (this was even when it posted credentials in a secure fashion):

I wrote this course over January and February and what really struck me at the time was the number of high profile attacks that occurred literally whilst I was recording; Target, SnapChat, Bell, Tesco, KickStarter and only just before that the mother of all customer data leaks – Adobe. It got so coincidental that on the morning of Saturday Feb 15, I recorded the 9th module on using components with known vulnerabilities and gave an example of the risks within older versions of WordPress admin facilities. At that very same time, over a million Forbes accounts were publicly released by the Syrian Electronic Army who also posted screen grabs of… a compromised WordPress admin facility.

It struck me just how relevant and timely this course was when I looked at the very recent attacks and how they aligned to precisely the material in this course:

Snapchat leaked 4.6 million usernames and phone numbers by allowing their service to be brute-force queries by direct object reference (the phone number). Whilst the service needed to provide some facilities to query by phone number, there were insufficient protections to prevent the subsequent exploitation of the service.

A9 – Using components with known vulnerabilities

The example above on Forbes – while the detail is still scratchy, they appear to have been running an out-dated WordPress version at risk of having the admin facility exploited. (There’s since been an article written by Forbes titled How The Syrian Electronic Army Hacked Us: A Detailed Timeline that outlines a raft of other security failures).

Now I’m not saying these events wouldn’t have happened if the impacted parties had watched this course… hang on, no, that’s exactly what I’m saying! Each one of these risks is clearly outlined by OWASP and in turn, appears in my course. All the information needed to identify and mitigate these risks is outlined in the course in such a way that the folks holding the purse strings can get what it’s about and what may happen if they don’t get it right.