RE: webmail vulnerabilities: a new pragma token?

> From: Peter W

> It would be nice if there were on an HTTP header that, if sent
> to the client, would cause the client to disable javascript,
> vbscript, etc. for that document only.

> > The problem with Pragma as an extension mechanism is
> > that there is
> > no way for the server to know whether or not the
> > client understands
> > any particular pragma token, so it becomes an unreliable
> > mechanism.

> True, but that's just an issue of getting client vendors on
> board.

Believe me, that is a big hurdle to get over.  I'm one of the
authors of RFC 2617 - Digest Authentication, whose goal is simply
to stop publishing passwords on the Net in cleartext (as all web
mail sites do now - do any use Digest yet?  IE5 supports it.)
Getting new extensions into browsers is not an easy task
(Netscape doesn't even support HTTP/1.1 yet), and you have to
always assume that some won't have it.

> Agreed. I think it would be nice if HTTP provided a way to
> indicate to the client where they might find a signature or
> verification service to authenticate individual pieces of
> content. [...]
> So this, too, is a good candidate for a new entity header.

I should think that multipart/signed would be a better way to go;
the server provides both the object and its signature together.

> I also think there should be an HTML/XML DTD extension to allow
> a document to mark a portion of it (e.g., a certain DIV) as
> signed text, e.g. the news paragraphs are signed, but not the
> doubleclick ad banner. ;-)

That sounds like grist for the XML Signatures WG.

> But it would be nice, don't you think, if a site could
> explicitly repudiate a document without needing a different
> base URL?

I think that you've got the problem backwards - rather than
trying to find a way to explicitly repudiate things, the model
needs to be that nothing is trusted unless vouched for
explicitly.  Otherwise, an attacker can just strip the
repudiation and the result is a trusted object.

> I don't see signed scripts going anywhere soon; too much of a
> hassle for Web publishers.

I think that if Web publishers want to run their programs on my
system with my privileges, then the burden belongs on them to
establish that I can trust them and their scripts.

> Two growing trends make this repudiation a valuable notion:
> webmail systems (ala Hotmail) and discussion-based Web sites
> (ala Slashdot). In both these models, it's natural that
> externally-supplied content should not be trusted to the same
> degree that content created by Microsoft (Hotmail) or Andover
> (Slashdot) should be.

Interesting assumption - that the service provider should be
presumed more trustworthy.  One I don't share, but that is not a
protocol issue.

> And especially for webmail, it seems
> very, very difficult for the server to filter out all the
> different ways of embedding scripts. (Actually, sanitizing
> other objects like PostScript files or Java classes would be
> more difficult.)

Which is why they should put the burden on the originator of the
mail and the recipient to implement a trust model that flows
through their service, rather than taking on the (probably
impossible) job of making all the content safe.

--
Scott Lawrence      Director of R & D        <lawrence@agranat.com>
Agranat Systems   Embedded Web Technology   http://www.agranat.com/

Received on Thursday, 20 January 2000 06:55:45 UTC