8

I am writing an internal tool that will support plugins written by other developers. Ideally, these plugins would have a Javascript component to allow people to make widgets. Some of the pages these widgets operate on may contain sensitive data. What I want to avoid is the developer writing a plugin that has javascript which posts this data to some external server. However, it is essential to the operation of these widgets that they can manipulate the data on the page. Basically these widgets should only be able to effect the presentation of the data, but they should not be able to steal it.

I have looked at adsafe, but this is too restrictive because these widgets can only manipulate the dom provided by the adsafe widget, and so could not access the data they need. I also looked at Google Caja, which might be an okay solution, though its cross compilation would make the code execute slower in a performance critical environment (I have also not played with it, so I don't know specifically if I can use it to avoid posting).

I think the "ideal" solution might be some kind of static analysis tool that can eliminate "just" programs that try to contact an external server, but I welcome any suggestions that could work.

Improve this question

3 Answers 3

Reset to default
6

Code is inherently dynamic and it is and will always be impossible to control the behavior of user-supplied code. By allowing users to execute JavaScript you are implementing a Cross-Site Scripting (XSS) vulnerability. XSS is also commonly used to expose users to Drive By Download attacks which is strangely missing from your threat model.

One way of mitigating the threat posed by XSS is to isolate user supplied scripts to a sub-domain such that they cannot access sensitive information due to the Same-Origin Policy. This does nothing to stop an attacker from executing BeEF on users of your web application or perform another type of drive by download attack.

Improve this answer
2

You could use the Content-Security-Policy. This can add some script restrictions. However it is not used by all browsers and it might not be fine grained enough for you.

Improve this answer
2
  • The CSP can't solve this problem. The point of the application is that the attacker can supply arbitrary code to be executed. The CSP allows a developer to dictate where a script can come from in order to prevent an attacker from supplying arbitrary code. Chicken or the egg.
    – rook
    Commented Dec 29, 2012 at 15:33
  • Actually CSP has the "connect-src" attribute, but yes the best separation can be achieved by downloading the plugin from its own origin/domain.
    – eckes
    Commented Jan 5, 2013 at 19:35
1

I recently created a js-library (https://github.com/asvd/jailed) which might be suitable for your purpose. The idea is as following:

  • the untrusted code is executed in a restricted sandbox (restricted subprocess in Node.js, or a web-worker inside a sandboxed iframe for a web-browser);

  • the sandbox has no access to anything, but you can "expose" a set of external functions into the sandbox, thus precisely defining the API and the permissions of what is permitted for the untrusted code to perform;

  • then the code may directly call those functions to manipulate or interact with the main application in the permitted way (under the hood, this is acutally emulated using messaging mechanism).

This might also be a bit inconvenient, meaning that if you wish to permit an opportunity to manipulate the DOM nodes for instance, you have to explicitly re-describe the whole API in terms of exported functions.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .