Jump to content
Sign in to follow this  
lynkfs

Site security and http response headers

Recommended Posts

I recently had a look at Scott Helme's site, https://securityheaders.io

 

Scott is involved in information security and his site explains in great detail how to enhance site security by means of http response headers.

 

Quoted :

"HTTP Response headers are name-value pairs of strings sent back from a server with the content you requested. They are typically used to transfer technical information like how a browser should cache content, what type of content it is, the software running on the server and much, much more. Increasingly, HTTP Response headers have been used to transmit security policies to the browser. By passing security policies back to the client in this fashion, hosts can ensure a much safer browsing experience for their visitors and also reduce the risk for everyone involved. Let's take a look at some more security based headers.

 

The first step in hardening your HTTP response headers is looking at the additional headers you can utilise to make your site more secure. Outlined below, these headers give the browser more information about how you want it to behave with regards to your site. They can be used to deliver security policies, set configuration options and disable features of the browser you don't want enabled for your site. Once you have setup each header, check it using SecurityHeaders.io."

 

His site features a facility to scan any domain, giving back information on which headers to check.

 

So I scanned a standard SMS project output (Visual Component Projects). The results indicated to add security policies by including the following headers :

 

- Content-Security-Policy 

- X-Frame-Options 

- X-XSS-Protection 

- X-Content-Type-Options

 

The first (Content-Security-Policy) can prevent the browser to load malicious assets by white-listing what is permissible and what is not.

The second (X-Frame-Options) can be used to prevent click-jacking by disallowing your website to be framed.

The third (X-XSS-Protection) can be used to properly configure the browsers built-in security function (reflective XSS protection)

The last (X-Content-Type-Options) reduces exposure to drive-by downloads and the risks of user uploaded content that, with clever naming, could be treated as for instance an executable.

 

Sounds all pretty good to me.

 

The Content-Security-Policy (CSP) is probably the most important. It also comes with a heap of options and the list of permissable resources can be left wide open or screwed down to zero and everything in between.

 

Experimenting a bit I settled on

 



<meta http-equiv="Content-Security-Policy"
      content="default-src 'none';
               script-src  'self' 'unsafe-inline';
               style-src   'self' http://yourdomain;
               img-src     'self' http://yourdomain;">


 

The first line is the default for 'nothing is permitted'. This will stop the browser from downloading any script, any font, any image, any css file etc. The following lines override this behavious somewhat.

 

The second line handles scripts. The self parameter means that scripts in the same directory as the index file are permissable.

Depending on your project linker options either the js is included inline in the html file or a separate 'main'js' file is created which is referenced from the html file (<script type="text/javascript" src="main.js"></script>)

The latter is preferred anyway, using inline JS or CSS is considered unsafe as it provides at least an opening for attackers to inject script into a page.

Unfortunately the 'external scriptfile' linker option still leaves a small bit of inline js in the html file :

 



        <script type="text/javascript"> /* This prevents the window being moved by touches,
 to give the impression of a native app */
document.ontouchmove = function(e) { e.preventDefault(); }
 </script>


 

Would be better to include this in the external file as well.

For now in both linker options the keyword 'unsafe-inline' is required

 

The third and fourth line handle css-files and images. Since usually the styling info is in a subdirectory (res/app.css) and the images are in a subdirectory as well, the domain must be specified.

 

There are additional parameters to handle for instance http-requests, permissions for audio and video handling and more.

 

 

The other 3 response headers are valid for all servers but the syntax is slightly dependant on server-type. 

For nginx servers I believe the following headers are valid :

 



<meta http-equiv="X-Frame-Options" content="'SAMEORIGIN'">
<meta http-equiv="X-Xss-Protection" content="'1; mode=block' always">
<meta http-equiv="X-Content-Type-Options" content="'nosniff' always">


 

just include these meta tags in the header section of the default.html file in the Templates sub-directory prior to compile and link.

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...