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:

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