W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2016

In-browser sanitization vs. a “Safe Node” in the DOM

From: Andrew Sutherland <asutherland@asutherland.org>
Date: Sat, 23 Jan 2016 16:48:12 -0500
To: public-webappsec@w3.org
Message-ID: <56A3F51C.7060700@asutherland.org>
Could you elaborate on the specific use-cases motivating this proposal?

As an email app developer (currently on the Firefox OS Gaia email app, 
previously on Thunderbird) whose app sanitizes HTML mail messages[1], it 
seems like the following largely meet our needs and potentially 
eliminate much of our need for sanitizing:
- iframes
- The iframe sandbox attribute
- CSP2 in the iframe by way of an injected meta element

The motivating goals for this are:
- Privacy: Ensure that no network accesses occur as a by-product of the 
user reading an email message unless they specifically choose "show 
images".  I think CSP2 now may provide a sufficient means of 
accomplishing this.
- Anti-annoyance.  It's generally accepted that HTML emails do not have 
the full fidelity of the web open to them, and so it's appropriate for 
us to ensure the user's expectations of an inert (non-singing, 
non-dancing) message.

If the above mechanisms are insufficient, I'd think I'd consider some 
combination of:
- requesting new fanciness for CSP
- using service workers and their ability to decide how to fulfill 
requests from within my origin
- requesting an enhancement to service-workers to allow them 
programmatic access to extra context information in order to deny fetch 
requests.  For example, Thunderbird makes use of Gecko's 
nsIContentPolicy mechanism[2] to forbid remote network access from mail 
messages.  (And I think this is generally in line with how your proposal 
would work under the hood.)

This proposal seems to discard iframes quite quickly, so maybe there's 
something about your use case where this makes sense?  I do agree it's 
majorly unfortunate that we don't have a way for an iframe to self-size 
itself to be displayed in its entirety.  I feel like I've read off-hand 
comments that a solution might be more feasible once CSS Containment 
happens (https://drafts.csswg.org/css-containment/) but I really may be 
misremembering/misinterpreting.  But it seems like if what we really 
want is seamless iframes, it's simpler and saner for everyone if we just 
ask for seamless iframes rather than introducing a new concept with its 
own new semantics to the world[3].

Andrew

1: Using a white-list based mechanism using 
https://github.com/mozilla-b2g/bleach.js.  We did, however, discuss 
creating an HTML API before going with a pure JS library. See 
https://groups.google.com/d/msg/mozilla.dev.webapi/wDFM_T9v7Tc/_yTofMrjBk4J

2: See 
https://dxr.mozilla.org/mozilla-central/source/dom/base/nsIContentPolicyBase.idl 
and 
https://dxr.mozilla.org/mozilla-central/source/dom/base/nsIContentPolicy.idl 
for the interface.  Thunderbird's usage is at 
https://dxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgContentPolicy.cpp#431

3: Like, will form elements and others impact the global scope?  It 
doesn't seem safe to let them do that, but you're changing their 
behavior if you don't.
Received on Saturday, 23 January 2016 21:48:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:17 UTC