Securing HTML vs securing HTTP

[Martin Atkins]

Jens Alfke wrote:
> 
> 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.
> 

If you're letting arbitrary people inject arbitrary HTML into your site
you're already in danger. Here are some other things people can do if
you allow this:
* Add spam links to leech off your Google PageRank.
* Inject plain old adverts into your site
* Inject script which copies session cookies off-site in order to hijack
privileged user accounts.
* ... etc, etc ...

If you're displaying any user-supplied content on your site you need to
be running it through an HTML cleaner. Unfortunately you'll find that
browsers are full of quirks which make it hard to catch everything
harmful, but stripping out LINK elements at least would not be a major
undertaking with a real HTML parser. (not just regexes!)

I don't know how well this is handled in Drupal and its modules, but if
the comment/other modules you're using don't already do this, I
personally would have serious reservations about using any code from
that author, since he's obviously clueless/ignorant.