cross-site data retrieval
Jason S
methods for cross-site data retrieval via AJAX.
Use case:
Website A offers a web service (like the Flickr API, perhaps)
I am working on Website B. I wish to use Website A's web service via
an AJAX call. All I want to do is issue a GET call for some data. It's
just data that I use in a way I see fit. Not a script. I don't need
any cookies to be sent.
Website A does not know about website B.
I've looked at COWS, Cross-site XMLHTTPRequest, and a few other things
and they all seem to require cooperation from the 3rd-party site using
the new "Access-Control:" headers or something to explicitly grant
permission to other websites.
Is there a way to accomplish this:
(a) in the majority of browsers
(b) with Firefox only?
Also what is the security risk? I understand why if B's cookies were
transmitted to A then that would be a security risk. But otherwise, if
I am handling the data from site A in a safe matter (e.g. not
executing it as a script!), what is the risk?
Maybe one of you could point me to a good overview of the topic.
Jonas Sicking
Anything that a browser does (apart from accidental security bugs) is
going to either require that website A explicitly cooperates to share
its data, or require that the user explicitly says that website B may
load data from website A.
Anything else would be a security bug.
The reason is that website A might be behind a corporate firewall. And
so if website B could read this data, corporate firewalls would not work
if a user inside the firewall browsed sites outside the firewall.
The following solutions exist, but all require either explicit
cooperation from site A, or require user intervention:
* Write an extension or plugin that exposes functionality to site B that
allows data to be loaded from site A.
It is currently not possible to write a cross-browser extension. But
you can write a cross browser plugin (although IE uses a IE-only
plugin API).
Requires cooperation from user.
* Use postMessage:
https://developer.mozilla.org/En/DOM:window.postMessage
postMessage exists in FF3 and IE8. I think opera and safari have
releases that support it in the works.
Requires cooperation from site A.
* Use JSON and cross site <script>
Has security issues since you must trust site A not to XSS you.
Requires cooperation from site A.
* Use location.hash hacks.
Works in all browsers but is very cumbersome. Might break in future
releases.
Requires cooperation from site A.
* Use Cross-site XMLHttpRequest
Works in FF3.1 betas. Latest IE8 beta as very very limited support
using XDR. I think next safari will support it. I think opera is
working on it as well.
There is also signed scripts. But it requires user cooperation, is
firefox-only, and is likely to not work in future firefox releases.
/ Jonas
Jason S
> Anything else would be a security bug.
>
> The reason is that website A might be behind a corporate firewall. And
> so if website B could read this data, corporate firewalls would not work
> if a user inside the firewall browsed sites outside the firewall.
gack, that makes sense. (unfortunately.) So this is a firewall in the
broadest sense? e.g. firewall F exists around computers within the
domains paranoid-company.com and other-paranoid-company.com? Otherwise
it seems like if websites A and B are not within the local domain
(e.g. both outside the firewall) then there's not a security risk.
Technically I don't need website B to read the data, I just want the
client-side script for the end-user to read that data... although I
suppose if you allow website B to be arbitrary (e.g. "evil") then I
suppose the script could send data to website B.
The other option you haven't mentioned, which I can do, is to have
website B's server contact website A to issue a proxy. I can do that,
the only reasons I haven't are because then my server has to carry the
bandwidth & it adds latency; i'd prefer it if the client computer
could get the data directly.
Jonas Sicking
> On Oct 30, 6:14 pm, Jonas Sicking <jo...@sicking.cc> wrote:
>> Anything else would be a security bug.
>>
>> The reason is that website A might be behind a corporate firewall. And
>> so if website B could read this data, corporate firewalls would not work
>> if a user inside the firewall browsed sites outside the firewall.
>
> gack, that makes sense. (unfortunately.) So this is a firewall in the
> broadest sense? e.g. firewall F exists around computers within the
> domains paranoid-company.com and other-paranoid-company.com? Otherwise
> it seems like if websites A and B are not within the local domain
> (e.g. both outside the firewall) then there's not a security risk.
If both servers exist within the same firewall, or both outside all
firewalls, then there is no security risk no.
> Technically I don't need website B to read the data, I just want the
> client-side script for the end-user to read that data... although I
> suppose if you allow website B to be arbitrary (e.g. "evil") then I
> suppose the script could send data to website B.
Yes, once a webpage has information there are tons of ways it can
communicate that back to its home server, there is no way to prevent
that other than pulling the network plug.
> The other option you haven't mentioned, which I can do, is to have
> website B's server contact website A to issue a proxy.
Yup
> I can do that,
> the only reasons I haven't are because then my server has to carry the
> bandwidth & it adds latency; i'd prefer it if the client computer
> could get the data directly.
Yup. This is why we've added technologies such as cross-site
XMLHttpRequest and postMessage. It only works if both sites cooperate
though.
/ Jonasa