Problem:
A part of a web application contains another web application from another domain.
Both web applications make AJAX requests to the domains they originated from which poses problems because of the same origin policy for AJAX requests.
Solution:
One way to achieve this is to wrap the contained web application in an iFrame. The AJAX requests in it go to the the same domain of the iFrame - which is different from the parent application.
This sounds fine to me, but since iFrames ae unfashionable, what other / better way is there to do this?
Are you not able to have both applications send an AJAX request to your domain, and have your server side perform the call to a foreign domain, and then relay the result it receives back to the requesting client side App. Your server in essence becomes a proxy for the AJAX request?
What do you men unfashionable? If you like to hind you can apply height to 0 and display none.
Related
I'm new to JS and AJAX, and one day, I tried a cross-domain AJAX request. After some researchs, I found out that AJAX could not work over cross domains (natively) because it is unsecure.
From Wikipedia: " This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page's Document Object Model. "
But how could an AJAX request access to "sensitive data", while you can't with default HTTP?
An AJAX request is an HTTP request.
AJAX stands for Asyncronous Javascript And XML. It's kind of named that, after the first browser-based javascript HTTP client API, XMLHttpRequest.
HTTP requests are not inherently insecure, but certain things might make HTTP requests problematic.
A big one related to 'Ajax' requests is that, in the past at least, a HTTP request can carry session/cookie information.
This means that if Ajax requests were not restricted in browser sandboxes (cross-domain), it could mean that the owner of Site A, could make a request to Site B on behalf of a user.
Example: You're logged into a popular social network. Your browser uses a cookie to identify your logged in session. I send you a link to evil.example.org. If cross-site restrictions didn't exist, I could now make a HTTP for you + your session to the social network and act on your behalf.
However, this is not the end of this story. It is possible to do cross-site requests. This is called a CORS requests.
BUT: the way this works is that the owner of the site that you want to make a request to, has to allow in. In our previous example that means that the social network needs to explicitly allow "evil.example.org" to make these kind of requests.
The way this site gives you permission is via CORS headers.
Other ways to work around it is via:
Frames that are hosted on the site you're trying to access. (with specific code)
A proxy you control.
If the server you're trying to access delivers its content in a very specific way. (again, you need control of the target server).
If you control the target server, your best options is to just use CORS though. If you don't your best bet is to setup a proxy you control.
So I have run into a problem. I am building a javacript file, which appends an iframe into clients page (within a div). Lets say, this iframe is loaded from http://example.com/iframe. iframe's backend module (to handle form submission; written in spring) has some endpoints like http://example.com/url1, http://example.com/url2
Now, I want only the iframe to be able to communicate with backend APIs. Currently, I can hit the iframe backend APIs from localmachine too.
I have come across the referer HTTP field, and initially was planning to set a referer filter on the APIs, but later found out that this can easily be spoofed. Will I get any benifit sertting CORS header on the APIs and setting the origin as http://example.com? Will it work, and if yes, is this a safe and dependable solution? Are there any better alternatives?
I'm working on a Facebook Canvas App, and which by definition loads the code/webpage for my app in an iFrame on the Facebook website.
During development I have got the impression that if I make an AJAX request from my App's webpage to a webservice for my app which is on exactly the same server/domain name as the webpage, that that is actually technically a cross domain request - because the page originally loaded in the (top) frame of the browser is on a different domain to my webservice.
However I now believe that, due perhaps to a bug in my code, I was mistaken, and a page in an iFrame can make requests to URLs on the same domain as it without being a cross domain requests.
Clarifying this is particularly important to me as I now believe I can actually use POST requests instead of having to use JSONP GET requests.
If someone could clarify this for me I would greatly appreciate it. I have search around and cannot find a clear statement on this scenario.
EDIT: To provide more clarification: my Facebook App page URL at https://apps.facebook.com/myapp/ loads my webpage at www.mydomain.com in an iFrame. The webpage at www.mydomain.com then makes an AJAX request to a webservice on www.mydomain.com (at eg. www.mydomain.com/webservice/). So is the request from my webpage to my webservice a Cross Domain request or not?
Cheers
Matt
Your document loaded within the iframe is still a document of it’s own, and behaves like any other document, whether it be displayed in a frame or not, when it comes to the same origin policy.
So yes, you can absolutely make AJAX requests to the domain that your document got delivered from, not matter that it is displayed inside an iframe on Facebook.com.
There is no crossing of domain boundaries involved.
Given all the coverage FireSheep has been getting, I have been trying to work out the best practices for balancing HTTP / HTTPS usage for some sites I manage (e.g. blogging sites, magazine sites with user contributed comments).
To me, its over kill to deliver all pages over HTTPS if the user is logged in. If a page is public (e.g. a blog) there is little point encrypting the public page. All I want to do is prevent session hijacking by sniffing cookies over HTTP channels.
So, one plan is:
Login form is over HTTPS
Issue two cookies: One cookie is 'public' and identifies there user for read only aspects (e.g. 'welcome bob!'). The second cookie is private and 'HTTPS only'. This is the cookie that is verified whenever the user makes a change (e.g. adds a comment, deletes a post).
This means that all 'changing' requests must be issued over HTTPS.
We use a lot of AJAX. Indeed, many comment forms use AJAX to post the content.
Obviously, I cant use AJAX directly to post content to a HTTPS backend from a HTTP frontend.
My question is: Can I use script injection (I think this is commonly called 'JSONP'?) to access the API? So in this case there would be a HTTP public page that sends data to the private backend by injecting a script accessed via HTTPS (so that the private cookie is visible in the request).
Can you have HTTPS content inside a HTTP page? I know you get warnings the other way around, but I figure that HTTPS inside HTTP is not a security breach.
Would that work? It seems to work in chrome and FF, but its IE that would be the party pooper!
Another way is to have an iframe which points to a https page that can make all kinds (GET, POST, PUT etc) of Ajax calls to the server over https (same domain as iframe is on https too). Once the response is back inside the iframe, you can post a message back to the main window using HTML5 postMessage API.
Pseudo code:
<iframe src="https://<hostname>/sslProxy">
sslProxy:
MakeAjaxyCall('GET', 'https://<hostname>/endpoint', function (response) {
top.postMessage(response, domain);
});
This works in all modern browsers except IE <= 7 for which you'll have to either resort to JSONP or cross domain communication using Flash.
The problem with JSONP is that you can only use it for GETs.
Can you have HTTPS content inside a
HTTP page? I know you get warnings the
other way around, but I figure that
HTTPS inside HTTP is not a security
breach.breach.
Including HTTPS content inside a regular HTTP page won't raise any alerts in any browser.
However, I don't think JSONP will help you out of this one. Using GETs to post content and modify data is a very bad idea, and prone to other attacks like CSFR
Is it possible to directly access third party web services using Ajax? Mostly I've seen that the website I'm visiting handles it on its server and then transfers the processed/unprocessed data to client browser. Is this always the case?
(yes, almost always)
Typically, when you're trying to accomplish accessing third party web services a proxy server is used to access those services. You can't reach external third party web services because they exist on separate domains and you run into the "Same Origin Policy"
Now.... there are methods for doing cross-domain ajax, but the service you are accessing must support it (there are restrictions on what kinds of data can be returned and how the requests are formatted due to the way cross domain ajax works)
A simple way to do this is indeed by using some sort of server-side proxy for your request. It works like this. You do the Ajax request to your own domain, lets say proxy.php. proxy.php handles your request, forwards it to the 3rd party service and returns te results. This way you don't get the cross-domain errors. You can find multiple examples of these simple proxy's by using the magic Google.