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?
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.
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.
I have recently been experimenting with building a cross domain web api, and wow has it been a bumpy journey. I have not had any problems with modern browsers such as Chrome, FF and Safari. The problem is with IE, which requires you to use XDR as opposed $.ajax when making cross domain calls. First Question: If I was using Backbone.js, what is the recommended way of making cross browser and cross domain ajax calls?
Another problem I had with IE was that when you make cross domain ajax requests, IE has a bunch of restrictions and limitations such as "Only text/plain is supported for the request's Content-Type header" - a link. Therefore in my case, I was unable to bind to my model using the MVC C# framework, unless I bind it manually.
Anyway my second and last question is: How do companies like Instagram, Facebook, and Twitter go about building their API's? I am not looking for a complete guide, but just want to know how difficult it is.
JSONP
The current standard is using JSONP. It is basically a trick to send a JSON payload wrapped in a single JavaScript function, the browser treats it like a script file and executes it.
CORS
Moving forward the way to go is CORS. Sadly browser support (IE) isn't there yet and there are still some implementation differences between the modern browsers that do implement it.
HTTP Method Overloading
Some APIs overload GET and POST request using X-HTTP-Method-Override: PUT or ?_method=PUT.
easyXDM
A number of API providers implement easyXDM. This tends to be used more when they provide a JavaScript API or widget API where developers load their JS and integrate it directly in to the frontend code.
I've created a RESTful API that supports GET/POST/PUT/DELETE requests. Now I want my API to have a Javascript client library, and I thought to use JSONP to bypass the cross-domain policy. That works, but of course only for GET requests.
So I started thinking how to implement such a thing and at the same time trying to make it painless to use.
I thought to edit my API implementation and check every HTTP request. If it's a JSONP requests (it has a "callback" parameter in the querystring) I force every API method to be executed by a GET request, even if it should be called by other methods like POST or DELETE.
This is not a RESTful approach to the problem, but it works. What do you think?
Maybe another solution could be to dynamically generate an IFrame to send non-GET requests. Any tips?
There's some relevant points on a pretty similar question here...
JSONP Implications with true REST
The cross-domain restrictions are there for a reason ;-)
Jsonp allows you to expose a limited, safe, read-only view of the API to cross domain access - if you subvert that then you're potentially opening up a huge security hole - malicious websites can make destructive calls to your API simply by including an image with an href pointing to the right part of the API
Having your webapp expose certain functionality accessed through iframes, where all the ajax occurs within the context of your webapp's domain is definitely the safer choice. Even then you still need to take CSRF into consideration. (Take a look at Django's latest security announcement on the Django blog for a prime example - as of a release this week all javascript calls to a Django webapp must be CSRF validated by default)
The Iframe hack is not working anymore on recent browsers, do not use it anymore (source : http://jquery-howto.blogspot.de/2013/09/jquery-cross-domain-ajax-request.html)
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