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

An additional issue with seamless just came to mind...  Chris had asked:

> What if I just want to filter arbitrary user input before
> storing it in LocalStorage for retrieval and use later?
> Or filter it to minify it, or the like.

I presented a straightforward solution for Safe Node.  But for
seamless it gets tricky if you assume a portion of the solution
involves script running in the host frame.  At minimum, script would
need to know how to find and activate IFRAMEs that eventually land on
a page, somewhere.

Dave

On Mon, Jan 25, 2016 at 12:05 AM, David Ross <drx@google.com> wrote:
> IFRAMEs require significant engineering work to implement in many
> cases, and aren't particularly flexible in some ways.  They're square
> and styles from the outer page don't affect them.  Scrollbars might
> appear or content may be obscured if it isn't quite the right size.
> That can be handled but it increases complexity.  These issues should
> fixed by seamless though, as you point out.
>
> But seamless isn't a particularly good solution out of the box...
> You'd need to pick the right CSP and pick the right policy for the
> IFRAME sandbox, which can be tricky.  You can do all sorts of fancy
> things with postMessage, which is tempting but adds a ton of
> complexity.  But then also postMessage doesn't work if you've disabled
> script on the inner page, which you'd need to do if the IFRAME was
> same-origin to its container.  You need to make navigation target the
> top level if you want to allow navigation.  Finally, last time I
> checked, the outer frame has no way of taking action when links within
> the sandboxed frame have been clicked, hovered over, etc. (reference
> https://bugs.webkit.org/show_bug.cgi?id=98951)  This would be an
> important consideration for the mail client scenario, as an example.
>
> In contrast, it should be possible to create Safe Nodes on-the-fly
> whenever you want to safely render a little snippet of untrusted
> markup.  You mostly don't need to think through all these
> considerations, just create a Safe Node and add it into the DOM.
> Configuration options are available, but they're tuned to the use
> cases you might care about and they don't create much of an
> opportunity for shooting yourself in the foot.
>
> Though I would agree that in a world with seamless IFRAMEs, it should
> be possible to build a decent Safe Node polyfill.
>
>> Like, will form elements and others impact the global scope?
> Per above, form elements wouldn't function.  Input elements would
> still be available though.  Presumably with a sandboxed frame you'd
> disable allow-forms so the behavior would be the same.
>
> Dave
>
> On Sat, Jan 23, 2016 at 1:48 PM, Andrew Sutherland
> <asutherland@asutherland.org> wrote:
>> 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 Monday, 25 January 2016 08:39:10 UTC