ACTION-893: Start putting together a set of guidelines that could help address the security issues triggered by links rewriting.

http://www.w3.org/2005/MWI/BPWG/Group/track/actions/893

This is a first draft, all comments welcome:

----

When a CT-Proxy is a "man-in-the-middle" a high level of trust needs to
be established with the mobile network operator and end-user before a
user chooses to allow transformation of their private data. Their
concerns are: 

 1. A 3rd-party could see their secure details, even by accident.
 2. Malicious software could snoop secure details or copy them.
 3. Secure details could be recovered from a discarded faulty hard-disk.
 4. A system administrator could see secure details by logging into the
CT-Proxy server, even by accident.
 5. Secure details could be logged by the CT-Proxy's operator for
business analysis.
 6. Their secure details may in fact be going to a fraudulent website,
not the website they expected (a phishing scam).
 7. Their logged-in session with a website could be hijacked by someone
spoofing their identity.

1 is addressed using encryption on all connections to/from the CT-proxy
and by ensuring that any caching at the CT-proxy complies with RFC2616
and RFC2109 with respect to public/private caching rules.

2 is addressed through software audit.

3 & 4 are addressed by operations procedures and by encrypting all user
data on disks.

5 is addressed by never logging anything more than origin domain name
for HTTPS transactions (ie only log what HTTP CONNECT would reveal).

6 is complicated by the fact that often a CT-Proxy has to operate as a
gateway, when it ceases to be a "proxy" and becomes an "end point".

For instance:
 * When a long web-page gets fragmented, links to subsequent fragments
must target the CT-proxy as the origin server.
 * JavaScript events triggered by links in the device's static XHTML/MP
markup must target the CT-proxy as the script execution environment.
 * HTTPS links must be rewritten to transcode an HTTPS web site.
 * To minimize the size of the page returned to the end user, long URIs
may be replaced by short "tokens" that only the issuing CT-proxy can
redeem.

At the URI level, this means that the URI moves from:
  http://[original-URI]
... to something like:
  http://ct-proxy.example.com/[original-URI]

This change of origin hostname is important because of the security
implications it has on the browser for cookies (which belong to
hostnames) and for script Document Object Model security (if the device
has any script capabilities then cross-site scripting attacks become
possible). From the device browser's perspective the CT-proxy makes the
Web look as if it is all from one origin.

The solution to this is for the CT-proxy to manage all cookies and all
script execution on behalf of the device whenever the CT-Proxy is the
URI end-point. The CT-proxy should not pass origin-server scripts
through to the device for execution or pass origin-server cookies to the
device. The CT-proxy must manage its script execution security and
cookie/hostname security in the same way as a web browser to prevent
malicious cross-site scripting exploits. [RFC2109] [reference on DOM
security?]

The CT-proxy must manage the browsing session (including the change of
referer, the use of client certificates, etc) on behalf of the end-user.


7 is only a threat when the CT-proxy is managing the browsing session on
behalf of the user's device browser. In this case the CT-proxy needs to
uniquely identify requests from each user, with either out-of-band
authentication using the radio network's SIM identity or by using
cookies between the user's browser and the CT-proxy. [Reference on
secure session management using cookies?]

Received on Friday, 16 January 2009 20:21:06 UTC