Support (secure?) CORS requests to /verify

[broofa]

Can someone please elaborate on why CORS is not supported (and, in fact, was removed in 29a2482)?

I assume the answer lies in the general tone of the security wiki page, that hints at how client verification is generally considered to be bad practice. That said, being able to do verification on the client is pretty appealing. Both for testing purposes, and as a way of enabling client-only applications that allow for identification.

[benadida]

It's appealing, but it's completely insecure, so we took it out because we noticed that it encouraged developers to follow an insecure pattern. One Greasemonkey script, one simple browser add-on, and an attacker can fake the return value from the CORS call in your local app and authenticate as whomever they like.

[lloyd]

Yeah, I was personally against the heavy handed removal of this initially, but once we found that many people were using it in insecure ways, it became a disservice, imo.

It's pretty easy to build a little proxy api on your service that bounces verifications off the verifier, but I understand the frustration.

[broofa]

Removing this feature really feels like it's just pushing the problem into the hands of people who have less incentive to address it properly. For example, the ease with which a "little proxy API" can be built means there is going to be a proliferation of public BrowserID proxies... some of which will likely serve Access-Control-Allow-Origin: * responses by default.

Would it not be better to have support for this in a central location, with good documentation about what does and does not constitute best practices? One might even go so far as to have a JSON-breaking prelude on CORS responses along these lines...

for(;;) /* Validating on the client is bad for these reasons: http://browserid.org */
{... identity JSON}

... so anyone using CORS has to explicitely remove the warning before their JSON will parse. Now, mind you, I'm not saying this is a good idea, but it has the dual benefit of publicizing the issue (.vs. the current policy of simply ignoring it), while offering up still-useful functionality where it might be needed.

[broofa]

Not too that there's a difference between removing a feature that contains a security hole .vs. merely removing a feature that can be used to create insecure systems.

[benadida]

@broofa I hear you that this is frustrating.

What we took into account is that people were simply not reading the documentation and thus doing things insecurely. Offering the feature and expecting developers to read the documentation to do it securely breaks a key principle: secure by default.

Offering the feature in a way that, by default, will freeze their browser, is interesting, but I think that would lead to more developers thinking our system is broken than to them actually investigating why their system is freezing / not parsing correctly.

Other than for demo purposes, there is no good/secure way to do this via CORS. So we think it's the right thing to keep it out.

[broofa]

I'm not frustrated - if my tone came across as such then that's my bad. My goal here was as much to get the rational for this decision documented as it was to actually call the decision into question. :)

That said, I'm still not entirely convinced. Developers looking to do XHR+CORS will google around until they find the shortest path to a solution. Currently this means looking here to see why it's not supported (hence, my asking this question so there's a chance they'll find the answer), but at some point that the shortest path will involve some forum post where someone says, "oh, just user the BrowserID proxy that so-and-so is providing", with no mention of the security issues involved.

I think a blessed CORS solution, that brings awareness to the ways in which it my be abused, is probably better in the long run. Just my $.02 though.