Re: Hotmail security hole - injecting JavaScript using <IMG

[ajax () LINWORTH ORG (Ajax)]

> > In my dream world, languages like HTML would be required by their own
> > bylaws to explicitly enumerate at least the most blatantly insecure
> > features.  There *ought* to be a list somewhere of what tags can have
> > javascript as a value, maintained by whichever authority is in charge of
> > determining such things.  Granted this only reduces the (potential)
> > vulnerability to a race condition -- between the updating of the
> > standard and the updating of site filters -- but it's probably as good
> > as we can hope to get.
>
> No, it is not.  Why are everybody missing the obvious here?
>
> It is TRIVIAL to make filters not have these kinds of security
> problems.  The clue is that any security filter MUST default to
> *D E N Y*, not pass.  Any security filter that denies 'bad' stuff and
> passes everything else is BROKEN.
>
> None of these problems would have occurred if MS had stuck to this
> trivial basic of secure systems design.
>
> Eivind.

I'm gonna say that this is untrue for HTML.  The language simply moves
too much.  If some tag, previously thought safe, becomes extended by a
particular browser or the language specification itself, then until the
filter is updated a potential vulnerability exists.

Think of it this way: imagine .forward files didn't have the ability to
point to a pipeline, only another email address.  You might have a
script in place to verify the listed addresses, but other than that...
Now imagine we put that functionality back; all of a sudden, your filter
is no longer adequate, and it must be updated.  Now obviously this
overlooks the fact that pipelines and simple addresses have different
syntaxes, but I believe the point is made.

Obviously a filter designed for one application or even one version of a
language will *not* be appropriate for anything else.  I don't apply
javascript filters to perl scripts the same way I don't filter water
with the screen from my front door.  I'll even go so far as to suggest
that the fact that we're even *dealing* with a versioned language
suggests the logical improbability of secure design.

Which leads me back to my original assertion: either we come up with a
fix for the language, invent a replacement, or engage in the current
scrambles at every revision.  This last is a race we cannot hope to keep
winning, particularly when we aren't even on the ball currently.

.a.j.a.x. @ vxgas.linworth.org
"You can run Java applets from anyone, anywhere, in complete safety"
    - Charles L. Perkins, "Teach Yourself Java in 21 Days"
11:26AM  up 104 days,  4:28, 2 users, load averages: 0.09, 0.08, 0.08