Free Azure for MSDN subscribers

Well, som terms apply:

Windows Azure Platform Benefits for MSDN Subscribers

And also a notice of warning:

You'll need your credit card to sign up. If you use more than the amount of services included with your MSDN subscription, we'll bill your card for these overages.

I'll probably take my chances on testing the cloud next year, despite the credit card warning...

All Windows Azure offers can be found here.

A month or two ago I investigated the possibilities for testing out Azure, but I somehow managed to not stumble upon the MSDN subscription option. Either this is a new offering, or my Google skillz were seriously off at the time.

A while ago one of my colleagues tried an Azure subscription, but he quickly realized that the prizing followed the idea of a hotel room. He was charged for the room per its availability, not for its actual use. Not very developer friendly.

For Azure to become a smashing success, it's important that developers get a chance to play with the technology — without committing to a significant bill. I really hope that this Azure subscription is a permanent offering, and that there are controls in place to protect developers from getting burnt on their credit card bills.

I'll start tinkering in the cloud next year — pretty soon that is!

Happy new year! :)

Digging into WIF, or not.

A couple of weeks ago I attended a great talk by Dominick Baier on WIF (Windows Identity Foundation) at an NNUG meeting. I've been contemplating for some time to dig into WIF and learn first hand how just how beneficial the framework is. Mr. Baier's excellent presentation was the final push I needed to start investigating. But behold, WIF is nowhere to be found on my computer (XP, with VS2010). Intense googling revealed that the WIF SDK cannot be installed on Windows XP. From the download page at the Microsoft Download Center:

Supported Operating Systems: Windows 7;Windows Server 2003 Service Pack 2;Windows Server 2008 R2;Windows Server 2008 Service Pack 2;Windows Vista

Too bad. No WIF for me. Time to upgrade from XP I guess.

Please replace the floppy disk

I was typing away in a word document opened directly from my home directory over VPN. Then I got an amazingly cool error message! Apparently I was thrown "offline" for a minute:

"Please restore the network connection or replace the floppy disk and retry."

Nuff said.

Who framed Roger Badbit?

I recently blogged how to mitigate the clickjacking vulnerability with the X-Frames-Options HTTP header. Then XSS-track came to my attention, so I figured it would be a good idea to blog more in general about attacks employing frames. A general post mandates a general and catchy title (you have to agree that it is).

First, a few comments on the idea behind XSS-Track. In general, an XSS vulnerability lets you inject script into a particular webpage. If the user navigates away from this page, you've "lost" her. XSS-track injects script to load the attacked website in an iframe, which then becomes the user's view of the website. The user is left navigating the website in the iframe, which means that the XSS script survives in the parent page — a very elegant trick. By owning one vulnerable page, the clever attacker can gain access to all pages the user visits during a session on the targeted website.

Now to more general considerations on attacks that load your site in an iframe, and how the X-Frames-Options HTTP header can help.

Defeating Clickjacking

The clickjacking vulnerability is receiving an increasing amount of attention. There has been some interesting advances in exploitation techniques, as explained in this video: Next generation clickjacking by Paul Stone at the Blackhat Europe 2010 security conference.

Let's first summarize the basic properties of a clickjacking attack:

1. The attacker can load a page from your website in an iframe
2. The attacker can have the user perform mouse operations on your webpage, i.e. clicking buttons, dragging and dropping content etc.

If we can prevent a webpage from being embedded in an iFrame, the clickjacking vulnerability will be mitigated. Framebusting is the traditional approach to prevent clickjacking attacks — a javascript embedded in a webpage to detect framing and try to "bust out" of the frame.  However, a recent study by researchers at Stanford summarizes common framebusting efforts and concludes that framebusting fails to mitigate the risk.

Lesson learned: HTTP modules can also affect WebResource.axd

HTTP modules can be very useful. In fact, I love them. The scope of this post is unfortunately not to explain what they are or what they do. If you're not familiar with what a HTTP module is, get an overview here and see how to create one here.

ASP.NET features some built in handlers: WebResource.axd and ScriptResource.axd. You'll see requests to these in any ASP.NET application, as they're used to serve builtin scripts for e.g. postback or client side form validation. By default, the ASP.NET application will configure these to expire from cache after a year.

Today I discovered a side effect I had not thought about. HTTP modules are loaded by the application, and are hooked into the event pipeline for each and every request handled by the ASP.NET application. In fact, this also includes requests to the WebResource.axd and ScriptResource.axd handlers!

How to secure ASP.NET cookies

The release of Firesheep a week ago brought a lot of attention to a problem that has been known for many, many years: cookies sent over both secure and insecure connections to the same site. Why all the fuzz now? Well, first of all, "regular" people (as in non-geeks) can install Firesheep and start stealing Facebook sessions. With such a demonstration, people realize just how easy it is to "hack" another user's account. Secondly, we're all on Facebook, so we all feel that this affects us personally. We can relate to the risk, and it stirs our emotions. Thirdly, the media loves these kinds of demonstrations and can capitalize on the fear factor. This hack was simple enough and scaled nicely, which made it a good sell.

Now the debate goes on about Firesheep, here's a good blog post on the ethical aspects. In this post I also found a link to Microsoft's Malware center, their antivirus software apparently detects Firesheep as a hacktool. Like it really matters. Firesheep clones will pop up all over the Internet. The only viable path forward is to build websites not vulnerable to trivial eavesdropping attacks.

Firesheep has raised the bar for baseline security in web applications. Before Firesheep, you would be regarded as sloppy or lazy not to have secured your website's cookies. After the release of Firesheep, you're essentially committing a crime against your users — because now you (and they) know that cookies can easily be stolen.

If you need a basic introduction to what cookies are, check out the cookie article on Wikipedia.  The rest of this post discusses more technical aspects of cookie security.