>> 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
