RE: webmail vulnerabilities: a new pragma token?

Hello all,

To get straight to the point.  I think the stated is the reason Pragma exists. 
 It is a perfectly apropos usage and addresses the problems discussed on 
BugTraq directly and efficiently.  However, this does not completely address 
the issues in implementation of the clients and their treatment of these 
WebMail systems nor the treatment of proxies concerning those systems.  Perhaps 
a poll of those providers would glean some information concerning the current 
treatment or their client expectations as to the treatment of the 'un-trusted' 
content types.  In any event, this seems to be at least a relevant and 
appropriate use of Pragma as stipulated in RFC 2616.

Eric

Eric Williams, Pres.
Information Brokers, Inc.    Phone: +1 202.889.4395
http://www.infobro.com/        Fax: +1 202.889.4396
mailto:eric@infobro.com      Pager: +1 301.303.8998
           For More Info: info@infobro.com


On Wednesday, January 19, 2000 8:45 AM, Peter W [SMTP:peterw@usa.net] 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/

Received on Wednesday, 19 January 2000 09:14:34 UTC