On 5/11/10 12:27 AM, Nathan wrote:
This leaves us in a scenario where it is the norm to download, install
and trust an application that runs in the browser
Perhaps. The difference is that it's much harder to do a drive-by app
install.
agree~ish, imho it's more the user giving the Site A potential access to
all the data from Site B which the user has permission to see; if the
browser pops up that facebook is trying to access company-payroll then
surely the user will be able to make a pretty informed decision..?
You assume the server the company payroll is on is something the user
will recognize. What if it's just arachnid.mycompany.com? Or even
a1273.mycompany.com? Or cluster-16-machine-2.mycompany.com?
agreed, perhaps if that decision was taken out of their hands for
critical resources which they didn't control (like company-payroll) it
would be a better scenario... perhaps one could use something like cors
to limit xhr access to critical resources..
The problem is that there is _already_ a large installed base of
critical resources that is not protected with CORS. Rule #1 of security
is that you don't introduce new functionality that's insecure unless the
entire rest of the world gets updated to handle it. It won't be
updated; certainly not in a timely manner.
again, agreed - hence why I'm suggesting that it's better to flip the
scenario order, allow unless denied, as the people who are in charge of
security of sensitive data should really be doing the studying for their
chosen career, not joe public who just wants to put up a few blog posts,
social profile etc on a shared host - how do you explain to joe that his
public profile isn't viewable in his public profile viewer unless he
changes some CORS headers on his shared host that he doesn't have access
to?
Sounds to me like the public profile viewer is broken (e.g. is using the
wrong tool to do the job). XHR is NOT the right tool for everything.
1) You could have the UA ask your server to perform the action
cross-site itself. No one's stopping you from doing that.
well noted - yet the whole point of making a purely client side
application
Hold on. Making purely client-side applications isn't exactly an
inviolable human right. There are lots of things that can't be done
purely on the client side... yet.
is so that it doesn't need a server and uses the web as a
distributed data tier.. not to mention http cache'ing and bandwidth
issues, it creates a silo, a bottleneck, adds in a layer where all a
users data in-out can be monitored and collected, more.. there are many
implications to this.
Sure. It's just the only way to make this work right this second.
2) You could use one of the APIs being proposed that do not send
user credentials and hence might well not require CORS, since
they will only be able to fetch public data (modulo the
firewall/routing issue, which will indeed need to be resolved).
? what's the point in CORS if it can be completely circumvented?
What would be circumvented? The point of CORS is that site A can't
pretend to be user U to site B and get information it couldn't get by
running wget on one of site A's own servers.
If a browser exposes an API to site A which does exactly what wget from
site A would do, then there's no reason to apply CORS: site A could
already get the data it's getting. The only difference is addressing
the issues you correctly note with site A proxying all the access
through its server.
No. The whole point here is that just because a user visits your site
doesn't mean that your script should be able to impersonate that user
when talking to other sites. That means either not allowing your
script to talk to other sites unless they explicitly say they're ready
for that sort of thing (current setup + CORS) or not allowing your
script to impersonate the user in the requests it sends.
granted, conflation over the current common setup, and the scope I'm
talking about which is using client side certificates over https,
restful and stateless - no impersonation can happen :)
That's not necessarily true. If you can send requests of your choosing
using the user's client certificate to sites of your choosing and read
the resulting responses... how is that not impersonation of the user?
-Boris
