seven ways for cross domain script programming

I was interested in making a conclusion about how to make XSS (cross site script)application. But, this is not an article about how to write javascript code to do XSS code hack. I just want to make an conclusion on this to show possible techniques used by ASP, who wants to integrate all of its existing web application into one portal. Maybe, I should call it as Cross Domain Script instead of Cross Site Script as XSS make me think it is a technique to insert malicious script into Web page.

As far as I know, there are at least seven techniques to make cross domain script app and plus one special way for flash player only.

1) Using crossdomain.xml . This is a special technique invented for Flash player. For example, if a Flex programmer wants his flash application loaded from Web site to access resource on Web site B, which is different from its original site, he can ask the administrator of Web site B to put a crossdomain.xml file on the Web site B. In the xml file, it will be declared that this site is allowed to access resource on Web site B. BTW, this crossdomain.xml could be security hole for any site that allow user to upload file. crossdomain.xml should be forbidden to be uploaded. Here are two samples Google Docs puts Google Users at Risk and Using Google App Engine as a Proxy Server

2) Using reverse proxy. One traditional way to make cross domain script app is using reverse proxy. Actually, I really think this is a "walk around" technique for cross domain script as its idea is to "cheat" Web browser that content from different domains are from same domain, which is actually reverse proxy's domain.

3) Using digital Sign Javascript. This technique is similar as signing a Java applet. However, this will suffered from different actions taken by Web browser users. The code can not do cross domain request if end user say NO.

4) Access-Control-Allow-Origin HTTP header field. It is defined by W3C as Cross-Origin Resource Sharing. It is supported by Fireforx 3.5 or newer and IE 8 or newer. In IE, for the Internet access, you need to enable it. For Intranet access, by default, it is enabled.

"Access-Control-Allow-Origin" header is not just one HTTP header. It is a set of HTTP headers. Below lists out some.

Access-Control-Allow-Origin: http://yiyujia.blogspot.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: PROPFIND, PROPPATCH, COPY, MOVE, DELETE, MKCOL, LOCK, UNLOCK, PUT, GETLIB, VERSION-CONTROL, CHECKIN, CHECKOUT, UNCHECKOUT, REPORT, UPDATE, CANCELUPLOAD, HEAD, OPTIONS, GET, POST
Access-Control-Allow-Headers: Overwrite, Destination, Content-Type, Depth, User-Agent, X-File-Size, X-Requested-With, If-Modified-Since, X-File-Name, Cache-Control
Access-Control-Max-Age: 3600


5) using iframe. iframe is a popular way for Web app developer to achieve cross site script programming. There are many online articles describe XSS with iframe.

6) Using JSON Padding (JSONP). This method include a server side proxy programm, which generate data in javaScript type (JSONP) and use a callback parameter to allow javascript from other domain residing in browser to consume the data. You can make your own server side proxy program. However, here are two example from yahoo (demo link) and google (demo link)respectively.

7) using bookmarklet. If it is possible for software vendor to ask user to bookmark the web page, we can create a bookmarklet to achieve cross site scripting. A bookmarklet is a piece of JavaScript code attached to hyperlink URL. Once the hyperlink is clicked, your JavaScrript code is run. There is limitation for the length of JavaSccript code. However, with dynamic JavaScript loading, we can easily workaround this limitation.

As conclusion, methods 1 and 4 are similar: server tells browser that it is OK for script loaded from other domain to access its resource. Method 2 is a popular way to walk around the cross domain forbidden. But, it block some information from client from our server side application too. Method 3 is complex and highly depends on end user's behavior. Methods 4, which depends on support from different Web browsers. However, those popular web browser supports this header and they are upgraded quickly. Method 5, using iframe, is a well known XSS techniques. Method 6 is also a technique belongs to server side solution. Method 7 is an interesting way.

BTW, for mod_jk does not work with mod_headers. But, it is easy to write a servlet filter to add any HTTP headers you want.