Restricted Contexts (private browsing / sandbox)

The following comment contains information about a general observation,
identified during a recent security analysis of 13 W3C standards,
organized by ENISA (European Network and Information Security Agency),
and performed by the DistriNet Research Group (K.U. Leuven, Belgium).

The complete report is available at http://www.enisa.europa.eu/html5
(*), and contains information about the process, the discovered
vulnerabilities and recommendations towards improving overall security
in the studied specifications.

In the analysis of multiple specifications, we have noticed that they do
not take a sandboxed environment or a private browsing mode explicitly
into account. This leads to several problems of underspecification, as
concluded in the analysis. Examples of potential issues are:
* Are permissions stored in a normal browsing context also valid in a
private browsing context or vice versa?
* Can a sandboxed frame request permissions, even with a null origin?
* Can data be stored under one browsing context and retrieved under the
other (sandboxed or private)?
* Do the specifications take a null origin into account?

Due to such underspecifications, the behavior of browsers varies
considerably. One concrete example is the storage of permissions in a
private browsing mode: Firefox does not store permissions acquired in
private browsing mode, but Chrome does (in incognito mode).

Another example is the CORS specification, which allows the use of
"null" as an origin value (used in a sandboxed frame with a unique
origin).

We have three recommendations to resolve these issues:

1. Specifically take sandboxed and private contexts into account when
specifying origin-dependent functionality (permissions, origin
checking, ...). Current specifications can be edited to reflect this
information.

2. Define what a private browsing context exactly is, how it should
function and what the requirements are. This allows browser vendors to
adhere to a specification, and thus avoid incompatibilities across
implementations. Additionally, the functionality specs can take these
contexts explicitly into account when defining how and when they are
accessible.

3. Current private browsing modes are aimed at having a browsing session
without leaving a local trail. A useful addition would be a truly
separated context to enhance privacy and provide full client-side
isolation towards sensitive sites (e.g. preventing CSRF attacks on a
banking site).


(*) HTML version of the report is available as well:
https://distrinet.cs.kuleuven.be/projects/HTML5-security/
-- 
Philippe De Ryck
K.U.Leuven, Dept. of Computer Science


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Received on Wednesday, 3 August 2011 17:49:58 UTC