CODEWITHSUNDEEP
javascriptajaxsecurityembedding
oltreseba
oltreseba

Reputation: 142

Security in embedded javascript and HTML

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

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?)

Upvotes: 6

Views: 1933

Answers (4)

rydwolf
rydwolf

Reputation: 1528

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.

Upvotes: 0

rook
rook

Reputation: 67019

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

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

Upvotes: 0

epascarello
epascarello

Reputation: 207521

Facebook had their own "JavaScript" coined FBJS which did the sandboxing by having control over what could run.

Upvotes: 1

Engin
Engin

Reputation: 166

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. (i.e. 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.

Upvotes: 1

Related Questions