RE: webmail vulnerabilities: a new pragma token?

> -----Original Message-----
> From: Eric D. Williams [mailto:eric@infobro.com]
> Sent: Wednesday, January 19, 2000 7:32 PM
> To: 'Mark Nottingham'; Peter W
> Cc: http-wg@cuckoo.hpl.hp.com
> Subject: 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.
>
But what your talking about means that the server would
send the pragma: disable-scripting to the client.
That is a response header, not a request header as the
spec defines it.
 
> > 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
>
No, thats a new directive.   You're just listing
multiple directives in a single pragma statement.
 
The point of that part of the spec is to declare
pragma obsolete and not to be used in future work.

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

I think the original poster meant that the CLIENT
would disable scripting code that was sent by the server.
What you seem to be describing is that the client would
send a requedt with "please dont send me any script"
which defeats the purpose since you now have to trust
the server....

I see your problem, but I dont think pragma is 
the right place for a solution.
As a matter of fact, I dont think HTTP is the place
for your solution.  Why not just stick a meta tag
in the HTML itself ?

Finally, as scott said, this problem can be solved
by using existing browser functionality.  This
is certainly easier than modifying the protocol and
hoping that people will implement it.  
(I for one would recommend against implementing
 your solution in our browser)

> 
> 
> > 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 23:56:09 UTC