Sponsored by:

It’s time to Hack Yourself First, with help from Pluralsight

Earlier this year I was doing my usual trick of browsing websites and writing about things that were readily observable with regards to some rather ordinary security practices. When I say “readily observable” I’m talking about things such as cookies not flagged as HttpOnly or SSL login forms embedded into HTTP pages. This stuff is just so easy to find because it’s staring you right in the face when you load up a website; yet somehow these problems remain extremely common.

The root cause, of course, is that we don’t know what we don’t know. Many developers are not aware that a cookie not flagged as HttpOnly can be accessed via some sneaky JavaScript injected into the page via an XSS flaw. They also haven’t thought through the process of how an HTTP page may be manipulated by a man in the middle such that it serves a rogue login form and the user is none the wiser. And how many people have really thought about the execution of a clickjacking attack? And for that matter, how many people realise that you can mitigate it with a single response header?

I wrote about a bunch of these risks earlier in the year in the blog post titled Hack yourself first – how to go on the offence before online attackers do. (Hat tip again to Jeremiah Grossman’s talk that inspired the use of this term – with his blessing!) This was partly to start consolidating info in one place and partly to feel out how it might all flow together with a view to turning it into a useful course – and that’s exactly what I’ve now done so let me share what I’ve created in “Hack Yourself First”, my latest Pluralsight course.

Pluralsight - hardcore developer training

Pluralsight and “the second course”

I first wrote about Pluralsight back in May when I published my first course on the OWASP Top 10 for .NET developers. I’ve been enormously happy with how that course has been received; out of about 550 courses at the time of publishing (it’s now around the 700 mark), it quickly hit number 14 and then settled down to be consistently in the top 10% on the leader board. It’s tracked at an average rating of 4.8 out of 5 since launch and the feedback I’ve had has been nothing but resoundingly positive. A big “thank you” to all those who watched, voted and contacted me afterwards – it has been an enormously fulfilling experience.

That course was very code-centric: go into your C# and look for these patterns then change them to those patterns. It was also strictly aligned to OWASP’s Top 10 and strictly targeted at ASP.NET developers. In some ways, it’s a bit niche and of course that’s just what you need if you’re an ASP.NET developer with access to the codebase! But that’s not always the case – either you’re working with another technology stack (yes, they do exist!) or you simply want to establish the security position of your application as an attacker would view it. You also don’t always have immediate access to the codebase – how many times has someone looked at a website within their own organisation and said “Hang on – I think there might be an issue here”? The answer is “lots” and I know that because people often then contact me and ask if there might be an issue!

This brings me to the course:

Hack Yourself First: How to go on the Cyber-Offence

"Hack Yourself First" is all about developers building up cyber-offence skills and proactively seeking out security vulnerabilities in their own websites before an attacker does.

Oh boy, I said “cyber”! Twice!! Regardless, the sentiment is that there are a whole heap of risks you can readily observe in running web applications just by using tools you’re already familiar with, namely Chrome’s developer tools and Fiddler. The fundamental difference with this course from the previous one is that it comes at security from the attacker’s perspective – they’re external, they have a URL now how can they find risks. Then, most importantly, what do the secure patterns look like and how do they actually defend against the attack I’ve just demonstrated – that’s the key.

As with the first course, I had a, uh, a little blow-out in the duration – it’s nine and a half hours. That wasn’t necessarily the original intention, but once I got going it evolved into a story I wanted to tell and anything less would have made it feel incomplete. Try as I might to be direct and succinct, I just kept getting to the end of modules and going “Alrighty then, I seem to have exceeded an hour again”. So it’s comprehensive!

Do you code angle brackets? Then this course is for you!

I really wanted this course to be cross-cutting and I’m very conscious that when you look at the distribution of frameworks used across websites, ASP.NET only has about a quarter of them:

Distribution of web frameworks pie chart

Microsoft’s framework remains my absolute number one choice for all the stuff I build (it’s been 12 years since I actively used anything else), but by stepping up the stack a couple of notches and focussing on HTML, HTTP and everything between the browser and what the server emits, this course is able to be relevant to a whole new audience. Of course that still includes fellow .NET developers but it also includes that rather significant chunk of the pie above that’s PHP, as well as the smaller players.

If you are a .NET developer, some things will seem a little familiar but the vast majority of content will be all new, if not the risk itself then the processes of discovering and exploiting it.

Learning how to Hack Yourself First

As you’d expect from nine and a half hours, there’s a whole lot of info in this course. In fact just the bullet pointed notes I made amounted to 8,000 words over 32 pages. No really, this is what I’ve spent my nights and weekends looking at for the last few months:

32 pages of notes

So what does all this amount to? Let me summarise a bit more succinctly than what’s above:

  1. Introduction: How to use Chrome’s dev tools to identify risks and how Fiddler can be employed to capture, manipulate and reissue requests including on the fly during both requests and responses just like a real man in the middle would.
  2. Transport Layer Protection: Sniffing cookies to hijack sessions, exploiting forms loaded over HTTP (even when they post to HTTPS) and injecting into insecure content loaded into a secure page to exploit the site.
  3. Cross Site Scripting (XSS): Identifying input sanitisation risks, checking for correct output encoding in various contexts, both reflected and persistent XSS and what the X-XSS-Protection header is all about.
  4. Cookies: The function of HttpOnly and secure cookies, employing path restrictions to the cookie, managing cookie expiration and the role of session cookies.
  5. Internal Implementation Disclosure: Discovering internal frameworks via headers then locating at-risk websites, HTTP fingerprinting, disclosure in robots.txt, identifying vulnerabilities in HTML source, internal error leakage and missing controls on diagnostic data.
  6. Parameter Tampering: Capturing, manipulating then reissuing malicious requests with Fiddler, manipulating and circumventing application logic, looking for missing server side validation, mounting a mass assignment attack, HTTP verb tampering and fuzz testing.
  7. SQL Injection: Testing for risks, disclosing internal database structure, harvesting data, automating attacks with Havij and finally, executing blind SQL injection attacks
  8. Cross Site Attacks: Cross site request forgery and the use of anti-forgery tokens, CSRF risks in APIs, mounting a clickjack attack and using the X-Frame-Options header
  9. Account Management: Password strength, length and character limitations, emailing credentials, account enumeration, denial of service via resets, secure password reset patterns, at-risk “remember me” features, re-authentication and brute forcing logins

That’s all! All of these are approached from an entirely framework-agnostic angle so you can take this course then immediately jump into your PHP app and begin finding risks. There’s such a broad range of info there that you will find risks on your own sites. Of course they’re all of varying severity but you’ll find that one risk tends to feed into another then the whole show begins to unravel. In fact that’s why I built a special website just for this course: Supercar Showdown.

Hacking Supercar Showdown

One thing I really wanted to do with this course was allow developers to experience how one vulnerability leads into another. For example, that XSS flaw may seem pretty minor but combine it with a poorly implemented “remember me” feature and cookies not flagged as HttpOnly and suddenly you’ve got a big problem on your hands. That’s really three discrete risks – XSS (which of course is mitigated in many ways), account management (with regards to the auto login) and cookie security. In order to fully demonstrate this sequence of risks, I created I dedicated website that’s bursting with very common security flaws and because I’m a bit of a fast car guy, I created Supercar Showdown:

Supercar Showdown website

This website allowed me to demonstrate all the sorts of risks I touched on above in one site and what it means is that you go through the entire course with the one application. Each module builds on top of the other and I was very careful to structure it in such a way that by going through it chronologically you gradually get to peel back the layers and discover everything inside the site. That chronology is important and I’d love to see people going through each module in sequence so they’re able to appreciate the process an attacker would go through in order to exploit flaws.

See that obfuscated URL in the address bar of the image above? I’m going to follow this post up with another one in the coming days where I’ll share the address and set you a little challenge. Whether you’re a Pluralsight subscriber or not, this site is going to be accessible to you to have a good poke around in so I’m really interested to see what sort of vulns people find. Stay tuned!

Let’s get web app security into the top 10!

I came oh-so-close with the OWASP course – number 14 out of more than half a thousand courses (doesn’t that sound so much more impressive than “550”?!), but I reckon this one has the legs to make it all the way to the exclusive realm of the Top 10. Yes, yes, I know AngularJS and MVC 4 are awesome and naturally they’re excellent courses, but do you know what’s really awesome? Not getting your shiny new website pwned!

So get in there and start watching the course. If you’re not a Pluralsight subscriber then just grab the free trial which will give you a few hours of viewing time over a week and a half. Frankly though, when it costs less than $1 a day to access 700 odd professionally produced courses, it’s a pretty reasonable investment to stick around a bit longer and absorb more info.

As always – and completely irrespective of this course – I’m around on blog comments, Twitter and email for questions and support in the world of web security. Enjoy!

Security Pluralsight
Tweet Post Share Update Email RSS

Hi, I'm Troy Hunt, I write this blog, create courses for Pluralsight and am a Microsoft Regional Director and MVP who travels the world speaking at events and training technology professionals