>> 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. > >> 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.
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. We're effectively adding a mechanism that works well only if you remember about a fairly counterintuitive gotcha, which realistically means that it won't be used correctly something like 90%+ of the time. Cheers, /mz
