HTTP security principles
HTTP GET and POST Requests: Overview
1. HTTP introduction:
By the majority of back- and frontend developers, the HTTP protocol is treated like a black box that enables some useful, though limited, functionality in their projects, for example, allows their application to communicate with the server.
But HTTP protocol has a lot of security controls against non-HTTP-protocol related vulnerabilities like XSS, Clickjacking, Man-In-The-Middle, which could help developers protect their web applications if used properly.
In our HTTP Primer lessons, we will present essential concepts on which the functioning of the HTTP protocol is based. Those lessons will give you a solid understanding of how the HTTP Protocol works before we proceed to the discussion of more complex topics on HTTP-related vulnerabilities and security controls that the protocol provides.
2. MAIN PURPOSE OF THE HTTP PROTOCOL [OSI Model]
According to RFC 7230, the Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. It was defined almost 30 years ago and became the foundation of the Internet.
HTTP resides on the application layer of the ISO OSI model (described in ISO/IEC 7498-1 standard). There are seven layers in the ISO OSI model and each one has its own role in the transmission of data from the client to the server.
As an application layer protocol, HTTP provides the definition of how to transfer the data formatted as hypertext between different locations on the Internet. The data formatted in a way the HTTP protocol dictates is transformed all the way down to the Physical level on a sender side and then does it back to the top on a receiver side.
When data is sent, the protocol on every layer appends additional data to it so that the original data can be transferred and reconstructed on the receiver side.
3. REQUEST-RESPONSE EXPLANATION
HTTP is a client-server protocol meaning that the client side sends a request and receives a response from the server side. In addition, there are intermediate devices that can read or manipulate requests and responses (e.g. on the Application Layer there can be filtering devices like antiviruses or Web Application Firewalls, load balancers, caches and so on).
A user sends requests to the server through the user-agent: a browser or any kind of program designed for communication with a particular server.
In the request, user-agent defines what web page it wants to receive from the server.
Web server either serves a static page or dynamically generates it and serves to the user.
A web page is a document written in HyperText Markup Language (HTML) that is usually accompanied by styles and scripts that make it look better. Scripts on the web page may retrieve additional data that is used to update the web page.
Alternatively, a server can respond with formatted data (JSON, XML, etc) that is further displayed in the user-agent application.
HTTP Security Headers
1. INTRODUCTION
There is a number of HTTP response headers that you should use to increase the security of your web application. They are referred to as HTTP security headers.
Once implemented, HTTP security headers restrict modern browsers from running into easily preventable vulnerabilities. They also provide yet another, additional layer of security by helping to mitigate security vulnerabilities and prevent attacks (like XSS, Clickjacking, information leakage, etc.). But it is important to mention that HTTP security headers are not intended to replace proper, secure code.
​
2. HTTP STRICT TRANSPORT SECURITY
HTTP Strict Transport Security (HSTS) is a mechanism that prevents user-agents (a browser or any kind of program designed for communication with a particular server) from browsing a website via an unencrypted connection in case an encrypted connection can be established, and only using a trusted certificate.
If the request is communicated through an unencrypted channel, it can be captured and tampered with by an attacker. The attacker then can steal or modify any information transmitted between the client and the server or redirect the user to a phishing website. So, the first goal of HSTS is to ensure traffic is encrypted, so it instructs the browser to always use HTTPS instead of HTTP.
Usually, browsers allow users to ignore TLS errors and continue browsing potentially insecure websites. With HSTS enabled, the user will be unable to skip the browser warning and continue. The second important goal of HSTS is to make sure that the traffic is encrypted using a trusted and valid certificate.
In the right pane, you can see a screenshot with the error that the user gets when the certificate of the target website is no longer valid (note that the user is unable to proceed to the target website).
3. HTTP STRICT TRANSPORT SECURITY
When HSTS response header signals the browser that the certain domain must be requested only using HTTPS, the browser saves this domain to the HSTS list and keeps it there for the timeframe specified in max-age directive of the Strict-Transport-Security header.
There are two cases when HSTS doesn’t provide proper protection:
when the user hasn’t browsed to the website before and is making his very first request to this website over HTTP,
when existing HSTS data has already expired.
To resolve this, it is possible to have a domain included in the HSTS preload list which arrives baked into most modern browsers.
(Note that enabling HSTS and adding a domain to the HSTS preload list must be tested beforehand. A mistake in HSTS and TLS configuration may lead to a denial of service.)
In the right pane, you can see a screenshot of the webpage with HSTS settings for Google Chrome browser.
4. X-XSS-PROTECTION
Some modern browsers have built-in XSS protection mechanisms that can be used as an additional layer of security against Reflected XSS. The main problem with that is that all of the browsers implement built-in XSS filtering differently, so to add more control to the process and make sure that the loading of a page with the malicious content will be blocked, the X-XSS-Protection header is needed.
X-XSS-Protection header is an optional HTTP header that performs XSS filtering by defining the anti-XSS mechanism behavior: from sanitizing the page by blocking injected Javascript to preventing page rendering and reporting the violation.
By default, browsers that support XSS filtering have it enabled. Though it can be disabled, this is considered a bad practice; often, if an application requires XSS protection to be disabled in order to function properly, it is an indication that the application is quite likely vulnerable to XSS.
Please note that only using the X-XSS-Protection header will not protect your application from XSS, but this header will make an important input in your defense-in-depth strategy and make it more robust.