Inline <style> elements violates style-src Content Security Policy

[jelbourn]

See https://developer.mozilla.org/en-US/docs/Web/Security/CSP/CSP_policy_directives#style-src

The framework should support users that want to build their apps for CSP. In this case, the style-src directive would be in violation by Angular 2's use of inline <style> elements for things like CSS encapsulation.

I was curious if Angular 1 supported CSP, and it seems that Angular 1 indeed generates a stylesheet (build/angular-csp.css) that users can consume for CSP mode.

cc @tbosch @matsko

[tpetersheim]

Is there any update on this issue?

[fredericoramos78]

+1

[xnnkmd]

@IgorMinar Can this be fixed so we can write secure Angular apps ?

[skatterwe]

Ich kehre zurück am 01.11.2017.

Ich werde Ihre Nachricht nach meiner Rückkehr beantworten. In dringenden Fällen senden Sie bitte eine Kopie Ihrer E-Mail für technische Angelegenheiten an [email protected], ansonsten an [email protected]. Ein anderer Mitarbeiter wird sich dann Ihrer E-Mail annehmen.

Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht "Re: [angular/angular] Inline

Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist.

[ghost]

+1

[eranation]

Is there any update on this? Any workarounds until it's officially addressed?

[alexleen]

+1

As a workaround, we had to move all of our component level styles to a global style sheet. This meant creating src/styles.css, copying over all of our component styles, and adding this file to the .angular-cli.json styles array. All *.component.css files were then removed.

See component styles and global styles for more information.

Note: changing the view encapsulation did not seem to work (as some suggested).

[epeschier]

We did the same as @alexleen. But when you do a production build, angular will still leave an empty tag in the head of the HTML document, resulting in a style-src csp error in the browser console. The app is running but can this be removed somehow?

[redevill]

Is this due to the shared_styles_host.ts file line 47?

   this._styleNodes.add(host.appendChild(styleEl));

This is the spot my CSP is identifying, and was wondering if this is the same issue?

[theRaffe]

Is there any update of this issue?? Or a work around

[jnmalapati]

any update or workarounds for this issue ?

+1

As a workaround, we had to move all of our component level styles to a global style sheet. This meant creating src/styles.css, copying over all of our component styles, and adding this file to the .angular-cli.json styles array. All *.component.css files were then removed.

See component styles and global styles for more information.

Note: changing the view encapsulation did not seem to work (as some suggested).

This doesn't seem to be work. Angular still adds the global styles as inline to the index.html file, not as a separate file.

[kgergooo]

@redevill That this._styleNodes.add(host.appendChild(styleEl)); can be because of an angular dependency. I also moved the component level styles into a global style but still getting the same csp inline style error, so I created a non minified angular build and I debugged the build. I get the csp errors because of the angular material npm package.

[Splaktar]

That this._styleNodes.add(host.appendChild(styleEl)); can be because of an angular dependency. I also moved the component level styles into a global style but still getting the same csp inline style error, so I created a non minified angular build and I debugged the build. I get the csp errors because of the angular material npm package.

@kgergooo Material has a couple of related, closed issues (https://github.com/angular/components/issues/12139, https://github.com/angular/components/issues/17783) but nothing open for CSP atm other then docs (https://github.com/angular/components/issues/12795). If you can create a reproduction of the problem, please open a new issue at https://github.com/angular/components/issues/new/choose.

[schivmeister]

Hijacking this issue as some discussion on this._styleNodes.add(host.appendChild(styleEl)); has already taken place...

We use Angular 9 for a true single-page application, meaning -- in addition to it being as good as a fully static website -- the server plays absolutely no part in templating whatsoever. With a "traditional" CSP configuration (which can be quite restrictive if we are specific about paths), we are still getting these violations from the main-es2015.* file (from different lines), which are beyond our control:

this._styleNodes.add(host.appendChild(styleEl));
...
(/** @type {?} */ (_document.head)).appendChild(styleEl);
...
el.setAttribute(name, value);

Each of these I suspect belong to webpack, flex-layout and/or ivy (could be material too but I didn't want to bother our front-end dev yet), and understand to be integral parts of Angular. This requires us to use unsafe-inline for the style-src directive, which is not acceptable as we intend to get security clearances at financial institutions.

The nonce-based "strict" mode is not a configuration that we can use, which is made clear by this FAQ. Using hashes is not a nice option either, since these hashes change on every build, even without changes in the code base!

When we decided to use Angular some years ago, we decided to trust the community and company behind it, but we ended up being quite surprised that such basic and well-documented security practices are not yet covered, given that it has been more than 4-5 years since widespread adoption by browsers.

Or, maybe Angular is ahead of the times...

[SymbioticKilla]

Any update on this issue?

[mfcarey]

This is increasingly becoming an AppSec showstopper issue for our Fortune-500 company's adoption of Angular due to non-support for strict style-src CSP handling in a way that doesn't totally undermine style encapsulation and application performance. Can we get any feedback as to potential solutions as relates to the Angular development roadmap?

[troll-os]

Bumping in, as stated above we have to deal with huge companies not allowing certain directives and this can lead us in difficult positions as Angular is part of our base stack. This issue is greatly underestimated IMO.

[ryndm]

Did anyone find any workaround ?

[ferdiesletering]

I've created a workaround to allow inline styling with Nginx. The browser does not block inline styling from Angular Material and ngx-bootstrap due to a nonce token. I would appreciate some feedback :)

[IgorMinar]

I discussed this with the security team at google, and they are not concerned about Angular requiring default-src self; style-src unsafe-inline; as the default policy, because the risk associated with this policy is very low.

We are updating the Angular docs to reflect this: #43553

Does anyone have a concern about this?

[binarious]

[...] because the risk associated with this policy is very low.

What's the reasoning behind this?

Personally I would prefer Angular not to require inline styles. They have their own attack vectors[1][2] and these could be relevant depending on an app's context.

[noguespi]

[...] because the risk associated with this policy is very low.

What's the reasoning behind this?

Personally I would prefer Angular not to require inline styles. They have their own attack vectors[1][2] and these could be relevant depending on an app's context.

I think it is because in modern browsers injecting javascript or html through style is now impossible. The attacker may still be able to alter the look of the website, but it will be limited (no html injection, only style modification).

It is a tradeoff, protecting totally against XSS and having a perfect CSP (default-src 'self') may require too much works for angular team. The security may be good enough as is.

[db6edr]

If the injected style is able to break out of its context, it can do all kinds of bad stuff. There's a neat introduction to mutational XSS here: https://www.youtube.com/watch?v=lG7U3fuNw3A

So, yeah, while it comes to a tradeoff between protection against attacks and its cost, I'm interested in the reasoning behind this decision of Google's security team as well.

[noguespi]

The link you provided is not specifically about XSS in styles, but globally about bad sanitizing of HTML/javascript and XSS.

What need to be discussed is how it is possible to exploit XSS when you can only inject styles :

<style>
.mystyle{
  // inject whatever you want here
}
</style>
<a style="color: red; // or here" >link</a>

Injecting a </style><script>alert(1)</script> or " href="javascript:alert(1);" is out of the scope because it is no more an XSS in style, hence not related to the content security policy style-src unsafe-inline;.

So far I didn't found a working XSS PoC which only rely on the style and work on a modern browser. You may have old exploit like background-image:url("javascript:alert('XSS')"); or <div style=xss:expression(alert(1))> that works, but only on very old browsers (IE 7 etc. these browsers doesn't even support Content-Security-Policy !).

The closest I have found is :

<style>@keyframes x{}</style><xss style="animation-name:x" onwebkitanimationend="alert(1)"></xss>

exploit link

However, you can see the alert(1) is inside the attribute onwebkitanimationend, this will be blocked by angular CSP because it also requires script-src 'unsafe-inline'.

What we need to find is an XSS exploit which works with the Angular CSP default-src self; style-src unsafe-inline; and on a modern browser.

I'm not saying it is impossible but I'm trying to explain how one may come to the conclusion the security risk of style-src unsafe-inline is low in the context of Angular and an acceptable trade-off.

[binarious]

The paper I linked above has some attack vectors which should work in modern browser.

Just to name one example: When data: for image-src is allowed, something like this is possible:

a {
  content: url('data:image/svg+xml;%20charset=utf8,%20%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20height%3D%2260%22%20width%3D%22200%22%3E%0A%0A%20%20%3CforeignObject%20y%3D%220%22%20x%3D%220%22%20height%3D%22100%25%22%20width%3D%22100%25%22%3E%0A%09%3Cdiv%20style%3D%22color%3A%20blue%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml%22%3E%0A%09%09I%20am%20%3Cpre%3EHTML%3C%2Fpre%3E%0A%09%3C%2Fdiv%3E%0A%20%20%3C%2FforeignObject%3E%0A%3C%2Fsvg%3E');
}

Source

[noguespi]

yes that's like my example, it is exploitable on modern browser, but not with default angular CSP configuration.

[HPS-Worldwide]

We are facing some security alerts regarding the "unsafe-inline" directive in CSP, and this ticket has been opened for 6 years now. I read @noguespi comment and I agree, however security vulnerabilities are not always know until they came out :) in terms of security it is always better to anticipate than to react (no pun intended)

I don't understant why Angular team persist in requiring unsafe-inline styles : what is the effort to get rid of it ?

[db6edr]

While checking some alternative frameworks, I found that many components use dynamically calculated values for the style attribute. This is true for Angular as well. Two examples I've got at hand are Angular Material's Slider and Sidenav. Yes, I know, they're part of Angular Material and not directly Angular, but seeing that Material's docs are hosted at a subdomain of Angular: does this really matter?

So the effort would be to find and implement alternatives for all these components and giving lots of other component developers a huge slap in the neck by forcing them to do the same.

[arun-rajagopal-42]

+1

As a workaround, we had to move all of our component level styles to a global style sheet. This meant creating src/styles.css, copying over all of our component styles, and adding this file to the .angular-cli.json styles array. All *.component.css files were then removed.

See component styles and global styles for more information.

Note: changing the view encapsulation did not seem to work (as some suggested).

In addition to the above, we had to deal with a lots of css conflicts and had to completely work over all our css files.

[Rugshtyne]

As I've expressed in this Angular Material issue, this is even affecting Angular Material and changes would be greatly appreciated. It would be great to have as a solution a possibility to add CSP nonces to the injected style tags.

We have used 'unsafe-hashes' for some of the styles attributes but now, according to the government of Netherlands, which we have to comply to, these should be removed.

If some other workaround is possible or a minor fix in a code would do, it would be great to get that information.