Re: Cross site scripting: a long term fix

[David LeBlanc <dleblanc () MINDSPRING COM>]

At 06:50 AM 10/7/00 +0900, Zag Zig wrote:

> An interesting commentary on this issue could be found
> in 'The Cross-Site Scripting Scam' by John C Dvorak.
> http://www.zdnet.com/pcmag/stories/opinions/0,7802,2434175,00.html

I am surprised that he doesn't think aliens from Alpha Centauri are
involved. He also failed to mention the Gnomes of Zurich or any of the rest
of the Illuminati. Mr. Dvorak has an active imagination - perhaps he should
consider writing science fiction (IMHO). "Whatever the Thinker thinks, the
Prover proves." - Orr's law, as quoted by Robert Anton Wilson.  I also find
it quite amusing he considers CERT/CC 'shadowy'. ROTFL. I always enjoy
thinking about people's reality tunnels.  But I wander well off-topic.

> This page has a list of links to comments entered by the readers.
> It appears that one of the commenting readers successfully illustrated
> the problem on that page.

This is rich irony. Last comment on the page stuck it in for their name -

<scr!pt>alert('?');</scr!pt>... - <i><scr!pt>alert('name');</scr!pt>

i replaced by ! so that it won't fire.

CERT proposed...
> This short term fix is complex and not likely to be widely used.

You're probably right.  About like expecting buffer overflows to go away
because people know not to use strcpy().

> The report does not propose any other changes in the web architecture
> that could lead to a simpler, more secure, and more widely used solution.
> It does not properly characterize the problem.
> It does not examine which features of the web architecture
> are responsible for the existence of the problem.
> It makes the problem look way too complex.
> This is a very simple problem.
> They do not expose the simplicity of the problem
> and do not propose a solution of matching simplicity.

Here, I don't entirely agree with you. I think your solution below deals
with at least some of the problem, but not all of it.

> This tag should have been part of HTML from day one.
> I take this back, make it day zero.

Part of the problem is because we started using HTML without any idea that
we'd end up depending on it for nearly everything. All sorts of stuff is
bolted on afterwards, so it is a bit of a mess.

> This tag, when applied to any text, returns that text unchanged.
> Zero, when added to any number, returns that number unchanged.
> In spite of this simplicity, it took a long time to discover
> or invent the number zero. Solving cross scripting problem with HTML
> lacking this zero tag is like multiplying with Roman numerals.

Interesting analogy.

> Will adding this tag cause any problems?
> The possible problem is that it may delay some
> sexier features: adding smell, taste, touch,
> the sixth sense and the fourth dimension to the web.
> This is a no-op tag, it performs no operation.
> It should not be too difficult to implement it.
> It would be difficult to make incompatible implementations,
> but not impossible.

I would further suggest that a similar <noscript> tag be made available,
and you could now have user-supplied HTML, but turn off scripting.

> If this was a talk, I would have expected someone to interrupt me
> a few paragraphs earlier where I suggested the simplified syntax.
>
> Surely you are joking. This can be defeated easily with this input:
>
> </text>
> <script> ... </script>
> <text>

Very true - I nearly hit reply much too soon to tell you this was silly.

> 2.1. Adding an end marker to the opening and closing tag.
>
> <text end='unique string'> ... </text end='unique string'>

This would seem convenient, but if the attacker can guess or otherwise
determine the unique string, it can be defeated. Considering that it must
be sent to the browser in order for it to work, the attacker can determine
this unless it is dynamically generated. If it is dynamically generated, it
will consume CPU on the server, and most web site operators view CPU
consumption as a Bad Thing. Also, it is a royal PITA to try and generate
random stuff that isn't guessable somehow (e.g., recent FreeBSD post, many,
many previous examples of this problem). One possible thought would be to
hash the supplied text, though I think someone will come up with some
reason that won't work. Perhaps if the browser also checked the
server-supplied hash, this could work.

> 2.2. Adding the count of bytes in the text.

> <text bytes='3'>ABC</text bytes='3'>
> <text bytes='3'>ABC</text>

> This works even better when tags are generated by
> a program. Counting bytes is a cheap operation.

I like this better. Server gets n bytes from client, escapes out all of
them. I can't think of a way around this just at the moment.

> This type of a quoted string is older then Fortran.

Actually, isn't it properly FORTRAN? I seem to recall that it is an
acronym, but considering that I last programmed it across a 300 baud modem
on a CDC Cyber running NOS, my memory could be failing me.

> What should the browser do if the number of bytes
> received does not match the number of bytes sent?
> It should throw away the string and replace it
> with a string of length zero.

I would suggest just truncating it, or padding with blanks, depending on
whether it was an under or overflow.

All in all, some interesting ideas. I wonder what it takes to get them
seriously considered and implemented.

Obviously, my $0.02 and has nothing to do with what my employer thinks.

#include <std.disclaimer>

David LeBlanc
dleblanc () mindspring com