Make your app safer with HTTP Security Policy

The World Wide Web is changing, users don’t realise but web protocols are improving a lot. We are moving the web from TCP to UDP for faster communications, we can use Multipath TCP and HTTP/2 for better performance and security, and we also have increasingly better Web Services and WebSockets thanks to HTML5. Therefore, I’m going to write about some security mechanisms to protect websites because, although I’m not a developer, I think it’s important to known how next generation protocols work to protect our services and the company we are working for.

The first and most used security mechanism by main webservers is HSTS or HTTP Strict Transport Security. This is an HTTP header sent from web servers to clients, for instance browsers, to ask them to use HTTPS instead of HTTP for a period of time specified by the “max-age” attribute. Consequently, HTTP can be used for the first access from clients to websites but HTTPS is used thereafter and the change from HTTP to HTTPS will be done natively by clients instead of redirections by web servers. However, the first HTTP connection can be used by attackers that along with a MITM attack and SSL Strip attack the confidentiality can be compromised. As a result, browsers have a preload list with websites which should be accessed by HTTPS even in the first connection. However, the preload list mechanism is not scalable because all websites can’t fit into only one list thus DNSSEC could be the solution.

HTTP Strict Transport Security

 

Another security mechanism delivered via an HTTP header is HPKP or HTTP Public Key Pinning. This security feature is used by few sites and even we could say it’s nearly dead because Chrome has already announced their plans to deprecate and remove support for HPKP. This is a security protocol to prevent fraudulently issued TLS certificates from being used to impersonate existing secure websites.

HTTP Public Key Pinning

 

CSP or Content Security Policy is another security mechanism to prevent XSS and data injection attacks. This security standard is implemented in web servers and the security policy is delivered via an HTTP header, like HPKP and HSTS, to browsers. The aim of the security policy is to tell browsers what are the trustworthy source content to prevent code execution by malicious scripts into victim’s browser.

Content Security Policy

There are many tools to help us to know which websites are properly secured. For instance, HSTS Preload List Submission is a website where we can enter a domain to check if that domain is preload into main browsers, and even we can submit our own domain to be inside into the preload list. Another interesting tool is securityheaders.io where we can analyse HTTP response headers to know if the web server is protected with security headers like “Strict-Transport-Security”, “Content-Security-Policy”, “X-Content-Type-Options”, etc. On the other hand, if we want to know which websites we have visited with HSTS or HPKP, we can install the Pin Patrol plugin into our browser.

Analyse HTTP response headers

 

These are some of the security mechanism we have to take into account when we are protecting web servers and users. For example, it’s too important to know how HSTS works when we are configuring SSL inspection in a firewall to make exceptions and allow websites which are configured with this security feature.

Regards my friends and keep protecting your web servers!!!