Security headers you should add into your application to increase cyber risk protection

Published: 2023-04-06
Last Updated: 2023-04-06 21:02:14 UTC
by Manuel Humberto Santander Pelaez (Version: 1)
1 comment(s)

Web applications are a wide world that is currently the object of numerous cyberattacks, mostly seeking to compromise the information directly in the clients that use them.

Considering the shortage of programmers, most of them are looking to finish the developments that are requested in the shortest periods of time. Although development frameworks carry out some default protection for attacks such as SQL Injection, the same is not the case for other types of attacks. I have been able to demonstrate the framework's default security protections in multiple developments, which opens up vulnerable scenarios as the ones described.other scenarios such as man-in-the-middle attacks (MITM), cross-site scripting and cross-site injections.

Modern browsers understand instructions from web browsers through headers, allowing control of many easily preventable vulnerabilities. Let's review the ones I have found to be essential-security controls in the web server to support application security:

HTTP Strict Transport Security

Why am I telling people to have this header in an age of web connections that should only be encrypted? Default configurations for plain HTTP port are still a thing and you can find web servers accepting plain HTTP connections. A quick shodan search shows the following:

This header has two main purposes: to prevent protocol degradation as the browser is instructed to only perform HTTPS connections to the server using plain HTTP and therefore avoiding MITM attacks. It can be checked as follows:

If you don't get any otput after this check, you should configure the header. If you are using apache, this will work for you. If you are using Internet Information Server, this will work for you.

Content-Security-Policy

This header is important as it can control attacks like cross-site-scripting, cross-site-injection and clickjacking. Some of the essential parameters to configure are:

base-uri Define the base URI for relative URIs.
default-src Define loading policy for all resources type in case a resource type’s dedicated directive is not defined (fallback).
script-src Define which scripts the protected resource can execute.
object-src Define from where the protected resource can load plugins.
style-src Define which styles (CSS) can be applied to the protected resource.
img-src Define from where the protected resource can load images.
media-src Define from where the protected resource can load video and audio.
child-src Define from where the protected resource can embed frames.
frame-ancestors Define from where the protected resource can be embedded in frames.
font-src Define from where the protected resource can load fonts.
connect-src Define which URIs the protected resource can load using script interfaces.
manifest-src Define from where the protected resource can load manifests.
form-action Define which URIs can be used as the action of HTML form elements.
sandbox Specifies an HTML sandbox policy that the user agent applies to the protected resource.
script-nonce Define script execution by requiring the presence of the specified nonce on script elements.
plugin-types Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded.
reflected-xss Instruct the user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header.
block-all-mixed-content Prevent the user agent from loading mixed content.
upgrade-insecure-requests Instruct the user agent to download insecure HTTP resources using HTTPS.

It can be checked as follows:

If you don't get any otput after this check, you should configure the header. If you are using apache or Internet Information Server, this will work for you. Please keep in mind that this header is tricky and you need to have a detailed information flow between all your components to make sure you set a corrent policy that does not break any functionality. 

Access-Control-Allow-Origin

What happens if a domain B is hacked and the scripts loaded to a client wants to access resources from domain A? 

You can use this header to make sure the resources are being used only from a specific origin and therefore avoid possible cross-site attacks from untrusted domains.

It can be checked as follows:

If you don't get any otput after this check, you should configure the header. If you are using apache, this will work for you. If you are using Internet Information Server, this will work for you.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter: @manuelsantander
Mastodon:manuelsantander@infosec.exchange
email:msantand@isc.sans.org

Keywords:
1 comment(s)

Comments

There are probabably also other HTTP response headers which should be considered. Since I keep forgetting things I usually look at Scott Helme's https://securityheaders.com/ - I need only to rememeber few keywords to be able to search for his page :)

I really like your's CSP example, it somehow shows how hard is to design/maintain CSP header :)


Diary Archives