W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 2000

RE: webmail vulnerabilities: a new pragma token?

From: Scott Lawrence <lawrence@agranat.com>
Date: Wed, 19 Jan 2000 14:08:34 -0500
To: "Peter W" <peterw@usa.net>, <http-wg@cuckoo.hpl.hp.com>
Message-ID: <002501bf62b0$955e13c0$954768c0@oyster.agranat.com>
> From: Peter W
> Subject: RE: webmail vulnerabilities: a new pragma token?

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

  The problem with Pragma as an extension mechanism is that there is
  no way for the server to know whether or not the client
understands
  any particular pragma token, so it becomes an unreliable
mechanism.
  In this case, the server can send 'disable-scripting', but it
can't
  tell whether or not that will have any effect.  Worse - today it
  can be assured that it will not, since no browsers implement it.

  The degree of trust that a user should have in scripts, as this
  example illustrates, is really a property of the script itself, or
  perhaps of the containing document, not of the server from which
it
  is obtained.  There are already mechanisms available for signing
  email, so if anything we should be looking for ways for browsers
to
  make the trust decisions appropriately - based on the document,
not
  the web server.

  As an interim solution for the webmail sites today, I'd suggest
that
  you've already got the basis for a solution.  Serve the framework
  that you want the user to trust from 'webmailbox.example.com', and
  then serve the content of the mail frame from 'mail.example.com'.
  Instruct users to trust 'webmailbox' and not to trust 'mail'.  A
  solution like this can be implemented with many of todays browsers
  with no protocol change.

--
Scott Lawrence      Director of R & D        <lawrence@agranat.com>
Agranat Systems   Embedded Web Technology   http://www.agranat.com/
Received on Wednesday, 19 January 2000 19:12:20 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:35 EDT