RunAs Radio interviews me about Cardspace

Recently I was interviewed by Richard Campbell and Greg Hughs on RunAsRadio. You might have heard of Richard... he's also the host of .Net Rocks!. Where .NET Rocks! is for developers, RunAsRadio is for IT Pros.

Anyways, if you would like to listen to the interview we did on Cardspace, you can download it here. Its about a half hour long, and is a simple introduction to the world of Cardspace, atleast for the client side perspective.

For those already versed in the subject, you will notice a few term definition problems in the interview. It went by so fast, and I didn't make it clear what I was getting at. For those that don't know, here is a primer that may help understand how I talk about digital identity:

• InfoCard : An information card. The previous code name for Cardspace
  
• Identity Card: Generic term to mean a piece of digital information that represents your identity
  
• Identity Provider: As the name implies, a provider of one's digital identity.
  
• Relying Party: A system/application that relies on a digital identity for authentication, and possibly authorization. It is up to this party to decide which Identity Provider(s) it is willing to trust. ie: Web site, LOB app etc
  
• Claim: An assertion of a piece of information belonging to an identity. ie: username, password, age, phone number etc.
  
• Wallet: A piece of software that holds Identity Cards. Vista ships with a wallet that holds Information Cards. You can also download it for XP.
  

In a couple of places I used the term "credential" where I was really talking about "claims". And in passing it may sound like I was saying its the Identity Providers (IdP) role to decide who to trust. That didn't come out right. It is up to the relying party to decide which IdP it wishes to trust. In some cases, it will trust you, because you act as the provider. How? Because when you create a a self-issued card and submit it, you are asserting you are who you say you are. It won't be as trusted as much as say... a government IdP. But you get the point. I hope Kim doesn't think about throwing a brick at my head if he hears the interview :)

Anyways, fun interview. Richard and Greg have asked me to come back and do another one where we can explore the server side of things... and discuss how Relying Parties and Identity Providers really work. We may even get into some discussion about Longhorn server and some of the interesting bits there that can be leveraged for the new digital identity ecosystem. Until then... enjoy!

Javascript Hijacking provides new class of attack vectors for AJAX, and ultimately, ATLAS.

As more "Web 2.0" applications become popular, we continue to see richer and richer user experiences (UX) that astound us. To make UX snappy UI controls leverage technology like AJAX to offer support for better interactive experiences. We all know and love it. Who DOESN'T? I remember the first time I saw the scrolling on Google Maps. I couldn't believe my eyes.

But that comes at a price. People who listen to me speak know I am NOT a fan of melding data and code together. What you get at the data layer should NOT be what you see at the presentation layer. We see so many attack patterns that leverage this to their advantage. From the WMF vulnerability to origins of Office macro hell (and everythng in between), its just not a good idea to do this.

In the Web 2.0 world it gets worse. To get those speed increases developers leverage low overhead round tripping with AJAX interfaces. For those that don't know, AJAX stands for 'Asynchronous Javascript and XML'. The problem is, people are forgetting to keep constructs in XML and are spending more time leveraging the Javascript. And that gets me to this post.

The guys over at Fortify have released a research paper showing the weakness in this approach, and shows how easy it is to build on cross site request forgery to hijack Javascript. And as they point out in their research, this isn't a theoretical attack. We have already seen this in the wild. Remember the exploit for GMail recently? Google was serving the current GMail users’ contacts in unprotected JavaScript, so an attacker could steal the contact list using JavaScript Hijacking. Google has since fixed the problem for GMail, but to my understanding its actually a vulnerability that exists in their Google Web Toolkit API, and is not yet fixed. (Although I am told its being fixed as we speak).

And Microsoft's Atlas framework is not immune either. Although they HAVE made it more difficult to attack, it is still possible to generate a request from a malicious <script> tag with a HTTP GET request. Actually, I recall a few ASP.NET MVPs suggesting in public newsgroups to use GET for performance gains. There is a trade off in doing that; you expose yourself to these types of attacks.

The Fortify guys do a good job in explaining the problem, and better yet, defining how to SOLVE it. I hope Microsoft looks at this new class of attack and creates a mitigation strategy soonest for the Atlas platform.

Right now a work around that twarts this attack vector is to append the current session cookie to each request that returns Javascript. This will defeat the underlying cross site request forgery in the first place, and makes Javascript Hijacking moot since the server can validate the origin of the request. Since ATLAS provides the server-side support for this, it won't be difficult for Microsoft to do this. Predictably, MSRC will first have to threat model this class of attack before making any sort of recommendation for fixing the underlying problem.

Consider my post an early warning to the problem, and an echo of Fortify's research on how to mitigate the risks of this attack. If you are building web applications that use ATLAS, you need to consider this attack vector in your own threat models, and take action to mitigate the problem as you see fit.