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

On Wed, Oct 15, 2014 at 5:16 PM, Michal Zalewski <lcamtuf@coredump.cx>
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

Received on Wednesday, 15 October 2014 15:38:22 UTC