Security in embedded javascript and HTML

Question

I'm trying to find a solution for the following situation:

• I've a web application made of HTML, javascript, AJAX, ad so on.
• I want users to contribute to my application/website creating plugin that will embedded in it.
• This plugin will be created using similar technologies (ajax, HTML, etc) so i need to allow plugins to run their own javascript code.
• Each plugin will work in a page that will contain some user information and the plugin (like old fbml facebook applications)

The problem is that in this way the plugin can also made calls to get users information . (because since plugin's code is embedded it's domain will be the same of the main website, and the code will be entirely on my website).

So the question is: how can I avoid it and have a precise control about what information a plugin can get about the user?

The plugin will not be checked and can be changed anytime, so reading all the plugin code is not a solution.

I'm open to any proposal, possibly easy and effective, and possibily not putting the whole plugin in a iframe.

-- EDIT: How did facebook do when there was the old way to create applications? (now it's only iframe, but there was FBML application way, how did they get this secure?)

Answer 1

Have you ever heard of exploits allowing arbitrary code execution. Which is one of the most dangerous attacks ?

Well, in this case you are explicitly and willingly allow arbitrary code execution and there's almost no way for you to sand box it.

1) You can run the "plugin" within an iframe from a different subdomain to sandbox it in there, as you've mentioned. This way plugin can't reach your cookies and scripts.

Note that, if you want the plugins to communicate with your services from this domain, then it will be cross-domain communication. So you either need to resort to JSONP or use new cross domain access control specifications. (ie return appropriate headers with your web service response -- Access-Control-Allow-Origin "plugins.domain.com")

2) Create your own simple scripting language and expose as much as you want. This is obviously tedious, even if you manage to do that, plugin developers will endure a learning curve.

Answer 2

Facebook拥有自己的“ JavaScript” 硬币 ，即FBJS ，它通过控制可以运行的内容来进行沙箱测试。

Answer 3

Without a juicy backend, this really limits the impact of your script.

However you still have to worry about DOM based xss and Clickjacking

Answer 4

It's 6 years later, but I feel it's important to provide a modern solution to this. The new(er) sandbox attribute can be used to limit the capabilities of an IFrame.

A simple implementation of this system would allow only the allow-scripts permission to the IFrame, perhaps with a simple JS file which would be included along with each plugin containing a few custom library functions.

In order to communicate with your HTML page, you would use postMessage . On the plugin end, a library like I mentioned above could be used to transfer commands. On the user side, another system would have to validate and decode these requests then execute them.

Since a sandboxed IFrame doesn't have cross origin capabilities, it cannot directly modify the page. However, this also means the origin of the postMessage can't be verified, so some sort of code would have to be created for security reasons.