- SOC2 Compliance for Startups - 06/01/2020
- Fundamentals Of HTTP Headers And Web Application Security - 03/01/2020
- Basics Of IoT Security Threat Modelling - 03/01/2020
Fundamentals of HTTP Headers and Web Application Security
The notorious targets for all sorts of cyber attacks can be zeroed down to the web applications. The increasing pattern of cyber attacks has led us, to not just inculcate cyber security as a luxury, rather as a necessity for all the web developers and above all for those developers who are responsible for building the consumer-facing applications. In hand with the above fact, it is also true enough that as and when the world is becoming more and more interconnected, along with rise of online services there is also rise in personal and sensitive data being created in tones. All such changes give in to more vulnerabilities and risks which the cyber criminals easily exploit through techniques such as, cross-site scripting, man-in-the-middle attacks, cross-site request forgery, clickjacking, etc.
There are many things to consider while thinking about securing our web applications or sites, but a rather good place would be to start with the exploration and implementation of HTTP security headers that put in an extra layer of security. So, in order to tighten up the security of web applications, the HTTP headers can be put to leverage by just incorporating few lines of code which help in balancing both usability as well as security. These HTTP headers help prevent the modern browsers from encountering all sorts of vulnerabilities. Speaking in technical terms, the HTTP headers are just simple fields which are encoded in clear text and are said to be part of the request as well as response message headers in HTTP. Their design is such that they cause enablement of both HTTP server as well as client in order to have exchange of metadata based on parameters such as, connection that has to be established, resource that is being requested and resource that is being returned.
At times when a user wants to access a certain specific page from a server, the server in turn provides the response by giving the required content along with the response headers of HTTP which carry metadata such as status error codes, cache-control, etc. Now, a huge part of such headers are termed as security headers that provide instructions to the browsers about how it should behave while handling our website’s data as well as content. They play a major part in protecting us from threats and attacks such as, clickjacking, XSS, compromised website resources, drive-by-downloads, passive eavesdropping, compromised certificates, information disclosure to name a few. To wrap it all up it can be rightly put that these security centric headers help in empowering our browsers in making smarter decisions for the users.
⦁ X-XSS-Protection
It is a HTTP response header. This is characteristic of Internet Explorer, Chrome and Safari. Whenever there seems to be a chance of reflected XSS attacks or detection of such attacks, the browsers stop the loading of pages. This header provides a means of protection to the users who still use old browsers what lack privileges of having CSP (Content-Security-Policy) header.
Syntax:
X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=
The permitted sets of directives under this header are as follows;
0
This syntax indicates that we are disabling the XSS filtering.
1
This syntax would enable the XSS filtering privileges. This is found to be default in browsers. The browser would sanitize the pages if there is any detection of XSS attacks.
1; mode=block
This syntax would enable the XSS filtering privileges. But instead of sanitizing the pages, the browser would prevent the pages from loading if any attack is detected.
1; report=
This syntax would help XSS filtering possible. When there is any XSS attack detected, the browser would sanitize the pages thereby reporting the attack.
Example:
The syntax below blocks pages from loading when reflected XSS attacks are detected:
X-XSS-Protection: 1; mode=block
In PHP;
header(“X-XSS-Protection: 1; mode=block”);
In Nginx;
add_header “X-XSS-Protection” “1; mode=block”;
⦁ WWW-Authenticate
It is a HTTP response header that helps in defining the authentication method which must be used so as to gain access to a resource.
This header is sent along with a “401 Unauthorized” response status code.
Syntax:
WWW-Authenticate:
The permitted sets of directives under this header are as follows;
The most common authentication type is Basic. Other authentication schemes maintained by IANA are; Bearer, Digest, HOBA, Mutual, Negotiate, OAuth, SCRAM-SHA-1, SCRAM-SHA-256 and vapid.
realm=
It provides a description of the area that needs to be protected.
charset=
It tells the client about the server’s preferred encoding scheme while submitting a username and password. Here, the only allowed value is “UTF-8″ which is a case insensitive string. This by no means is related to the encoding of the realm string.
Examples:
A server response typically contains a “WWW-Authenticate” header that looks like the below:
WWW-Authenticate: Basic
WWW-Authenticate: Basic realm=”Access to the staging site”, charset=”UTF-8″
⦁ Authorization
This is a HTTP request header that contains the credentials in order to authenticate a user with a server. It usually happens after the server has responded with “401 Unauthorized” status and the WWW-Authenticate header.
Syntax:
Authorization:
The directives permitted under this header are as follows;
The common one is Basic. Other authentication schemes maintained by IANA are; Bearer, Digest, HOBA, Mutual, Negotiate, OAuth, SCRAM-SHA-1, SCRAM-SHA-256 and vapid.
If the authentication type is Basic then the credentials is provided as;
Username:Password
Example; root:toor
Example:
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
⦁ Proxy-Authenticate
It is a HTTP response header that defines the authentication method which should be employed so as to gain access to a resource behind a proxy server. It helps authenticate the request to the proxy server, thereby allowing it to transmit the request further.
This header is sent along with a “407 Proxy Authentication Required” status code.
Syntax:
Proxy-Authenticate:
The directives permitted under this header are as follows;
The most common authentication type is Basic. Other authentication schemes maintained by IANA are; Bearer, Digest, HOBA, Mutual, Negotiate, OAuth, SCRAM-SHA-1, SCRAM-SHA-256 and vapid.
realm=
It provides a description of the area that needs to be protected.
Examples:
Proxy-Authenticate: Basic
Proxy-Authenticate: Basic realm=”Access to the internal site”
⦁ Proxy-Authorization
It is a HTTP request header that contains the credentials so as to authenticate a user to a proxy server. It happens usually after the server has responded with a 407 Proxy Authentication Required status and the Proxy-Authenticate header.
Syntax:
Proxy-Authorization:
The directives permitted under this header are as follows;
The common one is Basic. Other authentication schemes maintained by IANA are; Bearer, Digest, HOBA, Mutual, Negotiate, OAuth, SCRAM-SHA-1, SCRAM-SHA-256 and vapid.
If the authentication type is Basic then the credentials is provided as;
Username:Password
Example; root:toor
Example:
Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
⦁ Content-Security-Policy(CSP)
It is a response header that allows all the website administrators to control resources that the user is allowed to load for a given page. With a very few exceptions, policies in most cases involve specifying the server origins and the script endpoints, which helps guard against XSS attacks.
Syntax:
Content-Security-Policy:
The first category is the “Fetch directives” that help in controlling locations from which few of the resource types may be loaded. These directives constitute connect-src, default-src, font-src, frame-src, img-src, manifest-src, media-src, object-src, script-src, style-src and worker-src.
The second category is the “Document Directives” that help in governing the properties of a document or worker environment to which a policy applies. These directives include base-uri, plugin-types and sandbox.
The third category is the “Navigation directives” that help in governing that to which location a user can possibly navigate to or be able to submit a form to (for example). It consists of form-action and frame-ancestors.
Other directives are block-all-mixed-content, require-sri-for and upgrade-insecure-requests.
Examples:
Disabling unsafe inline/eval and only allowing loading of resources (such as; images, fonts, scripts, etc.) over https:
// header
Content-Security-Policy: default-src https:
// meta tag
Not implementing the above policy yet; rather reporting violations that would have occurred:
Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/
⦁ Content-Security-Policy-Report-Only
This is a response header which allows web developers to experiment with policies by monitoring (and not enforcing) their effects. These all violation reports consist of JSON documents sent through a HTTP POST request to the specified URI.
Syntax:
Content-Security-Policy-Report-Only:
Examples:
This header would help to report the various violations that have taken place. It helps us observe how our site behaves or responds, looking into the various reports regarding violations and then choosing the appropriate policy that would be applied by CSP header.
Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/
But let’s say we want to get the reports as well as enforce the policy, then we use CSP header along with report-uri directive such as;
Content-Security-Policy: default-src https:; report-uri /csp-violation-report-endpoint/
Violation Report Syntax:
The report JSON object constitutes the following data such as; blocked-uri, disposition, document-uri, effective-directive, original-policy, referrer, script-sample, status-code and violated-directive.
⦁ Public-Key-Pins
This is a response header that associates a specific kind of cryptographic public key with a certain web server so as to decrease the risk of MITM attacks by implementing forged certificates. If for example, one or several keys are pinned and none of them are used by the server, the browser will not by any means accept the response as legitimate, and will thereby not display it.
Public-Key-Pins: pin-sha256=”
max-age=
includeSubDomains;
report-uri=”
The various directives that are permitted under this header are as follows;
pin-sha256=”
The term “pin-value” is the Base64 encoded Subject Public Key Information (SPKI) fingerprint. Multiple pins can be specified for different public keys.
max-age=
This provides the time in seconds, that the browser should remember that this site is only to be accessed using one of the defined keys.
includeSubDomains (Optional)
If this parameter is put to use, the rule would be applied to all of the site’s subdomains too.
report-uri=”
If this parameter is used, then pin validation failures would be reported to the specified URL.
Example:
Public-Key-Pins:
pin-sha256=”cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs=”;
pin-sha256=”M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE=”;
max-age=5184000; includeSubDomains;
report-uri=”https://www.example.org/hpkp-report”
⦁ Strict-Transport-Security
It is a HTTP response header (often written as HSTS) that allows a website inform browsers that it should only be accessed using HTTPS rather than using HTTP.
Syntax:
Strict-Transport-Security: max-age=
Strict-Transport-Security: max-age=
Strict-Transport-Security: max-age=
The permitted sets of directives used under this header are as follows;
max-age=
This is the time in seconds format, that the browser should remember that a website is only to be accessed using HTTPS.
includeSubDomains (Optional)
If this parameter is put to use, then the rule would be applied to all of the site’s subdomains as well.
preload (Optional)
It is not a part of HSTS specification and by no means be considered as official.
Description:
When a website accepts a connection with the use of HTTP and redirects to HTTPS, chances are the users may initially communicate with the non-encrypted version of the website before being redirected to the safer version. For example, the user types in http://www.foo.com/ or may be just foo.com. This would create a chance for a man-in-the-middle attack. The redirect that takes place could be exploited to direct the users to a malicious site rather than redirecting them to the secure version of the former website.
The HTTP Strict Transport Security header provides direction to the browser by informing that it should never load or render a website using HTTP. It should automatically convert all attempts made to access the website using HTTP to HTTPS requests instead.
Example Case:
We log into a free WiFi access point facility at an airport and start using it by surfing through the web, while visiting our online banking service in order to check our balance or let’s suppose to pay a couple of bills. But, let’s assume unfortunately the access point we are using is in reality a hacker’s laptop, and he/she is intercepting our original HTTP request and thereby redirecting us to a lookalike or clone of our bank’s website rather than the original deal. So, now our private data gets exposed to the hacker.
Strict Transport Security helps resolve this issue. That is, if we have accessed our bank’s website once using HTTPS, and the bank’s web site uses Strict Transport Security, our browser would know to automatically use only HTTPS, which would prevent hackers from performing man-in-the-middle attack.
How the browser handles it
When for the first time our website is accessing with the use of HTTPS, it returns the Strict-Transport-Security header, which the browser records, so that the future attempts made to load the website using HTTP will automatically use HTTPS instead.
On expiration of the allotted time as specified by Strict-Transport-Security header, the next request made to render the website through HTTP will commence as normal instead of automatically using HTTPS.
Whenever the header is delivered to the browser, it would update the expiration time for that website. So, websites can refresh this received information and prevent the timeout from expiring. In order to disable Strict Transport Security, setting the max-age to 0 would immediately expire the Strict-Transport-Security header, thereby allowing access via HTTP.
Example:
Strict-Transport-Security: max-age=31536000; includeSubDomains
All pages and sub-domains would be loaded when used via HTTPS for duration of 1 year. The pages demanding access via HTTP would be prevented.
⦁ X-Content-Type-Options
This is a response HTTP header which is used as a marker by the server in order to indicate that the MIME types which are advertised in the Content-Type headers should not be changed and be followed. This header allows to opt-out of MIME type sniffing.
This header came into existence when it was introduced by Microsoft in IE 8 as a way for webmasters so as to block content sniffing that was taking place and could transform non-executable MIME types into executable ones. Other browsers also started introducing it since then, even if their MIME sniffing algorithms were less aggressive.
The site security testers mostly expect this header to be set.
On using this header we can prevent the browser from interpreting files as something else than declared by the content type in the HTTP headers.
Syntax:
X-Content-Type-Options: nosniff
This value “nosniff” will prevent the browser from MIME-sniffing a response away from the declared content-type.
The directive under this header is;
nosniff
This helps in blocking a request if the requested type is;
⦁ “style” and the MIME type is not “text/css”, or
⦁ “script” and the MIME type is not a ⦁ JavaScript MIME type.
⦁ X-Frame-Options
It is a HTTP response header. It is helpful in indicating whether or not a web browser should be allowed to render or load a page in a ,