Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Best practice regarding Security-Relevant HTTP Headers
#9
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
Reply


Messages In This Thread
RE: Best practice regarding Security-Relevant HTTP Headers - by Alexandre Machado - 11-07-2019, 06:21 AM

Forum Jump:


Users browsing this thread: 1 Guest(s)