Re: Tag to turn off active content?

Sven Latham <> wrote:

> I don't understand why any specific author would be concerned that
> their own page is a security risk - seems like an extremely paranoid
> author if they don't trust their own code

The problem is user-submitted content, such as in a forum page,
webmail service, or whatever. Almost all such systems are currently
vulnerable to JavaScript injection (even many that are only designed
to allow posting of plain text).

If the only way to insert scripting content had been a <link> to a script
inside <head>, this would not be so big a problem. However there are
currently many routes of attack, the main major approaches being:

  - embedded <script>
  - onX event handlers
  - javascript: in all properties that accept URLs
  - active extensions to CSS, eg. IE's expression() and behaviours,
    Mozilla's bindings
  - Netscape 4's JavaScript entities

The last three were a mistake but it is too late to complain about that
now. In any case there are ways to hide all these from scanners looking
from them; essentially to detect these cases a script would have to have
a full HTML and CSS parser built-in *and* would have to know all the
browser quirks that can cause them to interpret code differently to the
standard. The fact that most scripts out there don't have such
knowledge leads to cross-site-scripting vulnerabilities without end.

Lincoln's proposal is an inelegant but interesting workaround to the
problem. Attackers might find a way around it in some cases but it
would probably prevent a lot of attacks.

The 'lock' feature as proposed is clearly incompatible with both XML
and SGML, but could maybe be accommodated by using separate
empty on and off tags -

  <activeoff lock="x" />
  <activeon lock="x" />

I'm still not convinced this is desirable though. It might be easier just to
have an <activeoff /> element on its own kill all further scripting in a
page. Authors could still script things that need to be scripted by having
a script linked to above, which access elements afterwards through
the DOM.

In the end, it would not solve the complete problem, as there are more
things you can do with inadequately-filtered content than just scripting
and object inclusion. But it would definitely reduce the potential for
security breaches. Of course the *best* thing is still to have the site
author subject user-submitted content to a very restrictive set of markup
rules. But it can be a tricky job and at the moment most authors can't
or won't do it.

Andrew Clover

Received on Tuesday, 14 May 2002 11:43:03 UTC