Arrrg, cross site scripting security

OK, I know it is there for a good reason, but there are sometimes really good reasons why you want a web page to go and get data from a different server or even a different port on the same server.

Seems I am not alone. This page has some ideas I am about to try...

What gets me is why they bother. You can include images from another site, javascript from another site, iframes from another site. The ways to exploit things are there.

What is even dafter is there seems to be a really noddy way for a script to get data from another site by a simple document.write("");

FYI, what I am trying to make is a push server that will update lots of web browsers with new data in real time. It seems you can drip feed browsers with a new line every 10 seconds or so to keep them waiting forever, and then feed the data when you have it. The idea is the server can push one XML object to a thousand waiting browsers that all get the data at the same time and don't have to poll for it! I can see loads of uses for this, including little things like live updates on fault notes and diagnostics tests on the A&A control pages, but there are loads of applications.

I'll update this when I understand the rules more.


  1. I know it's a pain, but would you really want to be able to browse to a webpage on my site, and have that website instruct your browser to go to your bank's website and transfer all your money to me - and because it's running on your machine, in your browser, is able to do so?

    The rules that exist now are a real pain sometimes but are there for a reason and seem to be a reasonable compromise between convenience and security.

    The usual ways to achieve what you want are to use something like "JSONP" or to proxy the data on the server that the webpage came from.

    And yes, it's a pain!

  2. Yes, there are ways around it, which is the point. If there is a way around it, then whats the point. hackers will use the work around too.

  3. I believe the BBC has done this sort of thing before, I think they used AJAX to accomplish it.

  4. It's a problem that this stuff is so complicated and difficult to get right. As John Burton said, though, you do need it.

    Yes you can get round it to a certain extent with iframes and similar things, but that only allows you to send requests. You can't see the results in most circumstances.

    If you think the security model is ineffective, try writing a webpage that causes a user's computer to send spam (through Hotmail say) while your page is displayed. You can't do it for various reasons, but the most important one is that you need to read Hotmail's responses, not just send it requests.

  5. Have you looked at HTML5 web sockets? They don't entirely make sense to me but I think the idea is to allow you to create something analogous to a network socket in javascript-space, which works a whole lot better than monkeying around with drip-feeding http. These people: http://www.kaazing.com/products have done some magic to implement them in non-HTML5 browsers.

  6. The wikipedia page on Comet describes a number of techniques for pushing content to http clients.


  7. We use this "drip feed" as the basis for our Web IRC client for our "live support chat". No javascript needed!


Comments are moderated purely to filter out obvious spam, but it means they may not show immediately.

Hot tubs are expensive (again)

Yes, my hot tub is expensive. Our whole house total power consumption was, typically, 55 to 60 kWh per day. Which is a lot. I have some excu...