[whatwg] Lifting cross-origin XMLHttpRequest restrictions?
brettz9 at yahoo.com
Sat Mar 13 17:45:26 PST 2010
On 3/12/2010 3:41 PM, Anne van Kesteren wrote:
> On Fri, 12 Mar 2010 08:35:48 +0100, Brett Zamir <brettz9 at yahoo.com>
>> My apologies if this has been covered before, or if my asking this is
>> a bit dense, but I don't understand why there are restrictions on
>> obtaining data via XMLHttpRequest from other domains, if the request
>> could be sandboxed to avoid passing along sensitive user data like
>> cookies (or if the user could be asked for permission, as when
>> installing browser extensions that offer similar privileges).
> Did you see
I have now, thanks. :) Though I regrettably don't have a lot of time
now to study it as deeply as I'd like (nor Michal Zalewski's reference
to UMP), and I can't speak to the technical challenges of browsers (and
their plug-ins) implementing the type of sandboxing that would be
necessary for this if they don't already, I was just hoping I could
articulate interest in finding a way to overcome if possible, and
question whether the security challenges could be worked around at least
in a subset of cases.
While I can appreciate such goals as trying "to prevent
dictionary-based, distributed, brute-force attacks that try to get login
accounts to 3^rd party servers" mentioned in the CORS spec and
preventing spam or opening accounts on behalf of users and the like, I
would think that at least GET/HEAD/OPTIONS requests should not be quite
as important an issue.
As far as the issue Michal brought up about the client's IP being sent,
I might think this problem could be mitigated by a client header being
added to indicate the domain of origin behind the request. It's hard to
lay the blame on the client for a DoS if it is known which server was
initiating. (Maybe this raises some privacy issues, as the system would
make known who was visiting the initiating site, but I'd think A) this
info could be forged anyways, and B) any site could publish its visitors
anyways.) I'll admit this might make things more interesting legally
though, e.g., whether the client shared some or all responsibility, for
DoS or copyright violations, especially if interface interaction
controlled the number of requests. But as far the burden on the user, if
the user is annoyed that their browser is being slowed as a result of
requests made on their behalf (though I'm not sure how much work it
would save given that the server still has to maintain a connection),
they can close the tab/window, or maybe the browser could offer to
selectively disable such requests or request permission.
I would think that the ability for clients to help a server crawl the
internet might even potentially be a feature rather than a bug, allowing
a different kind of proxy opportunity for server hosts which are in
countries with blocked access. Besides this kind of "reverse proxy" (to
alter the phrase), I wouldn't think it would be that compelling for
sites to outsource their crawling (except maybe as a very insecure and
unpredictably accessible backup or caching service!), since they'd have
to retrieve the information anyways, but again I can't see what harm
there would really be in it, except that addressing DoS plans would need
to address an additional header.
I apologize for not being able to research this more carefully, but I
was just hoping to see if there might be some way to allow at least a
safer subset of requests like GET and HEAD by default. Akin to the
rationales behind my proposal for browser support of client-side XQuery,
including as a content type (at
http://brett-zamir.me/webmets/index.php?title=DrumbeatDescription ), it
seems to me that users could really benefit from such capacity in
options, but also for encouraging greater experimentation of mash-ups,
as the mash-up server is not taxed with having to obtain the data
sources (nor tempted to store stale copies of the source data nor
perhaps be as concerned with the need to obtain republishing permissions).
>> Servers are already free to obtain and mix in content from other
> Because you would also have access to e.g. IP-authenticated servers.
As suggested above, could a header be required on compliant browsers to
send a header along with their request indicating the originating
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg