Red Zone Area

Go to content
Hacker

Security Headers
Some 'sets' that could save the 'system'
Red Zone Area | April 2021


HTTP security headers are a fundamental part of website security. Upon implementation, they protect you against the different types of attacks that your site is most likely to come across. These headers protect against XSS, code injection, clickjacking, etc.. They should be used to pass additional information between the clients and the server through the request and response headers.

There are four kinds of headers context-wise:

  • General Header: This type of headers applied on Request and Response headers.
  • Request Header: This type of headers contains information about the fetched request by the client.
  • Response Header: This type of headers contains the location of the source that has been requested by the client.
  • Entity Header: This type of headers contains the information about the body of the resources like MIME type, Content-length.

Headers can also be categorized according to how proxies handle them like Connection, Keep-Alive, Proxy-Authenticate, Proxy-Authorization, TE, Trailer, Transfer-Encoding, and others many cases where headers could help you properlyi handling security, caching, client hints, conditionals, Connections, etc. More than useful!!
All the headers are case-insensitive, headers fields are separated by colon, key-value pairs in clear-text string format and we will share here some tips for you all.
Enjoy!
header
How to do it or that?
This session is dedicated to explain, share and spread ideas, tricks, tips about security
NEWS
We keep a blog updated with leaks, failures, attacks, tips and much more about security world. Take a look...
TALK to us
Questions, doubts, curiosities....anything that need cyber security, talk to us.
NEED more info...
The best REVIEWS are available here. Take a time for yourself and check it out...
Transfer-Encoding Strict-Transport-Security X-Frame-Options X-XSS-Protection X-Content-Type-Options Set-Cookie
The HTTP Transfer-Encoding is a response-type header  that performs as the hop-by-hop header, the hop-by-hop header connection  is the single transport-level connection must not be re-transmitted.  This header is performing between two nodes (single transport and level  connection).

Syntax:
Transfer-Encoding: chunked | compress | deflate | gzip | identity

Directives:
This header accepts five directives mentioned above and described below:

  • chunked:  This directive is used to send the series of data in a chunk format,  but have to mentioned the length of each chunk before sending the chunk  of the data in hexadecimal format like '\r\n' and then the chunk itself, followed by another '\r\n'.
  • compress: It is a compression format using the Lempel-Ziv-Welch (LZW) algorithm.
  • deflate: It is a compression format using the zlib structure, with the deflate compression algorithm.
  • gzip: It is a compression format using the Lempel-Ziv coding (LZ77), with a 32-bit CRC.
  • identity: This directive Indicates the identity function which is always acceptable

Example: The chunk encoding for this header is useful  when the server sending the huge amount of series of data to the client.  The total size of the response may be unknown until the request has  been completed.

Supported Browsers:
The browsers are compatible with HTTP Transfer-Encoding header are listed below:

  • Google Chrome
  • Internet Explorer
  • Firefox
  • Safari
  • Opera
HTTP Strict Transport Security (HSTS) is a web  security policy mechanism that helps protect websites from malicious  activities and informs user agents and web browsers how to handle its  connection through a response header. Whenever a website connects  through HTTP and then redirects to HTTPS, an opportunity for a  man-in-the-middle attack is created and the redirect can lead the users  to a malicious website because users first have to communicate with the  non-encrypted version of the website. A server implements the HSTS  policy by supplying a header over an HTTPS connection which informs the  browser to load a site using HTTPS rather than HTTP.

Syntax:
Strict-Transport-Security: max-age=<expire-time>
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
Strict-Transport-Security: max-age=<expire-time>; preload

Directives:
  • <expire-time>:  This mentions the time in seconds for which the user agent or browser  should only access the server in a secure fashion by using HTTP.
  • includeSubDomains: This directs the browser to apply the rule to all pages and sub-domains of the site as well.
  • preload: This is necessary for inclusion in most major web browsers’ HSTS preload lists.

Examples:
Strict-Transport-Security: max-age=3600; includeSubDomains
All pages and subdomains will be HTTPS for a max-age of 1 hour. This blocks access to pages or sub domains that cannot be served over HTTPS.

Supported Browsers: The following browsers are compatible with HTTP Strict-Transport-Security.
  • Google Chrome 4.0
  • Internet Explorer 11.0
  • Firefox 4.0
  • Safari 7.0
  • Opera 12.0
HTTP headers are used to pass additional information with HTTP response or HTTP requests. The X-Frame-Options is used to prevent the site from clickjacking attacks. It defines whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>. The frame-ancestors directive present in Content-Security-Policy(CSP) obsoletes X-Frame-Options.

Syntax:
X-Frame-Options: deny | sameorigin | allow-from url

Directives:
  • deny: This directive stops the site from being rendered in <frame> i.e. site can’t be embedded into other sites.
  • sameorigin: This directive allows the page to be rendered in the frame iff frame has the same origin as the page.
  • allow-from uri:  This directive has now became obsolete and shouldn’t be used. It is not  supported by modern browser. In this the page can be rendered in the <frame> that is originated from specified uri.

Examples:
  • On Apache:
    To send the X-Frame-Options to all the pages of same originis, set this to your site’s configuration.
 Header always set X-Frame-Options "sameorigin"
 Open httpd.conf file and add the following code to deny the permission
 Header always set x-frame-options "DENY"

  • On Nginx:
    Open the server configuration file and add the following code to allow only from same origin
 add_header x-frame-options "SAMEORIGIN" always;

Supported Browsers: The borwsers supoorted by X-Frame-Options are listed below:
  • Chrome
  • Internet Explorer
  • Safari
  • Firefox
  • Edge
Note: Only Internet Explorer and Microsoft Edge supports the allow-from directive.
The X-XSS-Protection in HTTP header is a  feature that stops a page from loading when it detects XSS attacks. This  feature is becoming unnecessary with increasing content-security-policy  of sites.
XSS attacks: The XSS stands for Cross-site Scripting. In this attack, the procedure is to bypass the  Same-origin policy into vulnerable web applications. When the HTML code  generated dynamically and the user input is not sanitized only then the  attacker can use this attack. In this attack, an attacker can insert his  own HTML code into the webpage which will be not detected by the  browsers. For his own HTML code attacker can easily gain access to the  database and the cookies. To stop this kind of attacks X-XSS Protection  was used in previous days.

Type of XSS Attack: Cross site scripting attacks are broadly classified into two categories.
  • Server XSS:  In this type of attack hacker attaches untrusted data with the HTML  response. In this case, vulnerability is present at the server end and  the browser just runs the script present in the response.
  • Client XSS:  In this type of XSS attack unsafe javascript is used to update the DOM  data. If we add javascript code in DOM with a javascript call, such a  javascript call is called an unsafe javascript call.

Syntax:
X-XSS-Protection: 0 | 1 | 1;mode=block | 1;report=<reporting url>

Directives: In this headers filed there are four directives:
  • 0: It disables the X-XSS-Protection.
  • 1: It is the by default directive and enables the X-XSS-Protection.
  • 1; mode=block: It enables the X-XSS-Protection. If the browser detects an attack, it will not render the page.
  • 1; report=<reporting-URI>:  It enables the X-XSS-Protection. If the Cross-site SScripting attack  detected then the page will be sanitizes and reported by report-uri  directive.

Examples:
Appache server:
Header set X-XSS-Protection "1; mode=block"
Nginx server.
add_header "X-XSS-Protection" "1; mode=block";

Supported Browsers: The browsers supported by HTTP headers X-XSS-Protection are listed below:
  • Google Chrome
  • Internet Explorer
  • Safari
  • Opera
The HTTP headers X-Content-Type-Options acts as a marker that indicates the MIME-types headers in the content types headers should not be changed to the server. This header was introduced in the Internet Explorer 8 of Microsoft. This header block the content sniffing (non-executable MIME type into executable MIME type). After that, all the other browsers also introduce the X-Content-Type-Options, and their MIME sniffing algorithms were less aggressive.

Syntax:
x-content-type-options: nosniff

Directives:
There is a single directive accepted by X-Content-Type-Options header.
  • nosniff: It blcoks all request if there “style” MIME-type is not text/css and JavaScript MIME-type. Plus it enables the cross origin if there MIME-Type text/html, text/plain, text/jason, application/jason and any type of xml extension.

Example:
x-content-type-options: nosniff
To check the X-Content-Type-Options in action go to Inspect Element -> Network check the request header for x-content-type-options

Supported Browsers: The browsers compatible with x-content-type-options header are listed below:
  • Google Chrome
  • Internet Explorer
  • Firefox
  • Opera
The HTTP header Set-Cookie is a response header and used to send cookies from the server to the user agent. So the user agent can send them back to the server later so the server can detect the user.

Syntax:
Set-Cookie: <cookie-name>=<cookie-value> | Expires=<date> 
						               | Max-Age=<non-zero-digit> | Domain=<domain-value>
						               | Path=<path-value> | SameSite=Strict|Lax|none
Note: Using multiple directives are also possible.

Directives:
  • <cookie-name>=<cookie-value>: The cookie name have to avoid this character ( ) @, ; : \ ” / [ ] ? = { } plus control characters, spaces, and tabs. It can be any US-ASCII characters.
  • Expires=<date>: It is an optional directive that contains the expiry date of the cookie.
  • Max-Age=<non-zero-digit>: It contains the life span in a digit of seconds format, zero or negative value will make the cookie expired immediately.
  • Domain=<domain-value>: This directive defines the host where the cookie will be sent. It is an optional directive.
  • Path=<path-value>: This directive define a path that must exist in the requested URL, else the browser can’t send the cookie header.
  • SameSite=Strict|Lax|none: This directives providing some protection against cross-site request forgery attacks.

Examples:
  • This types cookies were removed when the user shut down the system this types of cookies known as a session cookie.
    Set-Cookie: sessionId=38afes7a8
  • Permanent cookies expire on some specific date
    set-cookie: 1P_JAR=2019-10-24-18; expires=…in=.google.com; SameSite=none
To check this Set-Cookie in action go to Inspect Element -> Network check the response header for Set-Cookie.

Supported Browsers: The browsers compatible with HTTP header Set-Cookie are listed below:
  • Google Chrome
  • Internet Explorer
  • Firefox
  • Safari
  • Opera
Wherever you're looking for
Sudo something
127.0.0.1
Want to talk to us ???
Use our Contact Page
Follow us...
Created by Superdrive
Back to content