Wednesday, January 25, 2012

.NET Rocks talks security with Carl, Richard and Troy

Wednesday, January 25, 2012

Yep, this Troy! Right at the tail end of my Christmas holidays a couple of weeks back I had the pleasure of having a great chat with these guys:

image

In case you’ve been living under a rock (no pun intended), for the last nine and a half years, .NET Rocks is without doubt the foremost .NET themed podcast in the universe. By the time they got to me, there had already been 734 prior episodes (frequently running for an hour or more), so the series has well and truly become ingrained in the psyche of many a .NET developer. How many developers? Apparently about 250,000; yes one-quarter-of-a-million-.NET-developers. Wow!

For me, over the last few years it’s been one of the very, very few podcasts where I’ll religiously listen to every episode, regardless of the content. Carl and Richard have become a part of my daily drives, long flights and exercise regimes on a pretty regular basis.

My talk came at a good time for application security (depending on your perspective). We’d just capped off a year of unprecedented website hacking and just when we thought it was all over, along came Stratfor and then the hash DoS situation. During this time I also wrapped up the OWASP Top 10 for .NET developers series, packaged it all into a nice little eBook and launched ASafaWeb.

In the show we talk about each of the OWASP Top 10 web application security risks and how to mitigate them in .NET plus head off on a few tangents about some recent hacks, password management and the all-important pronunciation of “ASafaWeb” and “OWASP”. I had a ball recording the show (despite my internet failing and having to resort to Skype on iPhone over 3G), and every impression I had of Carl and Richard was reinforced both on and off the air. Great guys who love their technology and are passionate about sharing it with anyone who’ll listen.

So here it is, enjoy!

Episode 735 – Troy Hunt Secures ASP.NET

Monday, January 23, 2012

Breaking CAPTCHA with automated humans

Monday, January 23, 2012

We’re all familiar with CAPTCHA right? That impenetrable fortress of crazy squiggly characters that only a real human can decipher. Whilst they tend to drive us a bit nuts, they do actually provide a valuable function in that they prevent the automation of requests against online services. For example, you can’t get yourself a Google account without first wrapping your head around what on earth this one says:

CAPTCHA before creating a Google account

Why does Google do this? Well, once you create yourself a Google account you’ve now got GMail and G+ and all sorts of other platforms which could be used to perform such nefarious activities as generating spam, distributing malware or creating false identities. Once you can automate this, these activities can be performed en masse.

It’s a similar deal with Western Union:

Western Union's CAPTCHA

It’s easy to imagine that being able to automatically create accounts at a financial institution might open the gateway to all sorts of monetary shenanigans. And if you’ve already been able to create a GMail account, you’ve got everything you need to begin batching the creation of identities at Western Union.

So CAPTCHA prevents all this, right? Only humans can break the code and complete these signup processes, right? But what if we could automate the humans; I mean what if we could take CAPTCHAs and solve them at such a rate that these registration processes could be easily automated? Well it turns out you can and it will only cost you a couple of bucks.

Read more

Tuesday, January 17, 2012

Zappos, Stratfor, Sony, Gawker; Got your attention? Good, now start using a password manager!

Tuesday, January 17, 2012

Another week, another major security incident with a significant website. So the news this time is that Zappos – those guys who sell shoes (among other things) – to folks in the US may have, uh, accidentally disclosed somewhere in the order of 24 million user accounts. Bugger.

Now of course at the root of this is inevitably yet more evildoers intent on breaking through website security for financial gain, activism or just plain old kicks. Regardless of the modus operandi of these incidents, the fact remains that a significant number of accounts have been exposed and there’s now the real possibility that usernames and passwords – perhaps your username and password – are going to be floating around the internet being seen by who knows how many people.

This, of course, is a problem because statistically there’s a better than average chance you’ve used that password in a number of other locations. Did you use it for eBay? Was it the same one you used for Amazon? Or even worse, is it your Gmail password and it can now be used to reset all your other passwords? If you’re asking yourself any of these questions right now, it’s time for a password manager which makes it dead easy to create strong, unique passwords across all your accounts so that the next time this happens – and there will be a next time – your credential exposure and your risk won’t go beyond that single site.

Read more

Monday, January 9, 2012

ASP.NET session hijacking with Google and ELMAH

Monday, January 9, 2012

I love ELMAH – this is one those libraries which is both beautiful in its simplicity yet powerful in what it allows you to do. Combine the power of ELMAH with the convenience of NuGet and you can be up and running with absolutely invaluable error logging and handling in literally a couple of minutes.

Yet, as the old adage goes, with great power comes great responsibility and if you’re not responsible with how you implement ELMAH, you’re also only a couple of minutes away from making session hijacking of your ASP.NET app – and many other exploits – very, very easy. What’s more, vulnerable apps are only a simple Google search away. Let me demonstrate.

Update: I want to make it clear right up front that the out of the box ELMAH configuration does not make any of what you’re about to read possible. It’s only when ELMAH is configured to expose logs remotely and not properly secured that things go wrong.

Read more