Securing HTML vs securing HTTP

Sun Jan 22 17:59:59 UTC 2006

Hello — I'm investigating identity services; OpenID and LID so far.  
I've read the specs, and used the libraries a little bit, but I'm  
definitely a newbie.

I've been thinking about the contrasting ways they use of proving  
ownership of a URL. Namely:

* To OpenID, the ability to insert specific tags in the <head> of an  
HTML document proves ownership
* To LID, the ability to respond to specific POST queries directed to  
that URL proves ownership

I understand this reflects differing priorities of the protocols'  
designers. Adding a tag to a page's HTML requires less control over  
the server than adding code does. (And it's easier — I'm an  
accomplished web developer but was unable to figure out how to use  
the existing LID libraries to serve my identity at my site; whereas  
serving an OpenID identity was just a matter of signing up with  
MyOpenID.com and adding tags to my Drupal theme to redirect there.)

On further thought, though, I'm worried about the security of the  
HTML approach. This requires locking down the content of my home  
page, lest an attacker manage to splice in their own OpenID tags and  
thereby hijack my identity (by redirecting to their own OpenID URL).  
Since my home/identity page, like most, is a blog <http:// 
mooseyard.com/Jens> this is more involved than just securing FTP/SSH  
access to a static HTML file. Consider:

* The page is generated dynamically by Drupal, a very complex set of  
PHP scripts that I have only limited familiarity with.
* Page content is modified by 3rd party Drupal modules that can use  
hooks to get at almost any stage of the HTML generation.
* Ultimately, the framing HTML of the page is generated by a 3rd  
party Drupal theme.
* I could potentially (though I don't) display post comments on the  
front page, i.e. text content written by arbitrary people.

That's a lot of stuff I have to trust. Now, it's very unlikely that a  
release version of an open-source project like Drupal would contain  
malicious code. But a top-of-tree version might, briefly, if someone  
slipped up in reviewing a patch. It's more conceivable a new module  
might do something nasty before being discovered. Same goes for a  
theme, and in my experience people tend to be pretty cavalier about  
installing themes -- they might customize some of the CSS but may not  
examine the executable code, especially if it's written in an outré  
language like LiveJournal's S2.

Yes, I'm being paranoid. But am I paranoid enough? Consider that high- 
profile community sites like MySpace and LiveJournal have had  
security problems involving user-created themes that turned out to  
have malicious code in them. Apparently people have had their  
accounts pwnz0red, journals deleted, etc. Consider how much worse  
this could be if the victims had been using these URLs as identities  
for other sites ... it's not inconceivable that (given further OpenID  
adoption, and silly users) someone might have used their MySpace/LJ  
URL as an identity for, say, PayPal or eBay...

Thoughts?

--Jens Alfke