Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
add comment

2 Answers

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.

share|improve this answer
    
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 Dec 29 '12 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 Jan 5 '13 at 19:35
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.