Identityserver4: Content Security Policy Header Extensibility

[cbeall]

I was wondering if there is any plans for CSP Header extensibility.

I'm experiencing a minor errors in chrome where my favicon doesn't load. When my client and IDP are on different URLs, I'm seeing an error:

Refused to load the image 'http://mysite.com/favicon.ico' because it violates the following Content Security Policy directive: "default-src 'none'". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback

The current implementation with CSP headers defined in the various IEndpoint classes is fairly rigid. There is a potential work around by writing some middleware to add the CSP header earlier in the request, but that doesn't seem ideal. It be nice to have more control within the endpoint classes themselves, so that the existing directives (especially the script-src with the sha256), doesn't need to be recreated explicitly in middleware.

I was having another issue (more of an edge case) where my client, immediately upon authentication, redirects to another client. This fails because the redirected URL wasn't set within the form-action directive.

Refused to send form data to 'http://otherclient.com/' because it violates the following Content Security Policy directive: "form-action http://originalclient.com".

Ultimately, it be great if there was some sort of "CSP Directive Service" that could be extended to give more control with the headers.

[brockallen]

The code for this is all there for you to modify: https://github.com/IdentityServer/IdentityServer4.Quickstart.UI/blob/release/Quickstart/SecurityHeadersAttribute.cs#L26

[cbeall]

Ah... I missed that. Thanks!

[cbeall]

I spoke too soon here. The SecurityHeadersAttribute gives me the control of the views, but it does not give control of the response of the AuthorizeResult endpoint. I'm able to reproduce the above problem running the quickstart Identity Server with the SecurityHeadersAttribute. The only change I made was that I added a client with an implicit flow and disabled consent for simplicity.

The client (localhost:5000) challenges and redirects to identity server (localhost:1941). I enter local valid credentials into the form and the page is post to http://localhost:1941/account/login?returnUrl=....

The /account/login action calls SecurityHeadersAttribute, but nothing happens because it is RedirectResult and not ViewResult. This is not an issue. The redirect sends the browser to http://localhost:1941/connect/authorize/login?client_id...XXX.

SecurityHeadersAttribute does not impact http://localhost:1941/connect/authorize/login (its not within MVC), so that endpoint responds with a 200 and includes the default CSP header:

default-src 'none'; frame-ancestors http://localhost:5000; form-action http://localhost:5000; script-src 'unsafe-inline' 'sha256-VuNUSJ59bpCpw62HM2JG/hCyGiqoPN3NqGvNXQPU+rY='

Because http://localhost:1941/connect/authorize/login responds with a 200, Chrome automatically tried to fetch http://localhost:1941/favicon.ico. The CSP policy doesn't allow for this and you can see in the Chrome network trace where the status there is "(blocked:csp)".

At a minimum, I'd suggest adding to img-src self directives anywhere where IdentityServer sets "default-src 'none',

That would resolve the fav icon issue, but the only way to get control of the CSP headers in the AuthorizeResult response is to set up middleware to watch for the paths and write the CSP header (replicating the logic where origin of redirect uri is added) before AuthorizeResult has a chance to set it.

---

A less important detail, but from what I can tell, Chrome does not write the fav icon error to the console (it only shows up in network trace), unless there are additional CSP errors. When there are additional CPS errors, the favicon issue is written to the console with the following message:

Refused to load the image 'http://localhost:1941/favicon.ico' because it violates the following Content Security Policy directive: "default-src 'none'". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback

[brockallen]

So what's the actual impact of this? Seems like a chrome issue more than anything...

[cbeall]

Fair point on the favicon issue. Adding img-src {formOrigin} to the header string would mitigate it, but in the end, there is no real user pain and Chrome probably shouldn't even make that request when CSP forbids it.

The genesis of this for me was the other CSP issue I had. When my Identity Server redirects to client A, the endpoint designated to be redirected to performs an action (merging accounts), and upon success immediately redirects to Client B. The "secured area" of Client A has no UI.

I'm finding that when it redirects from Identity Server to Client B via Client A (with no user intervention at Client A), the browser rejects this because the AuthorizeResult CSP header doesn't allow form-action to client B (even though the actual form post is to Client A). My guess is this could also be solved with a hidden form post from Client A, but I've yet to try that yet.

With these two specific issues, one may be more of a Chrome issue and the other is perhaps an edge case. I was just originally wondering that given these sort of cases may arise, if there were plans for extensiblity of CSP headers created by AuthorizeResult. But at the same time, I could also see how the complexity of adding extensiblity there may not be justified by the amount of value added in return, especially when there are workarounds for everything I've identified.

[brockallen]

Yes, for this other issue I think it's the same one we saw and I addressed it today: https://github.com/IdentityServer/IdentityServer4/issues/659

[cbeall]

Yes, that looks like that will solve it. I should be all set with the next release. Thanks

[armitagemderivitec]

Hi,

I'm using IdentityServer4 v1.5.2 and IdentityServer4.AspNetIdentity v1.0.1 (the latest from nuget) and I am still seeing 'unsafe-inline' when hitting the /connect/authorize/login URL. Was this actually solved and if so what could I be missing?

I need to resolve as it's being picked up by our veracode security scan.

Thanks

Mike

[jaydgus]

We are using IdentityServer4 v2.1.1 and are getting the "Refused inline script..." on the '/connect/authorize/callback' page on the Ipad's Safari and Chrome. Therefore it just sits on the callback page.

I've tried intercepting/modifing the CSP header at various places without any luck. Do we need to download the source and reference the project so that we can customize the CSP header? etc? Any advice is greatly appreciated!

Thanks,
Jay

[x3haloed]

I would also like CSP header extensibility of some kind. I would like to add an allowed source to the frame-ancestors policy, because I have the following scenario:

• Two apps that authenticate against IS4 -- let's called them 'A' and 'B'.
• B must be framed within A so they appear to be the same application to the end user.
• B is not accessible until user authenticates to A, which creates a session on the IS4 server with cookie authentication to ASP.NET Core Identity.
• B should then (ideally) always be connecting to IS4's Authorize endpoint under circumstances where the user has a valid cookie-based session/auth. If the cookie-based session on the IS4 is not valid, I want B to tell A to force re-authentication and redirect to IS4 login. I _do not want_ to embed the IS4 server's login screen _into_ application A in this case.

As far as I can tell, there used to be a nice option for this in IS3, but there is no simple way to accomplish what I need in IS4:
https://identityserver.github.io/Documentation/docsv2/advanced/csp.html

Is that correct? Do I have a valid need here?

[x3haloed]

Shoot -- I just updated IS4 to the latest version and everything is working. It appears that you've relaxed the frame-ancestors policy for the Authorize endpoint. Sorry!

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.