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

I’ve been considering purchasing one of these t-shirts:

 

This shirt would announce to everyone who crosses my path that I am, in fact, the world’s greatest lover. They would know this because I have a t-shirt that tells them so and it would give them enormous confidence in my sexual prowess.

If ever I was challenged on the claim, I could quite rightly say that nobody has ever demonstrated that this is not the case and there are no proven incidents that disprove it.

Sound ridiculous? Of course it is but somehow we’ve come to accept this practice – or at least tolerate it – by virtue of images like these:

I’m pushing the “Publish” button on this just before I go on stage at Web Directions Code because all things going well, what I’m going to talk about in this post will form part of my demo about securing web services.

I’m making some (admittedly very simple) code available and providing some resources that will hopefully help everything I talk about with regards to unprotected wireless traffic make sense. I’d like to begin by introducing you to Pineapple Surprise!

Wait – what?! Where’s my Stack Overflow?! I mean I’m seeing stackoverflow.com in the address bar, what’s going on here?! It gets worse:

That little usr cookie down the bottom – that’s the money shot. Create a cookie in the browser with that name and value while the session is active (yes, it has expired just in case you were wondering) and wammo! You’re now me on Stack Overflow. You can go and respond to every security question about encryption and tell them to use ROT13, you can abuse Jon Skeet for not knowing his covariants from his contravariants and you can respond to any question about “How do I use ASP.NET to…” by telling them to use SharePoint. Except it’s not you saying that, it’s me and I’ll cop the abuse for it.

Let me explain what’s happening here.

I’ve been a little bit busy the last few months and here’s why – my first Pluralsight course, the OWASP Top 10 Web Application Security Risks for ASP.NET. Actually, if I’m honest, it’s been a lot longer than that in the making as my writing about the OWASP Top 10 goes all the way back to right on three years ago now. It begin with the blog series followed by the free eBook then last year the instructor lead training for QA and now finally, a complete online video course via Pluralsight.

For the uninitiated, Pluralsight is what they call “hardcore developer training” and it’s predominantly produced by fellow MVPs, community leaders and other subject matter experts who many of you would be very familiar with (there’s a great little article on TechCrunch with a very glowing overview of Pluralsight here). The quality of Pluralsight’s authors really are top notch and it is an honour to be able to contribute to my own little corner of expertise. The content is subscription based and starts at only $29 per month (and there’s a free 10 day, 200 minute trial if you’re not sure). You can watch it online via the browser or native clients for a variety of devices and depending on your subscription level, even save the courses offline.

Pluralsight as a training service is an absolutely fantastic resource and one I have used on many, many different occasions now. The breadth of content is huge and includes everything from the latest enhancements to ASP.NET 4.5, nitty gritty detail about LINQ, lots of fancy tricks in Entity Framework and a heap more in the ASP.NET space. Then of course you’ve got everything you could want to know about client technologies such as jQuery, CSS, HTML and on and on. Take a spin through the top courses and you start to get a sense of the breadth of content.

One thing I’ve learnt working with a bunch of different people over the years is that everyone has their own style of learning. We all like absorbing information in different ways and what I like about the structure of Pluralsight is that you have the choice to either sit through an entire course and go through in a very structured fashion, pick just one module on a discrete topic and learn everything about it or drill down even further and just pick one clip from within the module.

I’ve used each of these approaches in the past, most recently when I really wanted to get up to speed on Entity Framework 5 enum support. There’s plenty of info out there on this but I knew that Julie Lerman is the person when it comes to EF so I spent 6 minutes watching that topic in her Getting Started with Entity Framework 5 course and had exactly what I needed to, well, get started!

Let me tell you a little more about what I’ve created.

Just over a year ago to the day, my wife and I walked into the Apple store in Sydney’s CBD and bought her a shiny new MacBook Air. Macs weren’t familiar territory for us so we happily accepted the offer for a staff member to walk us through some of the nuts and bolts of OSX. That was a handy little starter and we left the store none the wiser that the machine now had a serious security risk that wouldn’t become apparent for another year.

A couple of weeks ago I wrote about my new favourite device, the Wi-Fi Pineapple. Despite its friendly tropical name, the Pineapple is a piece of cigarette-pack-sized professional security equipment I picked up online for $100 to help me demonstrate secure coding practices. Specifically, it’s helping me educate web developers about the risk of not using encryption between browsers and the websites they’re communicating with, something that needs to be built into the design of the site itself.

Among various party tricks packed into this little piece of equipment is a feature called “Karma” and it works like this: When you connect a device to a wireless network – let’s imagine the network is named “WILSON” for the purposes of demonstration – the device then continues to look for that network for perpetuity. What that means is that the device (laptop, smart phone, tablet, etc.) is running around shouting “WILSON, WILSON, where are you WILSON?” What Karma says when it hears this is “I’m Wilson, let’s get connected” and if WILSON wasn’t originally secured with a wireless password, the device connects to the Pineapple automatically. It now looks just like a normal wireless connection and it has been made without any action whatsoever on the user’s behalf.

You didn’t know this could happen? It’s written right there on the wireless network screen of every iOS device, albeit without explaining that “Known” means nothing more than an access point claiming to be exactly what the device has just publicly broadcast it’s looking for:

So what’s the risk of a device connecting to the Pineapple (or any similar equipment – it’s not the only one) without knowing it? It means that every single byte of data that passes through that connection and is not encrypted can be read or changed by an attacker. Passwords, personal information, photos, videos and anything else not properly protected by the website can be intercepted. Links to secure login pages, documents, emails and even banking websites can be manipulated when that protection doesn’t exist.

What’s now evident is that a large number of devices are leaving Apple stores after having been connected to an insecure network leaving them at risk for years to come. Let me explain.

You know how security people get all uppity about SSL this and SSL that? Stuff like posting creds over HTTPS isn’t enough, you have to load login forms over HTTPS as well and then you can’t send auth cookies over HTTP because they’ll get sniffed and sessions hijacked and so on and so forth. This is all pretty much security people rhetoric designed to instil fear but without a whole lot of practical basis, right?

That’s an easy assumption to make because it’s hard to observe the risk of insufficient transport layer protection being exploited, at least compared to something like XSS or SQL injection. But it turns out that exploiting unprotected network traffic can actually be extremely simple, you just need to have the right gear. Say hello to my little friend:

 

This, quite clearly, is a Pineapple. But it’s not just any pineapple, it’s a Wi-Fi Pineapple and it has some very impressive party tricks that will help the naysayers understand the real risk of insufficient transport layer protection in web applications which, hopefully, will ultimately help them build safer sites. Let me demonstrate.

HTTPS or SSL or TLS or whatever you want to call it can be a confusing beast. Some say it’s just about protecting your password and banking info whilst the packets are flying around the web but I’ve long said that SSL is not about encryption.

As an indication of how tricky the whole situation is, OWASP talks about insufficient transport layer security. Not “have you done it right” or “have you done it wrong”, rather have you considered all the little nuances that go into the correct implementation of this invaluable security feature.

Naturally, when this tweet from Mark Hemmings popped up on my timeline was a little intrigued:

We’ve all seen this before right? Clearly it means your valuable password is being sent over the wire in plain text and the ghosts in the wires will immediately harvest them and do frightful things with them, won’t they? Apparently not:

This is not your usual customer service rhetoric – these guys know about iFrames! They continue:

The key here is the word “key” in that sentence. Hang on – so other pages aren’t sent over secure connections? What happens if you’re already logged on?

This is a great opportunity to revisit the quirks of HTTPS because as it turns out, Mark is spot on and there are some very insufficient practices going on here. Let me break it down into 5 discrete problems and why each one of them undermines the HTTPS implementation not just on Top CashBack, but on many other sites following the same patterns.