webmail vulnerabilities: a new pragma token?

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/

Received on Wednesday, 19 January 2000 08:38:19 UTC