Apologies for the delayed reply. Comments inline. Thanks, Nick
On July 29, 2014, at 5:22 PM, Jonas Sicking <[email protected]> wrote: > On Tue, Jul 29, 2014 at 5:04 PM, Nicholas Doty <[email protected]> wrote: >> Omitting credentials would seem to lessen the concern of using Beacon for >> CSRF attacks. (I admit that the presence of the Origin and Beacon-Age >> headers should also help with that.) > > Again, Beacon as well as CORS only sends requests that <form> has done > since before HTML4. So I don't see what the concern is. If you still > have concerns it would help if you could specify them more in detail. As I understand it, your comment is that the attack surface is identical to implementations of existing form submission requests. CORS calls this a "simple cross-origin request" [0]. 1. Is Beacon limited to these simple cross-origin requests? In at least some documentation for these simple requests, they're limited in Content-Type to application/x-www-form-urlencoded, multipart/form-data, or text/plain [1]. Does Beacon limit Content-Types that way? It seems like users of this API could set the type attribute to a different value and make a cross-origin POST with a different Content-Type. (Maybe the reference to Fetch/CORS is intended to cover this case with a pre-flight request. I honestly can't interpret the pseudocode Fetch spec to determine if that's the case.) [0] http://www.w3.org/TR/cors/#security [1] e.g. https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Simple_requests 2. Can we document this in security considerations for the document? If Beacon is intended to only send requests that could already be accomplished as simple cross-origin requests through form submissions, it would be useful to explicitly note this in the specification. If an implementer wanted to provide a more limited and secure implementation (where they didn't allow certain cross-origin form submission requests), it would be useful for that implementer to see that condition in this specification. If in the future implementers wanted to reduce attack surface, it would be useful to have documentation of all specifications that currently allow for cross-origin POST requests, and under what conditions. 3. I see that there's a new "Privacy" section with a reference to HTML5, but the referenced section doesn't describe form submissions (as the reference implies that it does). I suspect that CORS would be more useful, as it describes the issue of "congruent with ... currently deployed user agents". >> Also, Doug seems to have asked a similar question to what I had about >> whether preflight is required. As I read it now, it seems like preflight is >> always required (because Beacon-Age is not on the simple headers list). But >> your response suggests that preflight would only be required on certain MIME >> types. Could you clarify? > > My understanding is that preflights are only caused by *page* provided > headers. Headers added by implementation never cause preflights. > > For example neither "Host" nor "If-modified-since" are simple headers, > but despite being sent very frequently, they don't cause preflight. The Fetch spec doesn't distinguish different types of header lists. CORS does note the "author request headers" list which I take to be what you're referring to, but the Beacon spec just uses the Fetch spec with the single header list. Maybe Beacon should actually make use of the CORS reference and then explain which of the headers are author request headers.
signature.asc
Description: Message signed with OpenPGP using GPGMail
