Security headers you should add into your application to increase cyber risk protection
by Manuel Humberto Santander Pelaez (Version: 1)
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
Comments