>> 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:27:30 PDT