Re: [whatwg] `iframe[@sandbox]`: "sandblaster" JS library for analysis/modification

[Mike West]

On Wed, Sep 30, 2015 at 4:56 PM, James M. Greene 
wrote:

> While investigating, I ended up creating a JS library called *sandblaster*
> [1] to assist me in analyzing


We should probably just provide a mechanism for reading the currently
active sandboxing flags. You shouldn't have to write pages of code to get
that data. Somewhat the inverse of
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29061.


> *and* potentially modifying/dismantling
> iframe sandboxes.
>

Are you able to do this in any cases other than `allow-same-origin` and
`allow-scripts`? If so, we should fix them. :)

Thanks for putting this together!

-mike

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Thu, Jul 9, 2015 at 5:28 PM, Daniel Veditz  wrote:

> On Mon, Jul 6, 2015 at 2:47 AM, Mike West  wrote:
>
>> I've dropped the opener/openee-disowning behavior from my proposal,
>> and renamed the sandboxing keyword to `allow-popups-to-escape-sandbox` in
>>
>> https://wiki.whatwg.org/index.php?title=Iframe_sandbox_improvments&diff=9958&oldid=9955
>
>
> ​It appears that this new keyword as described would still require the use
> of allow-popups in addition to allow-popups-to-escape-sandbox. Since it
> doesn't make any sense on its own can you change it so that either keyword
> allows popups to happen? That it, propose changing
>
> [Set] The sandboxed auxiliary navigation browsing context flag
> <https://developers.whatwg.org/origin-0.html#sandboxed-auxiliary-navigation-browsing-context-flag>,
> unless tokens
> contains the allow-popups keyword.
>
> to
>
>[Set] The sandboxed auxiliary navigation browsing context flag
> <https://developers.whatwg.org/origin-0.html#sandboxed-auxiliary-navigation-browsing-context-flag>,
> unless tokens
>contains the allow-popups or *allow-popups-to-escape-sandbox* keyword.
>
> ​(might then require changing -to-escape- to -that-escape-)​
>

My only concern with this is that folks might disallow certain sanboxing
flags that they know are dangerous, which might mean that their CMS would
block `allow-plugins`, but might allow new flags (which would then allow
someone to `allow-plugins-to-escape-sandbox`. This kind of blacklisting is
probably a bit far fetched, so I could live with the behavior if you feel
strongly about it, but I'd prefer to keep the changes as small and additive
as possible.

-mike

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Mon, Jul 6, 2015 at 9:14 PM, Boris Zbarsky  wrote:

> On 7/6/15 5:47 AM, Mike West wrote:
>
>> Boris, I think this is consistent with your suggestions in
>>
>> https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/F6WGG03FafAJ
>> and
>>
>> https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/pZZ0MXzpbKAJ
>> .
>> Can you live with this naming/behavior?
>>
>
> I personally can probably can... I can't promise anything about how people
> will respond to an intent to implement for such a thing.


I'll take it. :)

-mike

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Tue, Jun 23, 2015 at 11:14 AM, Mike West  wrote:

> After some conversation with bz (CC'd), I've slightly formalized the
> description of the feature at
> https://wiki.whatwg.org/wiki/Iframe_sandbox_improvments.
>
> This is something that I'd like to ship in Chrome in the somewhat near
> future. See the "Intent to Ship" at
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/YtsqkySmTWcJ.
> Feedback, positive or negative, would be appreciated (either here or
> there). :)
>

It seems like there's either substantial agreement (or apathy) regarding
the `allow-modals` proposal.

The auxiliary proposal is the more interesting of the two, and I've revised
it again following some more feedback from ads folks. In short, they're
more interested in maintaining a communication channel between the
sandboxed frame and the auxiliary window than I thought they were. Given
that, I've dropped the opener/openee-disowning behavior from my proposal,
and renamed the sandboxing keyword to `allow-popups-to-escape-sandbox` in
https://wiki.whatwg.org/index.php?title=Iframe_sandbox_improvments&diff=9958&oldid=9955
.

Boris, I think this is consistent with your suggestions in
https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/F6WGG03FafAJ
and
https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/pZZ0MXzpbKAJ.
Can you live with this naming/behavior?

-mike

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

After some conversation with bz (CC'd), I've slightly formalized the
description of the feature at
https://wiki.whatwg.org/wiki/Iframe_sandbox_improvments.

This is something that I'd like to ship in Chrome in the somewhat near
future. See the "Intent to Ship" at
https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/YtsqkySmTWcJ.
Feedback, positive or negative, would be appreciated (either here or
there). :)

-mike

--
Mike West , @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Sun, May 17, 2015 at 8:59 PM, Mike West  wrote:

> On Mon, May 11, 2015 at 6:11 AM, Mike West  wrote:
>>
>> 2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the
>> `sandbox` attribute, which, when present, would allow auxiliary browsing
>> contexts created by `window.open` and `target="_blank"` links to create
>> clean browsing contexts, unaffected by the sandbox which spawned them.
>>
>
> This flag is in the latest Chrome Canary,
> behind chrome://flags/#enable-experimental-web-platform-features, if anyone
> is interested in playing with the feature.
>
> Given the generally positive response on this thread, WDYT about adding it
> to HTML, hixie@?
>
> I'd like to circle back to the `allow-modals` proposal once
> https://www.chromestatus.com/metrics/feature/timeline/popularity/767 hits
> stable and starts bringing in reliable data (~12 weeks). I'll ping the
> thread again then. :)
>
> -mike
>
> --
> Mike West , @mikewest
>
> Google Germany GmbH, Dienerstrasse 12, 80331 München,
> Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
> Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
> Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>

Re: [whatwg] sandboxed iframe allow-auto-play

[Mike West]

Hi Benjamin!

On Fri, May 29, 2015 at 4:27 PM, Benjamin Kelly  wrote:
> Recently I was talking with a web developer who told me one of his biggest
> problems is dealing with "bad ads" that play audio/video immediately.
>
> I was wondering if we could address this use case with some changes like:
>
> 1) Change sandboxed iframes to disable audio/video playing without user
> interaction by default.
> 2) Add a new sandbox token "allow-auto-play" that permits playing without
> user interaction.

This should already be covered by
https://html.spec.whatwg.org/multipage/browsers.html#sandboxed-automatic-features-browsing-context-flag,
right? Note that it's tied to the `allow-scripts` keyword, as running
script makes it trivial to trigger a play action.

> Ideally this would effect flash running in the iframe as well, but its
> unclear to me how feasible that is.  Still, this might be a nice step
> towards improving this use case even without flash support.

Forcing behaviors onto Flash is difficult. Note, however, that plugins
are blocked entirely inside sandboxed iframes
(https://html.spec.whatwg.org/multipage/browsers.html#sandboxed-plugins-browsing-context-flag),
so this probably isn't an interaction we need to worry about.

-mike

--
Mike West , @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany,
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine
Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Mon, May 11, 2015 at 6:11 AM, Mike West  wrote:
>
> 2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the
> `sandbox` attribute, which, when present, would allow auxiliary browsing
> contexts created by `window.open` and `target="_blank"` links to create
> clean browsing contexts, unaffected by the sandbox which spawned them.
>

This flag is in the latest Chrome Canary,
behind chrome://flags/#enable-experimental-web-platform-features, if anyone
is interested in playing with the feature.

Given the generally positive response on this thread, WDYT about adding it
to HTML, hixie@?

I'd like to circle back to the `allow-modals` proposal once
https://www.chromestatus.com/metrics/feature/timeline/popularity/767 hits
stable and starts bringing in reliable data (~12 weeks). I'll ping the
thread again then. :)

-mike

--
Mike West , @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Thu, May 14, 2015 at 3:59 PM, Devdatta Akhawe 
wrote:
>
> 2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the
>> `sandbox` attribute, which, when present, would allow auxiliary browsing
>> contexts created by `window.open` and `target="_blank"` links to create
>> clean browsing contexts, unaffected by the sandbox which spawned them.
>>
>>
> Why isn't a child iframe of the sandboxed iframe an auxiliary browsing
> context?
>

Because it's a nested browsing context. Auxiliary browsing contexts are
related to a context, but not through nesting:
https://html.spec.whatwg.org/multipage/browsers.html#auxiliary-browsing-contexts.
It's just a definitional thing.

-mike

--
Mike West , @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Tue, May 12, 2015 at 6:45 PM, Ian Melven  wrote:

> This is what I expected. showModalDialog is a bit of an edge case perhaps.
> Sounds like this needs a new sandbox attribute value to re-opt back in to
> it like 'allow-modals' or whatever you suggested :) This is a behavior
> change as you said, but I defer to your stats on the (lack of) usage of
> iframe sandbox :(
>

Since Chrome has dropped support for `showModalDialog` entirely, I'm not
terribly worked up about it. :)

If folks want an opt-in, then `allow-modals` is probably a fine way to do
it. Again, it's not clear to me that there's a _good_ use case for modal
dialogs popping up from a frame (even an unsandboxed frame!).

Yeah, my main point was this should be tied to allow-popups somehow. If we
> proceeded this way ('allow-popups' + 'allow-unsandboxed-popups') to me that
> would mean that sandboxed iframe could only ever open unsandboxed aux
> browsing contexts. I think that's probably OK because we can't trust the
> sandboxed iframe to tell us itself whether an aux context it's opening
> should be sandboxed or not - so making this essentially a one time setting
> for the iframe it can't change seems to be correct.
>

That's the way the prototype I'm playing with works (
https://codereview.chromium.org/1139933002). I don't think there's a good
way to specify that some auxiliary browsing contexts are sandboxed and some
aren't. Especially given the general use case of fourth-, fifth-, and
sixth-party sources, nested somewhere inside the deepest darkest corners of
the iframe displaying the content the user actually sees.

Making it a binary toggle for the frame seems reasonable, given that it's
opt-in in the first place.

--
Mike West , @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Tue, May 12, 2015 at 6:05 AM, Brad Hill  wrote:

> Chrome did to that once upon a time (blocking 401 prompts on all
> subresource loads) but it opened up a brute-force hole where the lack of UI
> allowed extremely rapid testing of HTTP Basic requiring resources, so it
> got backed out.  I'm not sure where it eventually ended up, but I know it
> was an issue.  I'd think that for a sandboxed iframe you could be a bit
> more draconian and not just short-circuit the prompt but totally forbid
> connecting to resources which require an Authentication header, blocking
> the avenue of exploit as well as the phishing risk.  It seems there should
> be very few if any use cases for sandboxed content calling
> HTTP-authenticated resources.
>

Yes. That was how I interpreted the suggestion as well; we'd suppress the
dialog by cancelling the request. :)

-mike

--
Mike West , @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

>

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Mon, May 11, 2015 at 11:59 PM, Justin Dolske  wrote:

> On Mon, May 11, 2015 at 7:13 AM, Mike West  wrote:
>
>> > The worst offender: linking to things that are .htpasswd protected and
>> it
>> > pops up that authentication modal.
>> >
>>
>> I wouldn't be terribly averse to dropping support for that inside a
>> sandbox. Especially a sandbox without `allow-same-origin`.
>>
>>
> Firefox sorta does this by default, as of
> https://bugzilla.mozilla.org/show_bug.cgi?id=647010. At least it appears
> to for cross-origin iframes, which I would expect to be the normal case for
> ads?
>

Interesting! Thanks for the pointer to the bug. If Firefox is already going
this route, I don't see any reason Chrome shouldn't follow. It makes sense
to me, in any event.


> Also, along with blocking alert() et al from sandboxed iframes, it would
> be good to include the onbeforeunload dialog. It's a pretty common target
> for abuse. We've got a bug to disable it entirely in iframes (1131187), but
> no one is actively working on it.
>

Ah, yes. I forgot about `onbeforeunload`. I'd happily kill that inside a
sandbox as well. :)

-mike

--
Mike West , @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Mon, May 11, 2015 at 7:24 PM, Ian Melven  wrote:

> 1) At one point i think showModalDialog was specified to be blocked unless
> allow-popups was set. (I can't find this in the current editor's draft of
> the spec).
> It seems to me that it would make sense to follow #1 in your proposal
> (blocking alert and friends) UNLESS allow-popups is specified perhaps ?
> Unless the advertising use case is such that they would want to specify
> allow-popups in most common cases, which negates any benefit of this
> restriction in practice
>

My understanding of the use case is that they want `allow-popups` in order
to allow navigation to a landing page via `target="_blank"`, et al. They
don't want modal dialogs from that same window. Tying both behaviors to
`allow-popups` wouldn't solve their problem.


> 2) this also sounds like allow-popups would be needed (since you shouldn't
> be allowed to open new auxiliary browsing context without it)
>

Correct. Both `allow-popups` and the new flag would need to be specified.


> and maybe is more consistent using 'allow-popups-unsandboxed' ?
>

Or `allow-unsandboxed-popups`. I don't really care how we spell it. :)

--
Mike West , @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Mon, May 11, 2015 at 4:12 PM, James M. Greene 
wrote:

> 1. Block modal dialogs from inside sandboxed frames. That is:
>> * `alert(...)` would return without popping up a dialog.
>> * `confirm(...)` would return `false` without popping up a dialog.
>> * `prompt(...)` would return `null` without popping up a dialog.
>> * `print(...)` would return without popping up a dialog.
>
>
> I'm OK with that.  As a general rule, though, I would prefer that pretty
> much whatever gets blocked by default can be reenabled via additional new
> keywords (e.g. "allow-modals").
>

Sure. It's not clear to me that there's a _good_ use of any of these
methods in an iframe, so I'd prefer to just remove the capability entirely,
but if there's a desire to retain the functionality, I'd certainly
implement something like `allow-modals` in Chrome.


> Although I understand the rational for blocking native plugins by default
> due to their inherent unmanaged nature, I still wish that they could be
> reenabled via a keyword as there are still realistic scenarios where you
> may want (e.g.) Flash enabled but still disallow/disable other features
> like popups, navigation, etc.
>

An issue with Flash (and other plugins) is that they generally bypass the
rest of the sandboxing flags. That is, enabling flash while disabling
`window.open` is somewhat ineffectual, as Flash can just pop a new window
with it's native code.

This is somewhat improved in Chrome, as PPAPI allows us a bit more access
to the ways in which Flash can poke at the system, but it doesn't improve
the (terrible) process model, etc. I think it would still be a bit too
dangerous to introduce an `allow-plugins` flag given the sandboxing state
in other browsers, but it's probably a conversation worth having.


> 2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the
>> `sandbox` attribute, which, when present, would allow auxiliary browsing
>> contexts created by `window.open` and `target="_blank"` links to create
>> clean browsing contexts, unaffected by the sandbox which spawned them.
>
>
> I'm OK with that, too.  I'm assuming that cascades, though, right?  In
> other words, if the top window does NOT use the
> "allow-unsandboxed-auxiliary" keyword on its child iframe, I'm assuming the
> child iframe cannot successfully use "allow-unsandboxed-auxiliary" on a
> child iframe of its own.
>

Yes, this is also how I imagined it working. I should have made that clear
in the proposal, but I think (hope!) this naturally falls out of the way
sandbox flags are propagated from frame to frame/window to window.

-mike

--
Mike West , @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Mon, May 11, 2015 at 4:02 PM, Chris Coyier  wrote:

> I'd think popups would be killed by default and allow-popups would allow
> them. Or if you need a new value, allow-obnoxious-things could work ;)
>

I would prefer to simply remove the functionality. :)

If we do decide that we need `alert()` and friends, I would suggest that
`allow-popups` is the wrong flag to use. The advertising use case I noted
at the top pretty much requires `window.open`/`target="_blank"` to work
correctly. If those only work when `alert()` is enabled, then we wouldn't
solve the issue.


> Like navigator.geolocation (so we regex and strip it).
>

I think permissions for iframes in general are a separate question, but an
important one to deal with.


> The worst offender: linking to things that are .htpasswd protected and it
> pops up that authentication modal.
>

I wouldn't be terribly averse to dropping support for that inside a
sandbox. Especially a sandbox without `allow-same-origin`.

-mike

--
Mike West , @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Mon, May 11, 2015 at 9:19 AM, Jim Manico  wrote:

> The whole purpose of a sandbox is to limit what content inside of it can
> do. I want to limit where that sandbox can open windows with full
> cookie/script/etc access.
>

And you can do so by _not_ specifying the new flag I'm proposing. :)

Again ``'s behavior would not change. The proposal would
add new behavior only for something like ``.


> So essentially I want to say, "You can show your ad, you cant run a script
> or access my main window.  Also, you can only open full-access windows back
> to the same domain that your ad came from."
>

If the ad comes from `advertising-is-awesome.net`, but is pointing users to
the excellent products at `products-are-nice.com`, how would your proposal
allow a click on the ad to navigate a user to the excellent products in an
unsandboxed window (e.g. one that has an origin)? I'd suggest that that's
an essential component. It's certainly essential to advertisers.


> Is that to extreme of an ask? I just dont like the idea that a sandboxed
> resource has full access to open any new window. It seems excessive and can
> exploit CSRF vulns in a way a full sandboxed iFrame as I'm describing could
> not.
>

I still don't understand the threat model you're proposing. That is, I
don't see sandboxing as a CSRF defense at all. Sandboxed frames can
navigate themselves to any origin right now, and load any origin in a
frame. If the `allow-popups` flag is set, it can open auxiliary windows. If
the `allow-forms` flag is set, it can POST to arbitrary origins.

-mike

--
Mike West , @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Mon, May 11, 2015 at 7:27 AM, Jim Manico  wrote:

> > 2. Allow sandboxed frames to spawn new windows without forcing the
> sandbox upon them.
>
> I think this needs to be restricted so sandboxed iFrames cannot spawn new
> windows back to the same domain - or better yet may only spawn windows to
> limited domain/domains driven by the initial ad request.
>

What risk do you see that mitigating? How would you expect it to behave
with regard to redirects or navigations? I guess I don't see the value in
adding these kinds of restrictions, and (especially given the target
audience, and their predilection for tons and tons of cross-origin
redirects) it seems like making it easier to sandbox the inlined frame
outweighs the desire to lock down the out-of-line auxiliary browsing
context.

Also, note that the proposal already makes the behavior opt-in via the
`allow-unsandboxed-auxiliary` keyword (it wouldn't change the behavior of
any existing sandboxed frame), and browsers generally throttle the creation
of popups in various ways (Chrome allows only one popup per user gesture,
for instance).

--
Mike West , @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

[whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

(BCC: public-webapp...@w3.org)

Hello, wonderful whatwg@ folks!

I've talked with a few folks from Google's advertising teams who are
interested in using sandboxed iframes to mitigate the risks associated with
ads. They've flagged two things that they'd like to see happen in the
future:

1. Block usage of `alert()` (and its friends `confirm()`, `prompt()`, and
`print()` (and `showModalDialog()` for browsers that support it)).

2. Allow sandboxed frames to spawn new windows without forcing the sandbox
upon them. This would allow the advertisement itself to be sandboxed,
without forcing the same restrictive flags upon a landing page.

# Proposal

1. Block modal dialogs from inside sandboxed frames. That is:

* `alert(...)` would return without popping up a dialog.
* `confirm(...)` would return `false` without popping up a dialog.
* `prompt(...)` would return `null` without popping up a dialog.
* `print(...)` would return without popping up a dialog.

This was discussed briefly at
https://lists.w3.org/Archives/Public/public-whatwg-archive/2014May/0002.html,
but I didn't find any follow-up (CCing folks from that thread). I've added
metrics to Chrome in https://codereview.chromium.org/1121053002, but it
will take a few weeks to get good data. Given the low usage of sandboxes in
general (~0.5% of page views, according to
https://www.chromestatus.com/metrics/feature/timeline/popularity/672), I
suspect we could fairly easily make this change.

2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the
`sandbox` attribute, which, when present, would allow auxiliary browsing
contexts created by `window.open` and `target="_blank"` links to create
clean browsing contexts, unaffected by the sandbox which spawned them.

WDYT?

--
Mike West , @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

[Mike West]

On Thu, Oct 16, 2014 at 4:28 PM, Eduardo' Vela"  
wrote:

> Well, it doesn't today. But maybe you mean in the future.
>

You're right, sorry. I was thinking of blob-based workers. Maybe we should
do the same for frames?


> But the point is that there are many ways to exfiltrate, these are just
> the first thing that comes to mind but others like  also are
> an info leak, and I mean, these are just ideas coming up the top of my
> mind, the browser wasn't designed to solve this problem and it's dubious if
> it's really feasible to do so without reinventing a lot of things.
>

http://mikewest.github.io/credentialmanagement/writeonly/#input-behavior
outlines a few mechanisms, and potential resolutions. `pattern`, for
instance, is addressed by blocking input validation on the form field.

As you suggest, I'm sure there are more mechanisms. I don't think there are
infinite mechanisms, however, and I'm fairly certain that we could address
those that exist.


>
>
>> I wasn't clear: the server still needs to accept a bare username/password
>> pair, as it's not the case that users only log in a) using a password
>> manager, b) on a machine that's syncing. As long as that's the case, I
>> don't see how tying passwords to a cookie makes password theft less
>> problematic.
>>
>
> The user would just have to type the full password (including the extra
> cookie-random value that the password manager backed up). The caveat of
> course is that the user has to write this suffix somewhere, but that is
> what makes the password strong anyway.
>

I don't think asking users to remember a password and a random value is
tenable.


> And anyway, to be clear, this is just a discussion on an alternate design
> that has the same properties and is significantly easier to implement for
> both, authors and UAs, but it's by no means the only solution. My point is
> that there are probably simpler solutions that have similar security
> guarantees.
>

I'll reassert that this proposal is simpler for authors (11 character
opt-in) and users (no change) than the scheme you just outlined. It's more
complex for browser vendors, but that's fine and expected, as we're way
down at the bottom of the priority heap.

--
Mike West 
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

[Mike West]

On Thu, Oct 16, 2014 at 12:16 PM, Eduardo' Vela"  
wrote:

> On Thu, Oct 16, 2014 at 11:59 AM, Mike West  wrote:
>
>> On Thu, Oct 16, 2014 at 10:36 AM, Eduardo' Vela"  
>> wrote:
>>
> OK, so it's just being locked down out of a formality, but has no security
> purpose. Sure, so it's not useful for any security purposes.
>

Well, no. It doesn't solve the problem, but it introduces a hurdle. Making
an attacker do more work is good.

> 2. How is the tainting problem simplified by focusing on write only?
>>>
>>  Focusing on autofill means that we're moving the flag up to the
>> credential, so we can ensure that the browser only autofills into writeonly
>> form fields. To your specific example, it means we don't have to care about
>> blobs in iframes, because (I'm pretty sure...) we don't autofill blobs in
>> iframes.
>>
>
> The blob: URL would simply steal the FormData from the other page (it's
> same origin), and submit it via XHR to another origin..
>

Ah, that's clever! However: blobs inherit the CSP of their parent frame, so
the same mitigations apply.

Moreover, if we're doing the network-stack replacement thing, and we know
details about the credential, then we can refuse to do the replacement in
the browser process if the destination doesn't match the details we have
stored for the credential, CSP or not.

> 3. How is tagging the credential as write-only help with the secure
>>> deployment of a site-wide CSP policy?
>>>
>> It doesn't. The two are completely unrelated.
>>
>> My point was simply that if we tag a credential as writeonly, we wouldn't
>> fill it into a form that lacked the writeonly flag in a page that lacked
>> the writeonly CSP. Solving CSP deployment isn't a precondition of this
>> scheme.
>>
>
> I see, so it wouldn't be sufficient to make a field writeonly, you would
> also need to declare that in the CSP.
>

Let me rephrase: if we tag a credential as writeonly, we wouldn't fill it
into a form field that wasn't writeonly. Form fields are tagged writeonly
either by virtue of an inlined attribute, or a CSP on the page.

Either individually signals to the browser that the site does not intend to
make programmatic use of the field's value. We wouldn't need both in order
to decide when to tag a credential as writeonly.


> The whole website would have to have connect-src policies stricly
> restricting the exfiltration of data from the domain. Is there any
> (relevant/important) website where locking down connect-src for the whole
> origin is possible or feasible? Or are we assuming every website has their
> login form in a unique origin? (Are you expecting to have per-page
> suborigins implemented before this is feasible?).
>
> 4. Why are sites that echo passwords in password fields shooting
>> themselves in the foot?
>>
> Echoing sensitive data in a place where an injected XHR can read it is a
>> general problem. This proposal doesn't make that worse.
>>
>
> Sensitive data is echoed in places where XHRs can read all the time. Your
> email, your authentication credentials (OAuth, etc), your bank statements.
> This isn't a general problem.
>

It is a general problem, given the attack vector you're proposing: if I can
inject a same-origin XHR, I can read sensitive data. That includes
passwords, if the passwords are echo'd out in the page's contents. I'm
agreeing with you that writeonly doesn't solve this problem.

I'd suggest that sites themselves could solve it by echoing a nonce rather
than the original password, but that's obviously up to them and not
something we could spec.

> Sounds like a great way of hardening sign-in. It's not clear to me how
>>> that negates the problem of password theft, as I'd still need to be able to
>>> sign in on my friend's computer when I accidentally spill coke on my
>>> laptop, right?
>>>
>>
> How is the password manager able to sync your password to your friend's
> computer?
>

I wasn't clear: the server still needs to accept a bare username/password
pair, as it's not the case that users only log in a) using a password
manager, b) on a machine that's syncing. As long as that's the case, I
don't see how tying passwords to a cookie makes password theft less
problematic.

--
Mike West 
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

[Mike West]

On Thu, Oct 16, 2014 at 10:36 AM, Eduardo' Vela"  
wrote:

> 1. How are keyup/down/press restrictions useful for password protection?
> Actually they seem more useful for CSRF instead.
>
These events are some of the many ways in which the data being typed into a
particular field is exposed to script. If we're going to call the field
writeonly, we need to lock those down. That said, they only protect that
particular field: attackers can easily bypass this restriction by doing
more work (overlaying a new form, etc).

How are they useful for CSRF? I don't see the link.

> 2. How is the tainting problem simplified by focusing on write only?
>
 Focusing on autofill means that we're moving the flag up to the
credential, so we can ensure that the browser only autofills into writeonly
form fields. To your specific example, it means we don't have to care about
blobs in iframes, because (I'm pretty sure...) we don't autofill blobs in
iframes.

> 3. How is tagging the credential as write-only help with the secure
> deployment of a site-wide CSP policy?
>
It doesn't. The two are completely unrelated.

My point was simply that if we tag a credential as writeonly, we wouldn't
fill it into a form that lacked the writeonly flag in a page that lacked
the writeonly CSP. Solving CSP deployment isn't a precondition of this
scheme.

> 4. Why are sites that echo passwords in password fields shooting
> themselves in the foot?
>
> Echoing sensitive data in a place where an injected XHR can read it is a
general problem. This proposal doesn't make that worse.

> Imagine if the password manager, instead of just syncing passwords around
> also moved an httpOnly cookie. And whenever it detects the password going
> by it appends the httpOnly cookie.
>
> If the server detects such cookie in the request it concatenates it after
> the password and uses that as the auth credential.
>
> On the server, this only requires a one line change (adding he cookie at
> the end if present), on the client the APIs already exist.
>
> Same can be done with Channel ID with the further advantage that the OBC
> can't be copied. The advantage of the cookie approach is that it can be
> morphed and generated more easily.
>
Sounds like a great way of hardening sign-in. It's not clear to me how that
negates the problem of password theft, as I'd still need to be able to sign
in on my friend's computer when I accidentally spill coke on my laptop,
right?

> Also, as a point of reference we've redone authentication many more times
> in a lot less time with a lot less resources than deployed CSP across all
> of Google. So yes, it's easier.
>
That surprises me.

Still, I suspect both are significantly more work than adding an attribute
to a form field.

--
Mike West 
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Hashing autofilled data (was Re: Proposal: Write-only submittable form-associated controls.)

[Mike West]

On Thu, Oct 16, 2014 at 11:43 AM, John Mellor  wrote:

> On 16 October 2014 08:52, Mike West  wrote:
>
>> * Server stores credentials as `sha512(password + username)`.
>>
>
> It might be better to require PBKDF2/bcrypt/scrypt.
>

Yeah, that certainly makes sense.

-mike

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

[Mike West]

On Thu, Oct 16, 2014 at 1:31 AM, Eduardo' Vela"  
wrote:

> Yea the keyup/down/press restrictions are definitely not useful, at least
> for password protection since the user has clearly no way to know if the
> field is safe or not.
>

I'd disagree that they're useless, but they're certainly not a robust
defense against an attacker reading information that you type into a form.


> The tainting is never gonna work reliably and consistently as Michal hinted
> (say, a blob: URL would run in the same origin but not be bound to CSP
> which could be used to exfiltrate the data).
>

The tainting problem is simplified by focusing on the part I care about:
autofill.


> The dependency on CSP also makes this a bit aspirational. I can agree that
> the login form could be CSP protected but the whole origin is not as
> likely. Specially for connect- and form-.


As noted in a previous response, I see these concerns as somewhat mitigated
by tagging the credential as writeonly in a way that would prevent autofill
into a read/write form.


> And even that might be insufficient (its a common practice to echo back
> typed passwords when the user doesn't answer a captcha or has it wrong, for
> example - a same-origin XHR will leak the password).
>

As I think you'd agree, those pages are already shooting themselves in the
foot. You're correct that this proposal doesn't solve their problems, but
that's not a unique disadvantage of the proposal. :)

There are other solutions that seem more likely to work to solve the
> problem of password managers (something like a synced channelId, for
> example, or even FIDO style solutions). This proposal seems to try to
> achieve a mixture of just replacing canary values at the network layer
> based on destination with an httpOnly-style model for user-supplied data.
>

1. Password managers aren't the problem. Especially when used to generate
even vaguely secure password, they make authentication on the web
significantly less insecure than it would otherwise be.

2. The various proposals on http://www.browserauth.net/ like channel-bound
cookies (which I think you're referring to above?) can solve cookie theft.
They don't solve password theft.


> If we have a password manager and are gonna ask authors to modify their
> site, we should just use it to transfer real credentials, not passwords..
> Passwords need to die anyway.
>

You ding CSP as a "bit aspirational", and then propose killing passwords.
*cough* :)

As long as "modify their site" means "type 11 characters into your site's
template" and not "rewrite your authentication stack from the ground up
using technologies you've never heard of", I think it's something we can
reasonably ask of authors. The central advantage of the writeonly proposal
is that it's a trivial drop-in change. It's certainly not the real
revolution in authentication that we desperately need on the web, but
that's a feature, not a bug. :)

-mike

--
Mike West 
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

[whatwg] Hashing autofilled data (was Re: Proposal: Write-only submittable form-associated controls.)

[Mike West]

Forking this out into a separate thread, as I think it deserves some
additional consideration.

On Thu, Oct 16, 2014 at 5:05 AM, Roger Hågensen  wrote:

> There is also legitimate needs for being able to edit the password field
> from a script.
> I have a custom login system (that is currently in public use) that takes
> the password, does a HMAC on it (plus a salt and some time limited
> info). This allows login in without having to send the password in the
> clear. It's not as secure as https but it's better than plaintext.
>

Sigbjørn Vik (CC'd) suggested something similar in a previous conversation.

I think it's probably reasonable for a password field to specify that some
sort of operation be done on its value before it's sent over the network.
It's not clear to me exactly what would be necessary in order to prevent
replay attacks, but it seems quite possible for the site to ask the browser
to salt and hash the value in some known way before passing it on:

If user agents offered some sort of well-understood set of operations that
could be performed on a password before sending it over the wire, they
could potentially avoid ever knowing the password, which might be nice
(though it would certainly require substantial rewrites on their backends).

As a hand-wavey strawman that I haven't thought too much about:

* Server stores credentials as `sha512(password + username)`.
* Server provides a nonce ('a') as part of a sign-in form, saves that nonce
for the given session, and points to the username field as a salt.
* The user agent injects a nonce ('b') into the sign-in form in some
well-known field, and fills the password field with `sha512(sha512(password
+ username) + a + b)`.

The server now has everything it needs to compute the same hash as the
client. If the hashes match, yay. Sign the user in.

There are certainly better ways to do this, perhaps even some that wouldn't
require really significant work on the server side to support.

Any limitations on form manipulations should be based on same origin
> limitations instead, such that only a javascript with the same origin as
> the html with the form can read/write/manipulate the form.


This is a very difficult problem, as evidenced by Chrome and Firefox's
struggles to allow extensions to bypass CSP. It's tough to keep track of
the origin of an action, especially when that action is the result of an
event handler or some other asynchronous action that no longer has a clear
call stack back to it's originator.

It's unlikely to be implemented. CSP locking down the sources of script is
the best we can offer, I think.

--
Mike West 
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

[Mike West]

On Wed, Oct 15, 2014 at 6:27 PM, Michal Zalewski 
wrote:

> So I might have started this on the wrong foot


Naah. Your criticism is a) not unexpected, and b) totally accurate. I
hopefully believe that you're overstating the negatives, and
underestimating the positives, but that's kinda your job. :)

Also, I did a poor job of making my actual desire clear; I should have
focused more on the problem, and less on the proposed solution. I'll try to
be more general going forward: In a nutshell, Chrome's non-browser
processes are corrupted significantly more often than it's browser process.
Reducing their ability to request credential data seems like a
straightforward win. In order to do that without breaking valid use-cases,
we need a signal from the page that it's not intending to touch the value.
This signal is conceptually similar to CSP's broader "I'm not going to use
eval()." or "I'm not going to use XHR." statements, and would allow
password managers to flag credentials as writeonly, similar to how we flag
cookies as httponly today.

"writeonly" is only one way to provide this signal. Its advantage is
simplicity: existing sign-in forms can add this attribute today without
changing anything else at all in their flow.

1) XSS stealing the passwords / CC numbers entered by the user
> manually? This is probably not possible with this proposal; the evil
> payload may construct a form where the writeonly attribute is not set.
>

Yup. That's not a scenario that this proposal improves in the slightest. If
the user is typing something into a corrupted page, attackers can read that
something in a number of ways.


> 2) XSS stealing the passwords entered by the password manager? To do
> this, I feel that we need a taint-tracking system coupled with a
> password manager that remembers that some passwords can go only into
> writeonly fields, and which URLs and methods they need to be submitted
> to.
>

This is the scenario I'm focusing on.

We already track much of the form's context in Chrome's password manager in
order to determine which credential to insert into a given form. I imagine
other password manager do likewise. We're not using that data in this way
yet, but it's certainly a direction I'd like to explore.


> The CSP solution + blocking GET feels like a crutch that won't work in
> practice;


(Restricting browser's autofill of password and credit card data to POST is
probably something we should do regardless of this proposal.)


> my main concern is that writing site-wide policies is hard
> as-is, and that the likelihood of well-scoped per-page policies,
> especially with path granularity, is low.


On the web at large, yes. For particular form fields that we know to be
interesting, maybe no. I just tried Google, Facebook, and PayPal's sign-in
forms: none touched the password field before sending it out on the wire.
Allowing them to assert that they're not going to, and to protect users'
saved credentials based upon that assertion, seems like a reasonable goal.


> But if we go the CSP route,
> breaking writeonly fields if form targets are not policed may be the
> best we can do.


Also note that there's no reason that the password manager couldn't mark
form fields as writeonly when inserting known-to-be-writeonly
credentials  (or simply refuse to autofill into a read/write field). We
don't have to rely on the field being pre-protected if we know that it
asserted certain things in the past when we saved the credential in
question. Both CSP and the inline attribute could be treated as persistent
signaling mechanisms, conceptually similar to httponly or HSTS, which
mitigates some of the risk you're pointing to here.


> (Also note that my attack #3 will work simply if XSRF
> tokens are user- but not action-bound, which is a common pattern.) I
> also expect many other corner cases to crop up when others look at the
> implementations later on.
>

Granted.


> 3) Regular compromised renderers / malware stealing the data manually
> entered or automatically populated by the browser? Not doable.
>

Assuming that we ever send the information to the renderer, granted. I'd
like to avoid doing that by, for example, sending a nonce to the renderer,
and replacing that nonce in the browser process before sending the request
out onto the network.


> 4) Future Chrome origin-bound sandboxed renderers stealing the data
> manually entered by the user? Probably not doable, by analogy with #1.
>

Granted. Data the user types into a page is always readable, one way or
another.


> 5) Future Chrome origin-bound sandboxed renderers stealing the data
> auto-populated by the password manager? Feels like for this, we need
> taint tracking; otherwise, the renderer can ask for the password under
> false pretenses, perhaps after loading a sub-page with different or no
> CSP rules.


Consider that we can use this signal to flag the _credential_ as writeonly.
We don't have to rely on the form _always_ being so flagged.


> We could try 

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

[Mike West]

On Wed, Oct 15, 2014 at 6:10 PM, Tab Atkins Jr. 
wrote:

>
> Nothing in-band will work, because the attacker can replace arbitrary
> amounts of the page if they're loaded as an in-page script.  It's
> gotta be *temporally* isolated - either something out-of-band like a
> response header, or something that has no effect by the time scripts
> run, like a  that is only read during initial parsing.
>

Yes. Hence the CSP directive portion of the proposal.

The inline attribute is useful for the specific password manager case I'm
concentrating on, as it gives us a clear indication that the site doesn't
intend to do wacky manipulation of its credentials on the fly. We can use
this to determine how and when the password manager (or credit card
autofill, or whatever) ought to refuse to expose information to the
renderer.

--
Mike West 
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

[Mike West]

On Wed, Oct 15, 2014 at 5:59 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

> For the XSS attacker, couldn't they just use
> `theInput.removeAttribute("writeonly"); alert(theInput.value);`?
>
> Or is this some kind of new "un-removable attribute"?
>

The strawman suggests setting a flag on the element, and doesn't suggest a
way of unsetting that flag. This is conceptually similar to iframe@sandbox's
effect on the document loaded into the frame.

--
Mike West 
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

[Mike West]

On Wed, Oct 15, 2014 at 5:16 PM, Michal Zalewski 
wrote:

> > Fair enough - although I worry that the likelihood of people using
> > this in conjunction with tightly-scoped per-document CSP (versus the
> > far more likely scenario of just having a minimal XSS-preventing
> > site-wide or app-wide policy that will definitely not mitigate #3 and
> > probably do nothing for #1) are pretty slim.
>
> In fact, the XSS-preventing part is probably a stretch. Facebook and
> Twitter are often mentioned as the two most significant customers for
> CSP, but both use unsafe-inline and unsafe-eval.
>

True. Because both have huge legacy systems built on inlining JavaScript.
That's an architectural change that is really truly difficult in aggregate.

The same is not the case for login forms. Or credit-card forms, for that
matter.

The only sites that wouldn't be able to implement something like this
without significant effort are those who do client-side encryption (well,
"encryption") of the sensitive data before passing it on to the server.


> On top of that, note that #3 is not defeated by origin-scoped rules -
> you need to specify full paths.
>

You're correct. I mentioned that. :)

#3 also relies on the site having a comment form, or some other mechanism
of publicly reflecting POST data to the world without a CSRF. Lots of sites
have that sort of mechanism, sure, but I don't think that even a majority
of high-value sites do.

Honestly, if we're creating a mechanism that implies that a degree of
> protection is provided for password fields, we should either make it
> work on its own


Do you have suggestions for what "on its own" might look like?


> , *or* at the very minimum require a CSP with
> form-action specified, and otherwise warn or better yet, break fields
> flagged as writeonly.
>

Sure. Doing one or both is probably pretty reasonable. :)

-mike

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

[Mike West]

Good feedback, Michal. Thanks!

On Wed, Oct 15, 2014 at 4:41 PM, Michal Zalewski 
wrote:

> > 
>
> I think that one huge problem with this is that the attacker will have
> many other, indirect ways to get the value even if you protect direct
> access to the field. Two most obvious options include:
>

Note that there are two types of attacker I care about:

1. XSS. You've outlined some (of the probably many) ways to bypass the
kinds of protection I'd like to build here. Let's discuss below.

2. Renderer flaws. Currently, if someone can corrupt Chrome's renderer
process, she can request any and all passwords from the password store by
pretending to be various origins. If we can mark certain credentials as
"writeonly", we know we never have to send them to the renderer, and that
any such requests could be ignored. This is similar to what (I hope) we're
doing with `httponly` cookies (though I haven't checked, it seems like an
obvious optimization).


> 1) Change the action value for the form to point to evil.com, where
> evil.com is in attacker's control,
>

I hope that this is mitigated by the `form-action` CSP directive, which
allows the site to control the valid endpoints for form submission, and
`connect-src`, which allows the same for XHR, EventSource, WebSockets, etc.


> 2) Change the action of the form to GET while keeping the same method,
> let it submit, and then examine location.search.
>

Good idea. One way of avoid this would be to lock all forms with writeonly
data and XHR with opaque FormData to the POST method. That's probably what
we'd like folks to be doing anyway in order to keep potentially interesting
information out of server logs and browser history.


> 3) Change the action value of the form and the name of the password
> field so that the posted data is interpreted by the server as an
> attempt to, say, post a comment.
>

Again, mitigated (but by no means avoided) by path restrictions on the
`form-action` CSP directive.


> I worry that there's actually more, and that a lot of nasty "taint
> tracking" heuristics would be required to make it go away.
>

That's something I'd like to avoid, insofar as possible. I think it's
likely unavoidable to have some sort of opaque flag on request objects in
order to do the right thing with regard to ServiceWorkers, but since we
already track opaqueness for responses, I hope that's not an overly
burdensome taint to track.

-mike

--
Mike West 
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

[Mike West]

Yes. Two things about service workers:

1. If you can spin up a service worker, the site is already very much in
trouble.

2. I have handwavey ideas about ensuring that the FormData object which
would be readable via the Request object in the service worker would retain
the opaque flag. The spec strawman hints at that, but I haven't done the
work to find all the places to monkey-patch.

-mike

--
Mike West 
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Wed, Oct 15, 2014 at 4:25 PM, Boris Zbarsky  wrote:

> On 10/15/14, 10:15 AM, Mike West wrote:
>
>> `FormData` objects created from forms including these writeonly elements
>> would be "opaque". You could use them to submit an XHR request, but you
>> couldn't read the values directly from script.
>>
>
> If you're at the point where you can run script on the page, can't you
> spin up a service worker that would capture the data in that XHR?
>
> -Boris
>

[whatwg] Proposal: Write-only submittable form-associated controls.

[Mike West]

# Problem

A user’s credentials are valuable, and are often the key target of phishing
and content injection attacks. If a content injection attack can trick a
user's credential manager into autofilling her credentials, then the user’s
credentials will be available to the attacker directly via DOM APIs or
indirectly via form submission to a malicious endpoint. The latter risk can
be mitigated via the Content Security Policy `form-action` directive, but
the former is a real problem. If passwords are a simple value accessor
away, users are at risk.

## Proposal

We could mitigate this latter risk by allowing sites to opt-in to denying
DOM access to an element's content. If JavaScript can't grab the value,
then script injection attacks have a much more difficult time exfiltrating
interesting data. This might be as simple as adding a writeonly attribute
to submittable elements:



This would throw an `InvalidStateError` on `value*` accessors, bar the
element from constraint validation, block `keydown`, `keyup`, `keypress`
events, and probably other things I haven't considered yet.

`FormData` objects created from forms including these writeonly elements
would be "opaque". You could use them to submit an XHR request, but you
couldn't read the values directly from script.

This state could also be controlled via a Content Security Policy directive
which would set writeonly state for some arbitrary set of submittable
elements, perhaps based on autocomplete attribute values. Perhaps:

Content-Security-Policy: form-writeonly cc-number cc-csc ...
current-password new-password

## Spec Suggestions

I've strawmanned out the monkey-patching this would require of XHR, Fetch,
and HTML in a bit of detail at
https://mikewest.github.io/credentialmanagement/writeonly/, and there was a
short-lived public-webapps thread at
http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0165.html (and
a shorter-lived discussion at
http://specifiction.org/t/write-only-input-fields/598).

## Implementer Interest

I'd like to implement pieces of this in Chrome to harden our password
manager; if we can use this state as a heuristic to mark particular
credentials as writeonly, we can keep them out of the renderer process
entirely, which would be a nice win for security.

I've also talked about it tangentially with Anne and Jonas at Mozilla (the
former in relation to Fetch, the latter in relation to a proposed
Credential Management API). Neither jumped on it as the best thing ever,
but they were both more than marginally supportive.

Thanks!

--
Mike West 
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Various autocomplete="" topics

[Mike West]

On Wed, Apr 2, 2014 at 10:56 PM, Ian Hickson  wrote:

> > Also, consider the case of login forms without username fields. You see
> > this sort of thing a lot these days, when sites remember who was last
> > logged in:
> >
> > 
> > Password for hober: 
> > Not hober? Click here to sign in.
> > 
> >
> > It's difficult for tools to manage the user's auth info for such pages.
> > How can tools discover what the username is? The obvious solution, in a
> > world with autocomplete=username, would be to add  > autocomplete=username name=username value=hober> to the form.
>
> So far, autocomplete="" hasn't applied to . This would
> be a bit weird, giving it a different meaning than usual (providing
> information to the UA, rather than getting information from the UA). I'm a
> bit skeptical of this kind of overloading.
>
> Not sure what the right solution is, though.
>

As Garrett noted, this is already a solution Google is using, though not
with explicit syntax, just taking advantage of existing heuristics. Paving
this (potential) cowpath isn't really that weird.

That said, an alternative might be to add a mechanism of associating
autocompletion metadata with the field in order to give the UA enough
context to fill it in. For example, if a password is being requested for a
known username, that username could be added as an new
"autocomplete-username" attribute (similar to the 'data-*' construct HTML
already supports):



-mike

--
Mike West 
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Sandboxed IFrames and downloads.

[Mike West]

Ping. Is this a terrible idea? :)

--
Mike West , Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91


On Sat, Feb 2, 2013 at 7:11 PM, Mike West  wrote:

> It's currently possible to force a download by serving a file with a
> "Content-Disposition: attachment; filename=..." header. Notably, this
> mechanism can be used to download a file with minimal user interaction by
> including the resource to be downloaded in an IFrame. This holds even for
> sandboxed IFrames, as demonstrated by
> http://lcamtuf.coredump.cx/sandboxed.html (clicking that link will
> download a file, fair warning).
>
> It seems consistent with the general thought behind the `sandbox`
> attribute that it should control downloads as well as the bits it already
> locks down. I'd propose adjusting the spec to include a sandboxed downloads
> flag, which, when present, would block all downloads from inside the frame
> (or, perhaps only require user confirmation?). This restriction could be
> lifted via an 'allow-downloads' keyword, if present in the sandbox
> attribute's token list.
>
> WDYT?
>
> --
> Mike West , Developer Advocate
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>

[whatwg] Sandboxed IFrames and downloads.

[Mike West]

It's currently possible to force a download by serving a file with a
"Content-Disposition: attachment; filename=..." header. Notably, this
mechanism can be used to download a file with minimal user interaction by
including the resource to be downloaded in an IFrame. This holds even for
sandboxed IFrames, as demonstrated by
http://lcamtuf.coredump.cx/sandboxed.html (clicking that link will download
a file, fair warning).

It seems consistent with the general thought behind the `sandbox` attribute
that it should control downloads as well as the bits it already locks down.
I'd propose adjusting the spec to include a sandboxed downloads flag,
which, when present, would block all downloads from inside the frame (or,
perhaps only require user confirmation?). This restriction could be lifted
via an 'allow-downloads' keyword, if present in the sandbox attribute's
token list.

WDYT?

--
Mike West , Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

[whatwg] `window.location.origin` in sandboxed IFrames.

[Mike West]

Hello!

In WebKit, loading '' with a framed document containing
'alert(window.location.origin);' alerts the actual
origin of the document, which wasn't what I expected. I'm not sure
what's intended, but I expected that treating the framed document as
existing in a unique origin would have some effect on the string
output as it's location's origin.

Adam explained that WebKit currently treats the 'origin' attribute as
the origin of the document's location, not the origin of the
document[1]. This is generally benign, but surprised me in the
sandboxed case.

What should the expected behavior in this case be? Given the way that
MessageEvent sets the origin of a message from a sandboxed frame to
the string "null", that seems like a reasonable option here as well.

WDYT?

[1]: https://bugs.webkit.org/show_bug.cgi?id=106488#c1

--
Mike West , Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91