Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Best practice regarding Security-Relevant HTTP Headers
#1
Hi. We have a customer that has performed a penetration test for one of our web applications and claims in one finding that several security-related HTTP header are missing, these are Strict Transport Security, XSS Protection, Content Type Options and Content Security Policy. They recommend that at least the three first are set in order to consider the finding as fixed. We do however set these three at the beginning of a session according to recommendations in a previous forum thread, but I guess that these do not carry over to every response sent by the web application. Our current code looks like this:

Code:
procedure TBaseClientServerController.IWServerControllerBaseNewSession(aSession: TIWApplication);
...
begin
  if Assigned(aSession) and Assigned(aSession.Response) and (SSLOptions.Port <> 0) then
    SetCustomHeadersForHSTS(aSession);
...
end;

{Impl. from Hafedh TRIMECHE, see https://forums.embarcadero.com/thread.jspa?messageID=677727#677727}
procedure SetCustomHeadersForHSTS(aSession:TIWApplication);
type
  TCustomHeader=
  record
    Key   ,
    Value : UnicodeString;
  end;
const
  CustomHeaders : array[1..5] of TCustomHeader =
  (
  (Key:'Strict-Transport-Security' ; Value:'max-age=31536000; includeSubDomains'),
  (Key:'Pragma'                    ; Value:'no-cache'),
  (Key:'Cache-Control'             ; Value:'no-cache, no-store, must-revalidate, private'),
  (Key:'X-Content-Type-Options'    ; Value:'nosniff'),
  (Key:'X-XSS-Protection'          ; Value:'1; mode=block')
  );
var
  iHeaders : Integer;
begin
  aSession.Response.Expires             := EncodeDate(1000,1,1);//31/12/1899 00:00:00;
  aSession.Response.AllowCaching        := False;
  aSession.Response.CacheControlEnabled := False;
  for iHeaders:=Low(CustomHeaders) to High(CustomHeaders) do
  begin
    if CustomHeaders[iHeaders].Value<>'' then
    begin
      aSession.Response.Headers.Values[CustomHeaders[iHeaders].Key] := ' '+CustomHeaders[iHeaders].Value;
    end;
  end;
end;

If you test our web application with SSL Labs, it has always (since we first implemented this) recognized that we use HTTP Strict Transport Security and given us an A+ rating. This leads to a number of questions:

  1. Is it sufficient to set these all these headers at the beginning of an IW session (which would imply that the tester's conclusion is wrong)?
  2. Or should one or more of these headers be set for every response?
  3. If Yes on 2, which are the appropriate ServerController properties and event(s) to use? Example code?
  4. For the fourth header, Content Security Policy, the tester writes the following: "Content Security Policy requires careful tuning and precise definition of the policy. If enabled, CSP has significant impact on the way the browser renders pages (e.g., inline JavaScript is disabled by default and must be explicitly allowed in the policy). CSP prevents a wide range of attacks, including Cross-Site Scripting and other Cross-Site injections.". They recommend using this if this does not interfere with the application, and gives an example header like this: "Content-Security-Policy: default-src 'self'". What is the consequence of using this in an IntraWeb application? I it something we should attempt?

I would be much grateful for feedback on this. The tester regard this as a Medium severity finding that we need to fix in the near future.
 
Best regards

Magnus Oskarsson
Reply
#2
Hi Magnus. I have suggestions to you add in your headers:
Code:
Referrer-Policy  ->  same-origin
Strict-Transport-Security  ->  max-age=15768000; includeSubDomains; preload
X-Content-Type-Options  ->  nosniff
X-Permitted-Cross-Domain-Policies  ->  master-only
X-XSS-Protection  ->  1; mode=block
Now, i suggest you be careful and test all your application running all forms with console opened.
Code:
Content-Security-Policy  ->  default-src 'self' https: 'unsafe-inline' 'unsafe-eval'; img-src 'self' https: data:; object-src https 'self'; media-src 'self' https:; style-src 'self' https: 'unsafe-inline'; script-src 'self' https: 'unsafe-inline' 'unsafe-eval'; frame-ancestors https: 'self' *.facebook.com; base-uri 'self' https:
This is working FOR ME, make all your adjustment for your needs.
Reply
#3
Hi Jose and thanks for sharing your thoughts on this! There is more here for me to look into I see. But it does not explicitly answer my four questions, so it would still be great to have feedback on that (from you or other forum members).

Best regards

Magnus Oskarsson
Reply
#4
What IW version are you using? CSP is a lot of "feel good nonsense" in many areas, but 15.1 has been updated to be CSP compliant.

https://www.atozed.com/2019/07/15-1-0-h/

Content Security Policy (CSP) support. Read more about CSP here. https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
Good part of the rendering engine was refactored to remove inline JavaScript, CSS and unsafe code (according to CSP best practices). A nonce is now included in all scripts/link files.

Cross-Origin Resource Sharing (CORS) support. Read more about CORS here: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)