RE: webmail vulnerabilities: a new pragma token?

Mark,

On Wednesday, January 19, 2000 7:46 PM, Mark Nottingham [SMTP:mnot@pobox.com] 
wrote:
>
> Just a reminder- Pragma: no-cache is a request header, not a response header.

This is as it should be.

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

But what Peter suggests is an extension-pragma and not a new Pragma directive 
e.g.

Pragma: no-cache, disable-scripting

and not;

Pragma: disable-scipting

The question that seems more apropos is what is the provider expecting from the 
client, not the converse.  Any implementor that decides to modify her client to 
extend Pragma: no-cache to Pragma: no-cache, disable-scripting should 
reasonably expect the server to have implemented a Reply with scripting 
disabled. OR should we expect the Response chain to ONLY disable those scripted 
elements it 'understands' or the client 'understands' - to me that is the 
dilemma.  What would the clients and servers [sic] be expected to expect. NPI

Eric


> Cheers,
>
>
> On Wed, Jan 19, 2000 at 08:45:00AM -0500, Peter W wrote:
> >
> > 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/
> >
>
> --
> Mark Nottingham, Melbourne Australia
> http://www.mnot.net/

Received on Wednesday, 19 January 2000 19:36:23 UTC