Categories
വിവര സാങ്കേതിക വിദ്യ

HTTP — Security Headers

Headers are component of the HTTP specification, characterizing the metadata of the message in both the HTTP request and response. While the HTTP message body is often meant to be read by the user, metadata is processed solely by the web browser and has been enclosed in HTTP protocol since version 1.0.

The HTTP headers allow the client and server to exchange information how they communicate with each other.

Metadata in request messages can hold.

  • Language of the request
  • Cookies
  • Credentials for the website
  • Cache data

Metadata in response message can hold.

  • Size and type of the content
  • Cache storage preferences
  • Server data
  • Time and date
  • Credentials to be set by the client

Security headers 

This article is centered on security headers. Security headers are effective and also cost-efficient way of securing web application. It’s not the complete solution. These headers should be seen as, one more layer of protection to add thus improve upon overall security hygiene.

X-Frame-Options HTTP Header

Header which supports to protect against UI redressing attack. This header was suggested by Microsoft back in 2009 when clickjacking began to gain traction.

So, what is UI redressing? UI Redressing attacks are based on loading web pages inside an iframe and covering them with other UI elements. There are various forms of UI Redressing, such as hijacking keystrokes or extraction of content, each with its benefits for attackers.

How to prevent clickjacking attack? Clickjacking targets the user, the weakest point in security. We can use X-Frame-Options and X-XSS-Protection security headers.

X-Frame-Options: DENY | SAMEORIGIN | ALLOW-FROM URL
X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=<reporting-uri>

Read More: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

Read More: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

X-Content-Type-Options HTTP Header

This HTTP header is typically used to control the MIME Type Sniffing function in web browsers. This will prevent changing of mime type from what is advertised in Content-Type headers.

X-Content-Type-Options: nosniff

Read More: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

X-Download-Options HTTP Header

The X-Download-Options header can be used download the requested data instead of viewing it in the browser. The X-Download Options header is supported in Internet Explorer.

Content-Disposition: attachment; filename=cookietheift.html
X-Download-Options: noopen

Content Security Policy (CSP) HTTP Header

Content Security Policy gives an extra layer of security against multiple vulnerabilities such as XSS, Clickjacking, Protocol Downgrading and Frame Injection. We can define where the browser should download files needed for the site to work, And deny the rest.

Content-Security-Policy: <policy-directive>; <policy-directive>

Content-Security-Policy: script-src 'self' https://apis.google.com

Define CSP for each page set in the HTTP response. This will help to define the optimal policy for each page and its specific needs.

Read More: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

HTTP Strict Transport Security (HSTS) HTTP Header

HSTS is a mechanism that forces browsers to use a secure web connection.

Strict-Transport-Security: max-age=21576000;

max-age: This directive allows us to specify the amount of time (in seconds) that the content of the header will be stored in the browser cache. HSTS is based on Trust on First Use.

Man In the Middle, is a risk. HSTS preload list comes to the rescue.

Strict-Transport-Security: max-age=21576000; includeSubDomains; preload

Read More: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security

Read More: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security#Preloading_Strict_Transport_Security

HTTP Public Key Pinning

Certificate authorities can sign a certificate on behalf of a website without notifying the website owner!

How to Prevent Fraudulently Issued Certificates? The answer to this question is a mechanism called HTTP Public Key Pinning (HPKP). Websites can make their certificate fingerprints (hash values) known to the browsers using the Public-Key-Pins response header. Browsers store these hashes on the user’s computer. Every time the website is visited, the browser generates a hash based on the certificate’s public key. If the hash doesn’t match the stored value, the connection won’t be established, and the incident is reported to a URL if the report-uri directive is set.

Public-Key-Pins-Report-Only: 
pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=";
pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";
report-uri="http://example.com/pkp-report"; max-age=10000; includeSubDomains
Public-Key-Pins:
pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; 
pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";
report-uri="http://example.com/pkp-report"; max-age=10000; includeSubDomains

The header that will eventually replace HPKP is called Expect-CT.

Read More: https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning

Expect-CT HTTP Header

Certificate Transparency Logs; Publicly accessible and therefore administrators can check them and search for their domains. If there is a certificate issued for their domain without their prior knowledge or authorization, they can immediately take steps to protect their users.

Read More: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect-CT

How Do We Implement the Expect-CT Header?

Activate the Expect-CT header in the HTTP response.

Expect-CT: enforce,max-age=30,report-uri="https://ABSOLUTE_REPORT_URL"

Referrer-Policy HTTP Header

This header is used to improve on privacy. Anything referred from origin website should now give, referrer information to destination website. 

Referrer-Policy: no-referrer

Referrer-Policy Directives

" " (empty): 
no-referrer: 
no-referrer-when-downgrade: 
same-origin: 
origin: strict-origin: 
origin-when-cross-origin: 
strict-origin-when-cross-origin: 
unsafe-url:

Read More : https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

Security headers are HTTP response headers that define whether a set of security precautions should be activated or deactivated on the web browser. The web browser plays a major part, as that’s the OS for the web, Some browser respect certain headers some doesn’t. There are older headers and newer headers. It all depends on the browsers.

Experiment in debugging mode and don’t break your application functionality.

GiBu GeorGe