Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Best practice regarding Security-Relevant HTTP Headers
#11
Hi again, any feedback on the above would be welcome. I need to finalize a release soon, and I am OK with implementing "partial" CSP support (without the dynamic nonce parts) as a first step. But I need to know if the parts without nonce still are meaningful? (Or at least enough to be able to "tick the CSP checkbox" for some of our customer's security requirements). Then as a second step I could dive into it a bit deeper and try to implement a more complete support (but then I need to know what I did wrong with the nonces in the header).

Best regards

Magnus Oskarsson
Reply
#12
Yes, you are correct. Chrome will ignore unsafe-inline is ignored if nonce exists. That was added as a workaround for a Firefox bug in my test and never removed.

You can remove the unsafe-inline from script and style sections and see how it goes. If something is failing you can remove the nonce and leave the unsafe-inline, until the original issue which cause it to fail (with nonce present) is fixed.... hopefully you can understand what I meant :-)
Reply
#13
(11-07-2019, 06:21 AM)Alexandre Machado Wrote: CSP headers need to be set at each response.

CSP is a royal PITA and, as Chad mentioned, it is mostly nonsense. Most people who implement it are actually forced to comply with some "rules" created by web security audit companies. If that's your case then I believe you have no real choice.

The best place do set this is on ServerController.OnAfterDispatch event, yes.

Here is some code extracted from a test application, which can help you with that:


Code:
procedure TIWServerController.IWServerControllerBaseConfig(Sender: TObject);
begin
  // Content Security Policy - CSP

  FServerList := 'http://127.0.0.1:8888 ';
  // you may add to the server list other domains, for instance, a google API resource:[/font][/size][/color][/font][/size][/color]
  // FServerList := FServerList + ' https://fonts.googleapis.com ';
end;

function TIWServerController.GetCSPValue(aReply: THttpReply): string;
var
  WebApp: TIWApplication;
begin
  // Content Security Policy - CSP
  Result := 'frame-ancestors ' + QuotedStr('none') + '; ' +
            'base-uri ' + FServerList + '; ' +
            'default-src ' + FServerList + ' ' + QuotedStr('nonce-' + aReply.Nonce) + ' ' + QuotedStr('unsafe-eval') + '; ' +
            'script-src ' + FServerList + ' ' + QuotedStr('nonce-' + aReply.Nonce) + ' ' + QuotedStr('unsafe-eval') + ' ' + QuotedStr('unsafe-inline') + '; ' +
            'style-src ' + FServerList + ' ' + QuotedStr('nonce-' + aReply.Nonce) + ' ' + QuotedStr('unsafe-inline') + '; ' +
            'img-src ' + FServerList + ';';
end;

procedure TIWServerController.IWServerControllerBaseAfterDispatch(
  Request: THttpRequest; aReply: THttpReply);
begin
  aReply.AddHeader('Content-Security-Policy', GetCSPValue(aReply));
end;

Have in mind that:

- In IW, CSP is based on nonces. A nonce is a base-64 encoded big 160-bit random number, unique for each response. Each THttpReply instance will generate a new nonce which can be obtained via its Nonce property. Nonce can also be obtained via WebApplication.Nonce property.
- All internal <script> or <style> tags will contain a nonce, which should match with the response header. If not, the browser will block it and something will fail when page is rendering (scripts won't run, styles won't be applied, images won't load, etc). In general a failure is highly visible.
- default-src should be enough in most cases, but Firefox has a serious bug when no script-src is found, so I strongly recommend you to keep them all (i.e. default-src, script-src, style-src and img-src at least - your app might need others)
- unsafe-eval is needed for script processing and that's not going to change. JavaScript doesn't offer a real alternative for eval() when executing code generated on server side on the fly. And the real point is: If one can inject code into an HTTPS response, on the fly, CSP won't actually stop him...
- you can start with more permissive policies (like the one above) and then play with it and see how your application behaves.

Please let me know if you need further information

Hi,
I found this old thread and we also have this same requirements, unfortunately we are still running under IW 14.
We have previously added the CSP Header but there is an additional requirements from audit team is to not use the inline scripts and use nonce or sha instead. It seems that nonce property of aReply is only available on IW15.
Is there are way to implement the same on IW14?

Thanks.
Reply
#14
Hi,

CSP is not easy to implement in any circumstance, even if you have a static web site composed only of a bunch of HTML, CSS and JS files. On the contrary, CSP is hard... depending on the level of your requirements it can be *very* hard. Believe me, I've been there.

It is much simpler for you to just migrate to latest IW 15 and use the built-in functionality which is already prepared.

The problem is not only adding CSP headers to your response. All HTML, CSS and JS needs to be also considered and probably changed in order to comply with CSP.
Reply
#15
Hi Alexandre,
Thanks for the reply. We are on the process on checking IW15 but since we have a big system there are lot of considerations and testing. Also we need to consider TMS. Anyway hopefully we can convince our Audit to hold this CSP thing and wait for IW15 update.
Thanks again.
Reply
#16
I concur with Alexandre. CSP is no small walk in the park. I dont see it being feasible for a user to add to 14.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)