[Dev] Re: [Design] Obvious Scripting Security Notes

[Paul Snively]

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 
> default
> settings.
> * 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 
> JS,
> 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 
> introduces
> 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 :-)]
>
Touche'. :-)

> Wes Felter - wesley at felter.org - http://felter.org/wesley/
>
Best regards,
Paul