This is the fourth of four posts on our experience deploying Content Security Policy at Dropbox. If this sort of work interests you, we are hiring! We will also be at AppSec USA this week. Come say hi!
In previous blog posts, we discussed our experience deploying CSP at Dropbox, with a particular focus on the script-src directive that allows us to control script sources. With a locked down script-src whitelist, a nonce source, and mitigations to unsafe-eval, our CSP policy provided strong mitigations against XSS via injection attacks in our web application. In supported browsers, the only code allowed to run in our web application would be from our website, CDNs, and trusted third-party integrations. Unfortunately, deploying CSP with third-party integrations has its own risks and challenges. In this post, I will discuss how we handled these challenges using HTML5 privilege separation.
Risks with Third Party Integrations
For an example of a third-party integration code running on our website, consider the reactive chat widget from SnapEngage running on our business and marketing pages. The recommended mechanism for integrating with SnapEngage with a web application involves inserting the following code snippet into a script node in the HTML page
var se = document.createElement('script');
se.type = 'text/javascript';
se.async = true;
se.src = '//storage.googleapis.com/code.snapengage.com/js/' + chatId + '.js';
se.onload = se.onreadystatechange = function() { ... //elided
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(se, s);The above code creates a script node pointing to the SnapEngage library, sets up onload handlers, and inserts the node into the page. The loaded JavaScript library then creates the markup for showing the chat widget, the associated event handlers, and inserts them into the page.
There are two key problems with this approach. First, the chat widget markup and event handlers are not aware of CSP policy. So, depending on the widget’s use of eval and inline event handlers, our CSP policy breaks the chat widget. When we first deployed nonces for script-src on the Dropbox website, we had to disable it on pages relying on the widget (thus, increasing the XSS risk on the page).
A second, more subtle threat, is that this increases the trusted computing base of the Dropbox website to also include the SnapEngage servers. Recall that the same-origin policy means that all code running on www.dropbox.com origin gets the same privileges. Upcoming improvements to the web platform can mitigate this risk, but these are still under discussion at the W3C.
At Dropbox, we have been well aware of this risk and all our integration providers go through thorough reviews and mandatory security requirements. But, compromise of third-party providers is not unheard of and we deemed it an unacceptably high risk for the data that our customers trust us with.
One possible solution is to just copy the integration code to our servers and also modify the widget to not use inline event handlers. Unfortunately, this is an expensive and extremely intrusive solution. Worse, it means that any improvement to the widget must involve a manual check and code commit at Dropbox. Note that automating this has many of the same security concerns that we originally had.
Privilege Separation to the rescue
Given these issues, we instead investigated privilege separation for mitigating the issues posed by such third party integration. The core idea of privilege separation is simple: instead of running third-party code directly in the Dropbox origin, we run it in an unprivileged origin and include it on our website via an iframe. Using postMessages between the iframes, the Dropbox origin provides a smaller, trusted API for ensuring the relevant functionality while not compromising security.
This is similar to the privilege separated architecture of OpenSSH and Google Chrome; the unprivileged child processes correspond to unprivileged origins while the privileged process corresponds to the privileged (Dropbox) origin. Instead of the IPC mechanisms used in binary applications, we use postMessage to communicate between iframes.
Concretely, lets do a deeper dive into how the SnapEngage integration looks with a privilege separated design. On loading a page that needs the SnapEngage chat widget, code on https://www.dropbox.com origin creates an iframe pointing to https://www.dbxsnapengage.com. The code on dbxsnapengage.com, in turn, loads the SnapEngage chat widget per the sample code above. The CSS on the iframe hides the border and the iframe’d chat widget looks exactly the same as it would have if included directly.
Of course, this is not sufficient. For maintaining the functionality, the chat widget needs to integrate with the main page. For example, we want to show the chat widget only when users click the “chat” button at the top of the page. Previously, the JavaScript code would listen for a click on the chat button and execute startSupportChat function.
function startSupportChat() {
SnapEngage.setWidgetId(SUPPORT_ID);
SnapEngage.setUserEmail(chatData.Email, true)
SnapEngage.startChat("How can we help you today?")
}startSupportChat is a function that calls the relevant SnapEngage code that initiates the chat. Now that SnapEngage code is running on dbxsnapengage.com, this function does not do anything (nor does it exist on www.dropbox.com). Instead, we modify the code on www.dropbox.com to send a message to the iframe.
DropboxSnapEngage.startSupportChat = function() {
this.chatRequested = true;
DropboxSnapEngage.showSnapEngageIframe();
return DropboxSnapEngage.sendMessage({
'message_type': 'startSupportChat',
'chatData': this.chatData
});
};
DropboxSnapEngage.sendMessage = function(data) {
var content_window;
content_window = DropboxSnapEngage.getSnapEngageIframe().contentWindow;
return content_window.postMessage(data, this.SNAPENGAGE_IFRAME_ORIGIN);
};This sends a message to the iframe on dbxsnapengage.com. This page, in turn, defines the following postMessage event handler that calls startSupportChat in turn.
function receiveMessage(event) {
if (!validOriginURL(event.origin)) return;
var data = event.data
switch (data.message_type) {
//elided ...
case "startSupportChat":
startSupportChat();
break;
//elided ...
}
}The end result is that clicking the “Chat” button shows the iframe and sends the chat widget code the appropriate message to start the chat. But, all the chat widget code is now running on the unprivileged dbxsnapengage.com origin.
Note that this is just an example: we use privilege separation in multiple places on the Dropbox website to reduce risk from third party integrations (e.g., our integration with our payments provider). Another subtle but important feature of this design is that SnapEngage did not have to make any changes and can continue using even inline event handlers. We own and operate the dbxsnapengage.com domain and also implemented the postMessage API that crosses the privilege boundary.
Special thanks to Mark Gilbert and Brad Stronger who took the lead on implementing this integration with SnapEngage. This wraps up our blog post series on CSP. If this sort of work interests you, we are hiring! Come talk to us at OWASP AppSec USA, if you are around!
