RE: webmail vulnerabilities: a new pragma token?

At 2:08pm Jan 19, 2000, Scott Lawrence wrote:

> > 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.

Others have written that Pragma is a request header. Hmm. While RFC 2616
only defines its meaning as a request header, it defines Pragma as a
general header field, doesn't it? (sections 4.5 and 14.32). Anyhow, if
Pragma is a bad choice, then perhaps a new entity header should be used,
in which case this is not an HTTP protocol question, as new entity
headers can be added without changing the protocol. ;-)

> The degree of trust that a user should have in scripts, as this
> example illustrates, is really a property of the script itself, or
> perhaps of the containing document, not of the server from which it is
> obtained.  There are already mechanisms available for signing email,
> so if anything we should be looking for ways for browsers to make the
> trust decisions appropriately - based on the document, not the web
> server.

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. That way a photographer could
publish an image file and a detached .asc PGP signature, and the HTTP
client could obtain information from the httpd about where/how to get the
signature. Arguably this could be an attribute of an <IMG> tag, but IMHO
the signature is as much an attribute of the document as the last-modified
date and should be revealed by the httpd, not the referring document. So
this, too, is a good candidate for a new entity header.

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. ;-)

> As an interim solution for the webmail sites today, I'd suggest that
> you've already got the basis for a solution.  Serve the framework that
> you want the user to trust from 'webmailbox.example.com', and then
> serve the content of the mail frame from 'mail.example.com'. Instruct
> users to trust 'webmailbox' and not to trust 'mail'.  A solution like
> this can be implemented with many of todays browsers with no protocol
> change.

With Internet Explorer at least, yes, using Zones. Very clever idea. I
like it, except it's a hassle for the end users. But it would be nice,
don't you think, if a site could explicitly repudiate a document without
needing a different base URL?

That's the essence of the problem: we have two different
run-this-script? security models with Netscape and IE:
 Netscape: based on how we got the document (HTTP vs POP3/IMAP/NNTP)
	   -this made more sense when it wasn't so easy to anonymously
	    publish content through other folks' Web sites, see below
 IE:       based on where we got the document (domains & zones)
	   -made more sense when sites generally contained only content
	    locally produced or approved

I don't see signed scripts going anywhere soon; too much of a hassle for
Web publishers. What I'm basically suggesting is a way to improve the
all-or-nothing security model: let the server repudiate an individual
document. Why not a META tag? Because I see this as applying to different
documents than HTML(/XML). Consider PostScript files, Java classes, and
other content that you might get through HTTP.

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. 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.)

Anyhow, until/unless we have a usable document-based trust model, it would
be helpful if servers could indicate that a document should not be given
the same trust as official documents.

Thanks very much,

-Peter

http://www.bastille-linux.org/ : working towards more secure Linux systems

Received on Thursday, 20 January 2000 05:11:05 UTC