最佳实践：合法的跨站点脚本

Question

While cross-site scripting is generally regarded as negative, I've run into several situations where it's necessary.

I was recently working within the confines of a very limiting content management system. I needed to include database code within the page, but the hosting server didn't have anything usable available. I set up a couple bare-bones scripts on my own server, originally thinking that I could use AJAX to import the contents of my scripts directly into the template of the CMS (thus retaining dynamic images, menu items, CSS, etc.). I was wrong.

Due to the limitations of XMLHttpRequest objects, it's not possible to grab content from a different domain. So I thought iFrame - even though I'm not a fan of frames, I thought that I could create a frame that matched the width and height of the content so that it would appear native. Again, I was blocked by cross-site scripting "protections." While I could indeed load a remote file into the iFrame , I couldn't execute JavaScript to modify its size on either the host page or inside the loaded page.

In this particular scenario, I wasn't able to point a subdomain to my server. I also couldn't create a script on the CMS server that could proxy content from my server, so my last thought was to use a remote JavaScript.

A remote JavaScript works. It breaks when the user has JavaScript disabled, which is a downside; but it works. The "problem" I was having with using a remote JavaScript was that I had to use the JS function document.write() to output any content. Any output that isn't JS causes script errors. In addition to using document.write() for every line, you also have to ensure that the content is escaped - or else you end up with more script errors.

My solution was as follows:

My script received a GET parameter ("page") and then looked for the file ( {$page}.php ), and read the contents into a variable. However, I had to use awkward buffering techniques in order to actually execute the included scripts (for things like database interaction) then strip the final content of all line break characters ( \\n ) followed by escaping all required characters. The end result is that my original script (which outputs JavaScript) accesses seemingly "standard" scripts on my server and converts their standard output to JavaScript for displaying within the CMS template.

While this solution works, it seems like there may be a better way to accomplish the same thing. What is the best way to make cross-site scripting work specifically for the purpose of including content from a completely different domain?

Answer 1

You've got three choices:

1. Create a server side proxy script .

2. Create a remote script to read in remote dynamic HTML. Use a library like jQuery to make this easier. You can use the load function to inject HTML where needed. EDIT What I originally meant for example # 2 was utilizing JSONP , which requires the server side script to recognize the "callback=?" param.

3. Use a client side Flash proxy and setup a crossdomain.xml file on your server's web root.

Answer 2

Personally, I would call to that other domain on the server and get and parse the data there for use in your page. That way you avoid any problems and you get the power of a server-side language/platform for getting and parsing the data.

Not sure if that would work for your specific scenario...hard to know even with your verbose description...

Answer 3

您可以尝试使用easyXDM ，通过包含非常少的代码，您可以在不同域的文档之间传递数据或方法调用。

Answer 4

iframe remote content can be accessed by local javascript.

The remote server just have to set the document.domain of the page.

Eg:

Site A contain an iframe with src='Site B/home.php'

home.php looks like this :

[php stuff]...[/php]
[script type='text/javascript']document.domain='Site A'[/script]

Answer 5

I've come across that YDN server side proxy script before. It says it's built to work with Yahoo's Search APIs.

Will it work with any domain, if you simply trim the Yahoo API code out? Or do you need to replace it with the domain you want it to work with?