Giters

tpeczek / Lib.AspNetCore.Security

Lib.AspNetCore.Security is a library which provides security features like Content Security Policy, Strict Transport Security or Expect-CT for ASP.NET Core

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Adding directly to the CSP sources from controller

jords1987 opened this issue · comments

commented

Hi,

Just downloaded this porject and it looks great, want to know if it will accomodate one of my requirements... I have a controller that is returning
return Content(<html><script>{window.top.location.href = \" Request.Scheme}://{Request.Host}/Error/Index\"}</script><body></body></html>

This is being used to break out of an iframe.

I want to be able to generate the hash for this and add it to the CSP header on the fly.

Can you think of a way to achieve this with this library.

Thanks for any help

commented

Hi,

As you have already noticed there is no way to achieve this without some changes. I need to think about an API, probably it will be best to expose it directly on IContentSecurityPolicyInlineExecutionFeature without introducing additional components, something like this:

public IActionResult DynamicContnt()
{
    string scriptContent = "{window.top.location.href = \" Request.Scheme}://{Request.Host}/Error/Index\"}";

    IContentSecurityPolicyInlineExecutionFeature cspFeature = HttpContext.Features.Get<IContentSecurityPolicyInlineExecutionFeature>();
    cspFeature.ComputeAndAddScriptHash(scriptContent);

    return Content($"<html><script>{scriptContent}</script><body></body></html>");
}

It feels to me a little bit better and doesn't require consumer to have dependencies on both libraries (but I would still like to give it a thought).

commented

Hi thanks for the Reply,

Yes reason I put it in a new api is so that it could be stubbed for unit testing and if it was used in a service class or something outside of the controller. But it would take some configuration In startup.cs

Your solution would work for my requirement though and then could wrap up httpcontext.features.get

let me know if I can help further :-)

commented

We would probably also need to expose a function to get the current nonce so that it can be added to the script tag in the return

commented

Yes reason I put it in a new api is so that it could be stubbed for unit testing and if it was used in a service class or something outside of the controller.

That testing argument makes sense, I need to give it some more thought.

We would probably also need to expose a function to get the current nonce so that it can be added to the script tag in the return.

Unless I've misunderstood you, that's already covered by IContentSecurityPolicyInlineExecutionFeature.Nonce, but would to have be exposed in that new API as well if that would end up being the approach.

commented

Yes you are right about the nonce, I see now...

Either way you choose, the implementation doesn’t look too difficult, the code is very well structured already :-)

commented

Thank you :). If nothing blows up I should have something by the end of weekend.

commented

I've decided to stick with feature, as this is related specifically to the processing of the current request.

Service approach would result in either an "extension like" service (totally dependent on passing HttpContext as parameter) or hidden dependency on IHttpContextAccessor. Using IHttpContextAccessor is still an option when access is needed from different context than controller and testability is just an aspect of properly stubbing HttpContext.