[Dev] Re: [Design] Obvious Scripting Security Notes
psnively at earthlink.net
Sun Nov 3 18:41:20 PST 2002
On Sunday, November 3, 2002, at 05:14 PM, Wes Felter wrote:
> I don't agree. Entourage supports HTML mail, and it probably supports
> JS in
> mail, but I've never heard of any security holes due to this.
I don't know anything about what APIs are exposed to JS in Entourage,
so it's hard to comment. Clearly, in Outlook's case, it's just
ludicrous: why is it even possible to attach a script to a message that
a) reads the recipient's address book, b) creates a new e-mail
ostensibly from the recipient, with the poor 2nd-recipient's name in
the subject line and everything, and c) sends the new message to the
2nd recipient? The problem clearly isn't JS per se; it's a combination
of ANY script attached to an e-mail being executed willy-nilly, and
that script having capabilities that it shouldn't have.
> It seems
> simple enough to declare that JS inside a message cannot see or modify
> *anything* outside of that message, and my intuition is that this will
> support all use cases.
I would disagree with this--it is indeed easy to conceive of workflow
uses-cases that require deeper integration than this.
> Such a security model has the advantage that it
> doesn't need to be configurable.
I think configurable security policies are desirable for personal use,
and unavoidable for enterprise use.
> I tend to agree here. I've only seen two kinds of HTML email:
> * Simple HTML (no images, no JS) from people who are using OE with
> * Hostile mail (spam, viruses, etc.)
> So based on these use cases, I see no need for JS support at all.
> I can imagine use cases for the "enterprise" market that would require
> such as form-based workflow. But does that apply to Chandler?
Agreed, and I think that it does. Chandler is clearly aimed at "small-
to medium-sized workgroups." I'd expect there to be appreciable support
for Chandler-based workflow management in such a market.
> I think Mitch said plug-ins, not Web browser plug-ins.
Right--I made the distinction explicitly because browser plug-ins
commonly connect right back to the Internet and do stuff that the user
of the browser doesn't expect, isn't aware of, and doesn't necessarily
want. For example, thanks to Flash MX, that Flash animation playing in
your HTML (whether in browser or e-mail client) can now make XML-RPC
calls, and there's not a damned thing your firewall can do about it
short of blocking TCP access through port 80, which would make HTTP
hard to do. :-)
> I would appreciate
> the ability to view attachments inline and I don't see how this
> any security implications.
If the plug-in is from a third party and itself offers "extensibility"
features, particularly some kind of RPC as outlined above, then the
security implications are, I hope, obvious. This may be deemed an
acceptable risk even for Chandler--we all take a "caveat emptor"
attitude toward plug-ins anyway--but I wanted to be clear about it.
> [unnecessary capabilities advocacy snipped :-)]
> Wes Felter - wesley at felter.org - http://felter.org/wesley/
More information about the Dev