finally a bnode with a uri

[Shocking headline about OpenID security issue here]

openID and potential XSS attacks
Update: Dag Arneson gives some hints for OpenID server implementors on how to protect their scripts.

Update 2: Brad Choate of the Six Apart crowd informed me that OpenID server implementors are well aware of XSS possibilities. Platforms like Movable Type and Live Journal already use token mechanisms to make sure that received data were sent from a locally created form. I guess when the main server systems are protected, the mentioned security by obscurity effect kicks in again, I assume I could remove the 'shocking' from the blog title ;)

Update 3: The new Drupal versions also support optional form tokens. Blue sky again :)

Disclaimer: I didn't spend time for a more detailed look at the OpenID 2.0 spec, maybe the problem is already addressed (I truly apologise in that case), but danbri suggested to blog it anyway. Here we go.

While working on a distributed identity system for my SemWeb CMS, I had a look at what's already out there. (This sentence is absolutely unnecessary, it's just an excuse for pushing it out with the Planet RDF feed). One of the most promising (and already deployed) approaches seems to be OpenID. OpenID's core idea is piggybacking on existing service providers which offer personal home- or profile pages for their users. OpenID provides "a way to prove that you own a URL (identity)".

There are of course a lot of security concerns which are apparently nicely addressed by letting users specify which services ("consumers") to accept, you never have to tell your password to a consumer, and the communication between the consumer and the server is even encrypted. This is all cool stuff, but I'm wondering if the security focus is on the wrong link in the chain. The weakest one not being the consumer or the user, but the home service.

As we recently learned, we must assume incompetent users (or, even worse, semantic ones), so when my service provider tells me that I'm now OpenID-enabled, and someone claims on his blog that [your favorite technology/toolkit here] is nothing but crap, of course I want to login and join the discussion! Oh, cool, the blog has simple instructions: "To post comments, please enter your OpenID". I'm logged in at LiveJournal, all I have to do now is to tell that idiot my homepage URL.

And here (finally) is my concern: When I tell the site my homepage URL, it's super easy to find my login name or user id for the most common services (e.g. LJ). Now the site knows
  1. my user id or account name
  2. the service/software I'm using (LJ, Drupal, Wordpress, ...)
  3. that I'm currently logged in (otherwise, OpenID doesn't work)
As we know, none of the software packages used for online services is perfect. They are based on HTML forms which, when submitted, create blog posts, change profiles, add friends, etc. (In Drupal, for example, a single POST can be used to change your password, there is no need to verify the current one).

All the evil site has to do is to mimic a service form and submit it via a hidden iframe. The form will be submitted as if the user did it manually.

This is an interesting counter-example for two Web/IT principles: URI opacity and that Security by obscurity never works. The former isn't true for very successful sites (you could hardcode an exploit for LJ users only), the latter actually worked quite well in the last years, as it simply didn't make sense to secretly POST to a number of sites via an iframe, hoping to hit a service the current visitor is logged in to. With OpenID, though, we make things really simple for trap services.

As I said at the beginning, I don't know if the 2.0 spec addresses this issue. What we basically just need is something similar to a mobile phone's "plane mode" where you could log into your home service, but with limited functionality (e.g. "activate id services only").

Sorry, I deactivated comments. To protect you from spam. ;-)

Comments are disabled for this post.

Earlier Posts


No Posts found