On Wed, 5 Jan 2000, Metal Hurlant wrote:
>Things are a bit more complicated than that:
>- javascript code can be placed in a growing number of optional tag parameters
>(like onmouseover, onload, etc..). The only way to block those is to keep an
>extensive and up-to-date list of every possible parameter allowing to run a
>script.
Fine. Do it.
Javascript might not have been a good idea in terms of security. Price
you pay for functionality, I suppose. But since we're stuck with it, if
one wishes to provide content (in the form of web pages) and expect the
user to trust it, one must make sure that the content is appropriately
and reliably sanitized.
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.
Short of that, any company wishing to claim that the generated pages it
serves are safe for consumption should either a) not trust third-party
input (like email), or b) make the conscious and concerted effort to
filter things to the best of their ability. b) should not be
unreasonable for any large company, particularly the likes of
Hotmail/Microsoft. The fact that Mr. Guninski's second advisory in this
series could have been generated by a sed one-liner shows a lack of
commitment to (or completeness of) b).
>- Netscape supports something called javascript style sheets, allowing to
>embed javascript between <style> tags
Wow. That's orthogonality for you.
>- Netscape recognizes mocha: and livescript: urls and treats them like
>javascript: urls
>
>I'm sure IE has its own share of incompatible and not widely known ways to run
>scripts.
>Everyone thinks Javascript is cool (except maybe some weird security folks),
>so each new browser version is very likely to have a few new ways to do more
>cool things in javascript..
Does anyone else think that code-execution-via-document-viewing is not
an inherently safe paradigm? (It should actually be fairly obvious that
treating a data segment as a code segment is risky, actually ;).
Short a redesign of the language (or the implementation of a successor),
HTML and the cast of supporting applications around it is going to
continue to be vulnerable to insecurity by blind extension. Passing a
mix of trusted and untrusted content, both of which can be data, code or
pointers to further data and code, over the same socket simply cannot be
made secure without tying down the language. (Anyone wanna guess when
people will stop overloading HTML? Thought not.)
.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"
10:21PM up 98 days, 15:23, 1 user, load averages: 0.08, 0.08, 0.08
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:27:12 PDT