Subject: webmail vulnerabilities: a new pragma token?

From: Peter W <[email-masked]>
Date: Wed, 19 Jan 2000 08:45:00 -0500 (EST)

Before making this suggestion to client app vendors, I would very much
appreciate the comments of this working group.

Background:

On the Bugtraq security discussion mailing list[1], there has been much
conversation of late about webmail vulnerabilities. Essentially, the
webmail sites offer HTTP/HTML frontends to read Internet mail. They
normally can display HTML-encoded email. Such systems usually try to
remove all scripting code from email before displaying it. This is to
prevent those scripts from being executed in a way that might exploit
current client scripting lnguage problems, or simply exploit the trust
that a user might normally place in the site running the webmail frontend.

Suggestion:

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. Sites who wished to display untrusted pages (webmail
sites, web discussion forums, etc.) could then use a multi-frame layout.
Any frame that contained untrusted code would have this header included in
the delivery of its content to ensure that the scripts would not be
evaluated, regardless of the normal client settings; other frames, whose
"trusted" documents would be sent without this header, would still be able
to use scripting (if enabled on the client).

May I suggest

Pragma: disable-scripting

which I suppose means a no-cache page would be sent with

Pragma: no-cache, disable-scripting

Per RFC 2616, all Pragma headers must be passed to the client by all proxy
server or gateway applications. So this header would be passed to the
client application, as desired. But is it an acceptable use for "Pragma"?

Comments, suggestions?

-Peter

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

[1] http://www.securityfocus.com/

---

From: "Scott Lawrence" <[email-masked]>
Date: Wed, 19 Jan 2000 14:08:34 -0500

> From: Peter W
> Subject: RE: webmail vulnerabilities: a new pragma token?

> 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. Sites who wished to display untrusted
> pages (webmail sites, web discussion forums, etc.) could then use
a
> multi-frame layout.  Any frame that contained untrusted code would
> have this header included in the delivery of its content to ensure
> that the scripts would not be evaluated, regardless of the normal
> client settings; other frames, whose "trusted" documents would be
> sent without this header, would still be able to use scripting (if
> enabled on the client).

  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.
  In this case, the server can send 'disable-scripting', but it
can't
  tell whether or not that will have any effect.  Worse - today it
  can be assured that it will not, since no browsers implement it.

  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.

  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.

--
Scott Lawrence      Director of R & D        <[email-masked]>
Agranat Systems   Embedded Web Technology   http://www.agranat.com/

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Jan 2000 11:46:13 +1100

Just a reminder- Pragma: no-cache is a request header, not a response header.

Also, RFC2616 says that 'No new Pragma directives will be defined in HTTP'.
That seems to preclude this use of it.

Cheers,

-- 
Mark Nottingham, Melbourne Australia 
http://www.mnot.net/

---

From: Peter W <[email-masked]>
Date: Thu, 20 Jan 2000 08:04:24 -0500 (EST)

> > vbscript, etc. for that document only.

>   no way for the server to know whether or not the client understands

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

> 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

---

From: "Scott Lawrence" <[email-masked]>
Date: Thu, 20 Jan 2000 09:51:35 -0500

> It would be nice if there were on an HTTP header that, if sent
> to the client, would cause the client to disable javascript,

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

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.

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 20 Jan 2000 11:16:23 -0800

(Please note that the mailing list is really [email-masked];
the "cuckoo" machine apparently is willing to forward some mail,
but I'm not at all sure that it's running the same mailing list.)

Even if sticking this kind of information in HTTP were appropriate
(which I don't think it is), using "pragma" would be the wrong
way to go about it. The whole notion of "Pragma" as a HTTP header
came from programming languages which used "Pragma" as a way of
sticking in random additional compiler directives because there were
a fixed number of "reserved words" in the language. There's was no
reason to use "Pragma" as an extension mechanism in the first place,
and certainly it shouldn't be continued.

> vbscript, etc. for that document only.

If you really wanted ot go this way, how about a new MIME type, e.g.,
"message/unsafe;type=http" which would have the semantics of
message/type (message/rfc822 or message/http) with the proviso that
the body is likely to be unsafe content.

At least it would have the right extension behavior, namely
that unaware recipients might save the content to disk but would
be less likely to open it.