I am learning about he Prototype Ajax API. I was reading their documentation and I saw this:
Remember that for security reasons (that is preventing cross-site
scripting attacks) Ajax requests can only be made to URLs of the same
protocol, host and port of the page containing the Ajax request. Some
browsers might allow arbitrary URLs, but you shouldn't rely on support
for this.
So does this mean that I can't make requests to a backend of one app from another of my apps? Or am I just misunderstanding this. I would really appreciate some clarification for a new javascript learner, like me. Thanks
This is the same domain origin policy. This is enforced by web browsers, for security reasons.
In short, without this restrictions, ajax requests would allow you to retrieve any web page on the behalf of the user. This would allow you to read his emails if he was logged-in on his webmail.
Take a look at JSONP, for doing cross-domain ajax requests. (Notice the P in JSONP.)
This seems to be adding JSONP support to Prototype: http://dandean.com/jsonp-for-prototypejs/
Related
I'm struggling at the moment with the idea of creating a cross-origin request proxy or not.
I have a jQuery application that interacts with an API, making at least 4 requests to that server on the initial page load. Both servers are completely under my control, but they are on different subdomains. For that reason, I've been heading toward the approach of using JSONP to get around the cross-origin request policies.
However, I'm really missing out on one feature in particular: getting HTTP status codes for the requests. The way JSONP + jQuery work, the request works or it doesn't. If it doesn't, I specify a timeout for the request and if that timeout is reached I assume a failure (there's no way to know otherwise). I'd really like to be able to respond to a 404 vs a 500 error from the API server.
This led me to thinking a local proxy may work better - but it would then tie up server-side resources (server that holds the jQuery application + Sinatra application) instead of client resources (the browser). That can certainly add up when each page load is 4+ requests to the API server, even though it wouldn't block the application from loading.
I understand this is not a true "question" - so feel free to flag this / close it if inappropriate. However, I'd really like to get some opinions on the subject. I'm introducing some complexity by developing a local proxy in Ruby.
I'd stick to JSONP and the direct communication between the subdomains.
Also, you might want to check out (hacky) methods of using iframes for communication. Iframes are not subject to the inter-subdomain restriction. They can communicate as long as both subdomains belong to the same top domain.
JSONP has some limitations and is not your only option. Since you control both domains have you considered using CORS? If not, check it out: http://www.html5rocks.com/en/tutorials/cors/
You can read about JSON-P vs. CORS here: http://json-p.org/
I don't see how the callback function in JSONP is any different from the success callback function in AJAX.
Given #1, I don't see how it is fundamentally more secure.
So is the only difference an artificial same-domain constraint with AJAX?
Why can't AJAX just allow cross-domain requests; if this can cause a security hole, wouldn't the attack just XSS a JSONP request?
Confused,
Max
An ajax call is an actual HTTP request from your client directly to a server. Ajax calls can be synchronous (blocking until they complete) or asynchronous. Because of same-origin security protections, ajax calls can only be made to the same server that the web page came from unless the target server explicitly allows a cross origin request using CORS.
JSONP calls are an interesting hack with the <script> tag that allows cross-origin communication. In a JSONP call, the client creates a script tag and puts a URL on it with an callback=xxxx query parameter on it. That script request (via the script tag insertion) is sent by the browser to the foreign server. The browser just thinks it's requesting some javascript code. The server then creates some special javascript for the purposes of this call and in that javascript that will get executed by the browser when it's returned, the server puts a function call to the function named in the callback=xxxx query parameter. By either defining variables of by passing data to that function, the server can communicate data back to the client. For JSONP, both client and server must cooperate on how the JSONP call works and how the data is defined. A client cannot make a JSONP call to a server that doesn't explicitly support JSONP because the exact right type of JSONP response has to be built by the server or it won't work.
So, the two communication methods work completely differently. Only ajax calls can be synchronous. By the nature of the <script> tag insertion, JSONP calls are always asynchronous.
In an Ajax call, the response comes back in a ajax event handler.
In a JSONP call, the response comes when the returned Javascript calls a function of yours.
In some ways, JSONP is a security hole that bypasses the cross-origin security mechanism. But, you can only call servers that explicitly choose to support a JSONP-like mechanism so if a server doesn't want you to be able to call it cross-origin, it can prevent it by not supporting JSONP. You can't make regular ajax calls to these other servers.
The browser makers can't really close this loophole because if they did zillions of web pages would break that either already use JSONP or load scripts from other domains. For example, every page on the web that uses jQuery off the Google or Microsoft CDNs would break because the browser wouldn't be allowed to download javascript from cross-origin domains.
JSONP was largely invented as a work-around to be able to make cross-origin requests. But, since JSONP requires explicit server support in order to work, it wasn't really a security problem because a JSONP call can only be made to a server that explicitly decided to allow that type of cross origin call. JSONP is used much less now than it used to be because CORS was invented as a more elegant way to control/allow this. CORS stands for Cross Origin Resource Sharing and it provides a means for a target server to tell a web browser exactly what type of cross origin requests are allowed and even to tell it which web page domains are allowed to make such requests. It is has much finer control available than JSONP and all modern browsers now support CORS.
Here's an example of how a cross-origin call causes problems. If you could load any arbitrary web page from any other web page or make any arbitrary ajax call, then imagine you were already logged into your webmail interface on Yahoo in so some other browser window. This means that your cookies are set to allow requests from your browser to fetch data from Yahoo. If the javascript in some other web page was allowed to make a webmail request to Yahoo (that would automatically have your cookies attached), it could then fetch all your webmail data and send it back to it's own site. One web site could rip off all the logged-in data from any other web site. All web security would be broken.
But, the way we have it today, as long as Yahoo doesn't support a JSONP interface that uses those same web cookies, it is safe from unauthorized JSONP requests.
Here are some other good writeups on the dangers of cross-origin ajax and why it has to be prevented:
Why the cross-domain Ajax is a security concern?
Why Cross-Domain AJAX call is not allowed?
Why are cross-domain AJAX requests labelled as a "security risk"?
JSONP's callback is not an actual callback. Rather, JSONP works by script injection. E.g., if you want to make a JSONP call, you insert this script element into the DOM:
<script src="http://example.com/ajaxendpoint?jsonp=parseResponse"></script>
The server's response will be something like this:
parseResponse({"json":"value"});
It will be evaluated in the window's global scope. So essentially JSONP is like a remote exec(), where the server is advised what string to create to execute.
This is very different from Ajax: with JSONP, the response is evaluated in the script's global scope; with XMLHttpRequest, the response is received as a string and not evaluated.
(Also, JSONP can only be used with GET, whereas AJAX allows any http method.)
Thus to your second issue, "I don't see how it is fundamentally more secure." Well, you are right, JSONP is actually extremely insecure. The server can return any script it wants, and do anything it wants to your browser!
Cross-domain requests are insecure because they can be used to reveal information about the current page to a page on another domain.
And you are right that any XSS attack can just use JSONP. The purpose of CORS is not to prevent XSS (if you have untrusted scripts running on your page you are hosed anyway).
The fundamental difference is that, for some reason, it's perfectly fine to load javascript files located on other domains (via script tag), but it is not OK by default to load other cross domain resources.
I'm with you, in that the delineation seems rather arbitrary. In jQuery, when you do a JSONP call, effectively you are creating a script tag, loading the resource, and then the jQuery library executes your script by calling the function defined in that JSONP result.
In my eyes, I cannot think of an additional vector of attack introduced by allowing cross domain AJAX which is not already gaping wide by allowing cross domain script loading, which is a common practice used everywhere (jQuery by googleCDN, advertising scripts, google analytics, and countless others).
From wikipedia
In addition, many legacy cross-domain operations predating JavaScript are not subjected to same-origin checks; one such example is the ability to include scripts across domains, or submit POST forms.
I am writing an app right now that uses jQuery and JSONP to get JSON from 3rd party servers. The main idea behind my app is that it is a Front End with only GUI logic and 3rd party servers can be written by anyone to use the Front End.
I have no idea what security issues could arise from this but I definitely see it as a potential issue. What are some steps I can take to make sure that a 3rd party server doesn't completely crash my site that will be running the GUI?
JSONP means that you execute third-party javascript which should return a Javascript object. The script you load with JSONP can do anything a local script could, thus it is an XSS attack vector in two ways: either if the third party you request the JSONP data from is evil, or if the data is changed with a man-in-the-middle attack.
The second type of attack can be avoided by only doing JSONP over secure connections (or can be disregarded if your own page is sent over an insecure connection, in which case there are easier ways to do a man-in-the-middle attack); the first type is inherent to JSONP and cannot be avoided. You should only use JSONP when you trust the source. Otherwise, you can either set up an AJAX gateway on your own server and request JSON data through that (this will only work if the JSONP service does not require authentication), or use cross-domain AJAX requests (which do not work in older browsers, and require certain permissions from the JSONP server).
If the third-parties aren't trustworthy, you have a large problem here. Instead of sending JSONP code, they could send any JavaScript they want, potentially damaging your site or stealing users' information.
JSONP works by just including the remote data on your page with <script> tags. It is designed to avoid the browser's security restrictions, and so should only be used with trustworthy sources.
A client-side only solution to this problem does not exist.
EDIT: Oh, I misread your question. I thought the client was going to be receiving the JSON.
JSONP is just a JSON object wrapped in a javascript function call. Normally if you were operating from a server you would just request the unwrapped JSON object itself, but even with the JSONP object it's difficult to hurt yourself unless you are running eval() on it.
Are you using an existing JSON library? If so, you should be fine.
Are you parsing it yourself? If so, avoid eval and you should be fine.
Well, JSON describes an object, not an executable function. What JSONP is doing is rendering that result of a GET request as a function on your client and executing it. This would suggest that the biggest security concern you would consider is what your code is doing with the data.
Since it is straightforward to use JSONP in a script tag to fetch data from a different domain, shouldn't we allow XMLHttpRequest to do it as well? It doesn't make much sense to claim it strengthens security when it's possible to work around it, albeit with more messy semantics.
JSONP only works if the provider allows for it.
If cross domain AJAX worked, one of the first problems would be people posting to other domains in the hope you have an authenticated account there. This is CSRF.
They could GET a page authenticated as you, take your token, and then POST something malicious with your token (which tells the application this is an internal request).
Actually JSOP is a clever workaround for the limitations of the same origin policy but what it is is basically a self-inflicted cross-side scripting attack (remember that JSONP warks by using script tags instead of XHR so you give total control over your entire page to your JSONP data provider - usually they're not evil but sometimes they're incompetent so keep that in mind).
There is a lot of discussions on how to fix the same origin policy in new versions of ECMAScript because clearly it doesn't work if it has to be circumvented to make any kind of mashups. An interesting idea in my opinion is having a cheaper version of XHR that would send no cookies or useless headers and so would be able to prevent cross-site request forgery attacks but still allowing safe mashups without giving the data provider total access to your page. But we still have to wait for it.
Is it possible to do a cross-site call, in Javascript, to a WCF service?
I don't mind if it's a POST or a GET.
But I've heard that these days, browsers don't allow cross-site calls with either POST or GET.
How can I circumvent this and still call a WCF Service?
There's not a whole lot you can do to circumvent the browser's cross-site scripting blockers. Those blockers stop XMLHTTPRequest's from happening to any domain but the one that loaded the containing script or page.
That said, there is one commonly used workaround: Use JavaScript to write a new entry into the DOM that references a src that is a cross-site URL. You'll pass all your RPC method arguments to this "script" which will return some JavaScript that will be executed, telling you success or failure.
There's no way to do a POST in this manner, the src URL must be a GET, so you can pass arguments that way. I'm not sure if WCF has a "GET only" method of access. And, since the browser will expect the result of the remote tag to be a valid JavaScript object, you'll have to make sure that your WCF service obeys that as well, otherwise you'll get JavaScript errors.
Another common method of circumventing cross-site scripting is to write a proxy for your requests. In other words, if you want to access domain test.com from scripts hosted on example.com, then make some URL on example.com that proxies the request over to test.com in the proper way.
For your example, the proxying is likely the right answer, assuming that WCF doesn't have it's own cross-site scripting restrictions.
Are you using jQuery by any chance? jQuery supports Cross-Domain JSON requests using "JSONP". You will be limited to GET requests, but I've tried it out and it works well! It's also very simple to get working.
See the "Cross-Domain getJSON (using JSONP) " section on this page for details:
http://docs.jquery.com/Release:jQuery_1.2/Ajax
And here's some background on JSONP:
http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/
Let me know how it goes!
New W3C recommendations are being standardised to allow cross-site requests between trusted parties via the Access Control for Cross-Site Requests specification.
This requires a server serving suitable Access Control HTTP headers and a browser capable of understanding and acting upon such headers.
In short, if a remote host says it likes your domain, and a browser understands what this means, you can perform xmlHttpRequests against that host regardless of the same origin policy.
Currently very few browsers support this functionality. IE8 apparently does (I haven't tested it) and Firefox 3.1 does (I have tested this extensively). I expect other browsers to follow suit quite quickly.
You shouldn't expect sufficient adoption of compatible browsers until 2012 at the earliest.
That's the ultimate solution to the problem. The downside is waiting a few years before it can be used in mainstream applications.
If this is for use within an environment you fully control, such as for an intranet where you can determine which browser is used and where you can configure multiple servers to issue the correct headers, it works perfectly.
To expand on Ben's answer... I extended our WCF service to support JSONP calls from jQuery using code similar to this example from Microsoft:
http://msdn.microsoft.com/en-us/library/cc716898.aspx