I am writing a JavaScript application where I plan on host the code on a CDN. Now I plan to include this code to my clients' sites. However, I have a problem, I want to use AJAX to communicate between the client and the server. Now, from my understanding of XSS, this is not possible.
Ex:
User visits site.com, where a script tag's source is pointing to a file on cdn.somedomain.com
The script on cdn.somedomain.com fires an event.
This event will communicate with a PHP. I know it is possible for the script from cdn.somedomain.com to request documents on site.com. However, is it possible to send data back to a PHP file on cdn.somedomain.com?
Thanks for helping an entrepenuer! :D
The short is I think this is possible, but it depends on a couple of things. The same origin policy is a weird thing in that it won't allow cross domain reads, but will allow cross domain writes.
I think a way you could accomplish your goal is by making a GET request (minimally by creating an iframe, img, or whatever else that pulls a src) or possibly even using AJAX. If your goal is to only send data, then that should be fine. However, if you want to read this data back then I think that'll be a little less straight forward. I can't really answer that right now - especially without knowing more details about your system setup.
Sounds like a weird use of a cdn. Normally cdns serve static assets, so you wouldnt put a php file there. In fact the cdn wouldnt normally run dynamic server side code at all.
You can address the problem in several ways. Newer browsers support CORS and cross domain ajax. The cdn would then have to use the Access-control-* headers. You could also look at something like easyXDM, which works in older browsers.
Related
I would like to create a site with a similar functionality like translate.google.com or hypothes.is has: users can enter any address and the site opening with an additional menu. I gues this is done with some middleware-proxy solution and a javascript is injected in the response, but I'm not sure. Do you have any idea how to implement the same feature? How can it work with secured (https) sites?
Many Thanks
The entire site is fetched by the server, the source code is parsed, code injected and then sent back to the requesting client.
It works with SSL just fine, because it's two separate requests - the request that gets sent to the endpoint is not seen by the user.
The certificate is valid because it's being served under google's domain.
In order to actually implement something like this could potentially be quite complicated, because:
The HTML you are parsing won't necessarily conform to your expectations, or even be valid
The content you're forwarding to the client will likely reference resources with a relative URI. This means that you also need to intercept these requests and pull the resources (images, external css, js, etc) and serve them back to the client - and also rewrite the URLs.
It's very easy to break content by injecting arbitrary javascript. You need to be careful that your injected code is contained and won't interfere with any existing code on the site.
It's very common for an implementation such as this to have non-obvious security concerns, often resulting in XSS attacks being possible.
I need to send and load JSON data to and from a PHP script on a different domain and while the variables were passed, nothing is returned.
domain1.com/display.php (has Jquery $post() routine to send and load data) to
domain2.com/data.php (php script outputs JSON data) <-- this receives data, but response is not sent to requesting script.
Of course this is due to browser security restricting cross site scripting stuffs.
I've read a bit about JSONP but that's just another extra step.
I remember when I used to do FLASH, i would just uload a policy file to the server on a different domain where I would load data from and everything would just work.
Is there anything like that for JavaScript? if not, WHY the HECK not?! Seems to me like it's a legit, hassle free solution, that's just about as secure as JSONP method, or even more so.
Regards
Since you say "it's Javascript that needs to load the data", I gather this is running in some browser. In this case, the browser is enforcing security, as fas as I know, and fiddling with the server( script)s will not help.
Chrome has a command-line option to turn off XS security (--disable-web-security), and Firefox has a setting in about:config (I think, can't find it right now... sorry).
But I guess there's reason to these security settings in the first place... ;-)
Are you trying to load it on the client? Using PHP+cURL it should be no problem on the server side. If you really need to load cross domain content on the client side you could use the Cross Domain jQuery plugin (uses YQL internally)
I have a main header page that is included in many different applications across a couple of different languages, including Java and classic ASP. The file (file.js) is going to be obsolete soon. We are going to be going to an "out-of-the-box" solution, a new header created by another group. They gave us a link ("google.com") that we need to use to show this new header. I was wondering if there was a simple solution I could implement in my file.js that would show this content to the users. I know an easy way to do it in jsp is
<c:import url="http://google.com"/>
but this won't work in the js file, nor will it work in the jsp. Is there a way for me to do this?
Thank you,
Explosive_donut
Obviously the URL you are really given isn't Google. I suppose the second team is able to modify their own (document) headers sent to clients.
First way I think of is to use AJAX to retrieve the contents of the URL and create a div or select an existing to set its new content.
Unfortunately AJAX is restricted to the Same Origin Policy which can be circumvented with CORS (Cross Origin Resource Sharing). To allow CORS, your remote server as well as your client maschines need to send respective headers. Check out the link for more information.
If you need any more information and/or tutorials, let me know in the comments.
I realize this issue of cross site scripting has been covered, however being new to web development I had a few further questions.
Currently I am testing an html file I wrote on my PC connecting to a RESTFul web service on another machine. I am getting status=0. Is this considered cross-site scripting?
If a server hosts a file with javascript, and that javascript file has XMLHttpRequests to the server's own web services, will that work, or is that bad?
Apologies if any of these questions are stupid.
status=0 can me a variety of things, and without knowing more about how you got to that point, it is very difficult to determine what, exactly, it means. You could be using an iframe, the other computer could genuinely be telling you that the status is 0... we don't know.
The general rule is that it doesn't matter where the JS is from, it will execute the data where it's loaded. This is what makes the Google js archiving api possible (you know, use https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.js on a whole assortment of locations). And honestly, that is not a security issue.
The security issue comes in when a js file tries to access another domain (or even subdomain), whether through manipulation of an iframe or through XMLHTTPRequest. It's at that point that the browser will "lay the smackdown" on the script.
You will have difficulty communicating with JavaScript from your hard drive (file:///) to any internet protocol (http|https) because of this.
No, that is not cross site scripting. When including script JS file from another server it is rendered in your site so You won't be able to access through XMLHttpRequest site where JS script is originally located.
If that is possible than anybody who host jQuery file, there are many servers including google, would be opened for XMLHttpRequests.
SO, IT'S NOT POSSIBLE.
If you want JSON response from another server you can use pjson. Google it for more info.
And Cross Site Scripting is when someone injects JavaScript code on your site in order to bypass access control.
You can use CORS for that. You can use the same code you use now, but the other server you request the page from via ajax has to sent the following header on that page
Access-Control-Allow-Origin: http://yoursite.example.com
#or to allow all hosts
Access-Control-Allow-Origin: *
I have seen server side proxy workarounds for retrieving rss (xmls) from cross-domains. In fact this very question addressess my same problem but gives out a different solution.
I have a constraint of do not use a proxy to retrieve rss feeds. And hence the Google AJAX Feed API solution also goes out of picture. Is there a client-only workaround for this problem.
JSONP is the solution for requests that respond with JSON output. But here, I have RSS feeds which can respond with pure xml .
How do I solve the problem.
Use something like Yahoo! Pipes to serve as your proxy and translate the RSS XML into a JSON response.
Here is an article with instructions and code samples that explains how to do it: Yahoo Pipes--RSS without Server Side Scripts.
If you have control over both domains, you can try a cross-domain scripting library like EasyXDM, which wraps cross-browser quirks and provides an easy-to-use API for communicating in client script between different domains using the best available mechanism for that browser (e.g. postMessage if available, other mechanisms if not).
Caveat: you need to have control over both domains in order to make it work (where "control" means you can place static files on both of them). But you don't need any server-side code changes.
Another Caveat: there are security implications here-- make sure you trust the other domain's script!
Right now there really isn't a cross-platform solution for cross-site scripting. Do you have control or access to the RSS feeds? If so, why not simply respond with JSON and use JSONP?
There are other things coming down the pike with HTML5, like cross-site messaging (referred to as Cross-Document Messaging) that may be capable of delivering a payload of XML, but last time I checked, they hadn't even fully decided on a size limit for the messaging.
You can see the spec here: http://dev.w3.org/html5/spec/Overview.html#crossDocumentMessages
A solution for cross-domain calls without a server-side proxy is to use a SWF component.
You can script yourself one or use the readily available FLSend
The component uses ActionScript's URLRequest to call remote domains and ExternalInterface to communicate with the JavaScript methods that render your content.
The only way I can think of would be to embed a signed java applet on the webpage to retrive the xml and use javascript to interface with that. I'm not even 100% certain what the java security model is for that at present though but I think it would work.