Subject: RE: webmail vulnerabilities: a new pragma token?

From: "Eric D. Williams" <[email-masked]>
Date: Wed, 19 Jan 2000 12:12:12 -0500

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:[email-masked]      Pager: +1 301.303.8998
           For More Info: [email-masked]

On Wednesday, January 19, 2000 8:45 AM, Peter W [SMTP:[email-masked]] 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/

---

From: "Eric D. Williams" <[email-masked]>
Date: Wed, 19 Jan 2000 22:32:19 -0500

Mark,

On Wednesday, January 19, 2000 7:46 PM, Mark Nottingham [SMTP:[email-masked]] 
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.

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:
> >
> --
> Mark Nottingham, Melbourne Australia
> http://www.mnot.net/

---

From: "Eric D. Williams" <[email-masked]>
Date: Thu, 20 Jan 2000 09:28:11 -0500

On Thursday, January 20, 2000 2:32 AM, Josh Cohen 
[SMTP:[email-masked]] wrote:
> > -----Original Message-----
> > From: Eric D. Williams [mailto:[email-masked]]
> > Sent: Wednesday, January 19, 2000 7:32 PM
> > To: 'Mark Nottingham'; Peter W
> > Cc: [email-masked]
> > Subject: RE: webmail vulnerabilities: a new pragma token?
> >
> >
> > Mark,
> >
> 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.
>
> 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.
>

Got it.  That is a fine explanation of the intent as Pragma was included only 
for backward compatibility.

> I think the original poster meant that the CLIENT
> would disable scripting code that was sent by the server.

I disagree, I think the intent was to activate some 'procedure' in the response 
chain such that no scirpting elements would be returned in the content.  I 
certainly could have mis-interpreted this (and the Pragma directive is a 
request header) but it seems that is the intent.

> What you seem to be describing is that the client would
> send a request with "please don't send me any script"
> which defeats the purpose since you now have to trust
> the server....

That's the rub.

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

Therein lies the dilemma.  A question of whether the intended use of the 
browser as 'eMail UI' would be defeated in a substantial portion of WebMail 
based sites.  Also if the mere presence of a meta-tag could be used to disable 
(or enable) scripting in a browser (although, IMHO, disabling would be a good 
thing under some circumstances) it could lead to other issues concerning the 
'authenticity' or 'integrity' of page elements intended to be 'calculated' by 
the browser or passed to other modules for further processing.

Certainly we are not (yet) talking about SHTTP  like functionality for WebMail 
systems (maybe HTML or XML will?) but these issues of trusted and un-trusted 
scripting elements are currently being dealt with at the provider side through 
script filtering mechanisms, which seem to be inadequate at times.  This 
functionality may be best implemented as a Meta-Tag SUPPORTED in client 
implementations (who turns scripting back on?).  This would require a change in 
either usage expectations or browser HTML-parsing implementations ("I disable 
scripting every time I visit webmail.com?", "my browser ``remembers'' to 
disable scripting for this site element".) .  And still imposes a requirement 
on the provider concerning 'what to expect' the client will do as it relates to 
this meta-info certainly not a discussion for this WG, but IMHO may be best 
handled at the protocol level.

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

Just a note, this is not my solution.  Merely a seconding of a proposed measure 
to address some difficult areas concerning user expectations of behavior in 
these systems.  I would contend that the solution WILL require either:

1.  A change in the way WebMail systems are implemented (which could include 
protocol changes) or;
2.  A change in the functionality of browsers at some level (read HTML 
parsing).

Eric

Eric Williams, Pres.

---

From: Dave Kristol <[email-masked]>
Date: Thu, 20 Jan 2000 14:43:17 -0500 (EST)

In my opinion, the whole idea of using HTTP to alert the client of
"unsafe content" is wrong-headed.  ALL content is unsafe unless you
trust it.  Therefore, the client *must* provide facilities to let the
user identify trusted content and to protect him/her from untrusted
content.  The content could come equally well from FTP or some other
protocol.

We have seen that bugs in design and/or implementation of scripting
languages have left users vulnerable.  These bugs would still exist
even if an HTTP header were added.  And an HTTP header would provide no
protection from scripts obtained via FTP.  The real solution is to fix
the implementations.

That may seem like a slow and painful solution, but it puts control in
the hands of the user, who has the most at stake.  And given that new
browsers would be required to detect a new HTTP header anyway, fixing
the problem (faulty browser security), and not the symptom (scripts
embedded in web-based email), is the right way to go.

Dave Kristol

---

From: "Eric D. Williams" <[email-masked]>
Date: Thu, 20 Jan 2000 15:15:56 -0500

Larry,

I think you are coming real close here.  We are definitely looking at an issue 
of 'levels of trust' that must be understood by client implementations and 
end-users.  I suppose another MIME type would address the issue and allow some 
freeform for a time as to how to handle unsafe content.  For me you have made 
it no longer as perplexing a conundrum as before:

and,

On Thursday, January 20, 2000 2:16 PM, Larry Masinter 
[SMTP:[email-masked]] wrote:
--8<--snip-->8--
>
> 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.
>

I think the intent of the HTTP/1.1 support was for backward compatibility, only 
yes?  The 1.0 header request Pragma was a way of addressing "no-cache".

> > 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.
>
> If you really wanted to 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.

Here is where the 'levels of trust' (that's the bug-a-boo) would be important 
(to me).  It would be good not to limit the description here to merely 
"unsafe", per se I think I see your point clearly.

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

I don't know about that; if its not safe to a later 'aware' recipient is 
probable and good, but older clients would not be able to discriminate.  That 
could set up an interesting situation where browsers are updated or 
trust-levels are upgraded; Excellent though.

Eric

Eric Williams, Pres.
mailto:[email-masked]

---

From: Josh Cohen <[email-masked]>
Date: Thu, 20 Jan 2000 12:54:29 -0800

> Sent: Thursday, January 20, 2000 12:16 PM
> To: 'Larry Masinter'
> Cc: [email-masked]'
> > Larry said:
> Eric said:
Maybe Im misreading your words, but I think you missed
part of larry's point.  By using a new MIME type,
older browsers would implicitly discriminate.
Today, a browser that gets an unknown mime time, which this
new one would be, it will prompt the user to save it to disk
instead of showing it.

This would effectively prevent it from being displayed
or executed without user consent.

---

From: "Eric D. Williams" <[email-masked]>
Date: Thu, 20 Jan 2000 20:45:25 -0500

On Thursday, January 20, 2000 3:54 PM, Josh Cohen 
[SMTP:[email-masked]] wrote:
> > I don't know about that; if its not safe to a later 'aware'
> > recipient is probable and good, but older clients would not be able to
> > discriminate.  That could set up an interesting situation where browsers 
are updated or
> new one would be, it will prompt the user to save it to disk

Yes, that is true, my concern was/is with just that point.  After the item is 
saved many users attempt to open that 'troublesome' downloaded page.  The only 
thing I am saying is the content after saving to disk can still contain 
'malicious' scripting code and the browser could not then successfully 
discriminate unless the file name was some how also unlinked from the types 
'compatible' with the browser (read viewer) and parsed without scripting.

I say yes, Josh, you are correct that part was not clear.  Thanks.

> or executed without user consent.

Yes, user consent is a primary factor here (always), as well as _expected 
behavior_.  One should consider what a user would do concerning unknown types 
that are nominally displayed in their client, it could get confusing to say the 
least. A user may just map an association back to the browser at worst 
(education of the user is also a key issue) perhaps as you mentioned this is 
not an effective track (http-wg), but I am still not sure.

Eric