InfoSec Write-ups – Medium–
HTTP Headers : Web App Security Basics
HTTP headers let the client and the server pass additional information with an HTTP request or response. An HTTP header consists of its case-insensitive name followed by a colon, then by its value.
Example:
Strict-Transport-Security: max-age=31536000
Some HTTP headers that are indirectly related to privacy and security, can also be considered HTTP security headers. By enabling suitable headers in web applications and web server settings, you can improve the defense mechanism of your web application against common vulnerabilities. Following are some of the common security headers:
- Content-Security-Policy (Response Header): This allows web site administrators to control resources the user agent is allowed to load for a given page. CSP provides an extra layer of security against multiple vulnerabilities such as XSS, Clickjacking, Protocol Downgrading and Frame Injection. It can also be used as a substitute for security headers, such as X-Frame-Options and X-XSS-Protection.
In CSP, whitelisting is used to define rules. We can filter out any resources that do not fit with our rules.
Example:
Content-Security-Policy: <policy-directive>; <policy-directive>
<policy-directive> consists of: <directive> <value> with no internal punctuation.
Content-Security-Policy: script-src 'self' https://example.com
#Few Policy-directives and their details:
- frame-ancestors: specifies the sites that have the authority to load the current page in a frame, iframe, object, embed, and applet tag. It is a substitute for X-Frame-Options, since it can also help prevent Clickjacking and UI Redressing attacks.
- object-src: defines or restricts the sources from <object>, <embed>, and <applet>, which helps preventing Cross-Site Scripting attacks.
- upgrade-insecure-requests: Instructs user agents to treat all of a site's insecure URLs (those served over HTTP) as though they have been replaced with secure URLs(those served over HTTPS).
- X-Frame-Options (Response Header): This can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>. Applications can use this to avoid click-jacking attacks.
Example:
X-Frame-Options: DENY | SAMEORIGIN | ALLOW-FROM URL
#Further Details:
- Deny: The page cannot be displayed in a frame, regardless of the site attempting to do so.
- SAMEORIGIN: The page can only be displayed in a frame on the same origin as the page itself.
- ALLOW-FROM-URL: The website can only be framed by the URL specified here.
Note: The Content-Security-Policy HTTP header has a frame-ancestors directive which obsoletes this header for supporting browsers.
- X-XSS-Protection (Response Header): This header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks.
Example:
X-XSS-Protection: 0 | 1 | 1; mode=block | 1; report=<reporting-uri>
#Further Details:
0: Disables XSS filtering.
1: Enables XSS filtering.
1; mode=block: Enables XSS filtering. In case of attack, the browser will prevent rendering of the page, rather than sanitizing the page.
1; report=<reporting-URI> (Chromium only): Enables XSS filtering. If a XSS attack is detected, the browser will sanitize the page and report the violation.
- HTTP Strict Transport Security (Response Header): HSTS tells browsers that site should only be accessed using HTTPS, instead of using HTTP.
Example:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
#Further Details:
- max-age=<expire-time> : The time, in seconds, that the browser should remember that a site is only to be accessed using HTTPS (Recommendation of 2 years of time period).
- includeSubDomains (optional parameter): rule applies to all of the site's subdomains as well.
- Preload: whether the site should be included in the HSTS preload list
Note: HSTS is based on Trust on First Use (TOFU), meaning that we have to manually redirect the users, on their first HTTP request, to the HTTPS version of our website. In its response, there will be an HSTS header, the browsers will store it in their cache. The next time an unsafe (HTTP) connection arises, it will automatically be redirected to a secure connection. An attack can use MITM attack for first HTTP request and use techniques like SSL Strip or SSL Hijacking. To prevent this, we need to add site to HSTS preload list and add preload directive in header. The browser will check if the site is in preload list and will refuse to load it over an insecure connection.
- X-Content-Type-Options (Response Header): used to control the MIME Type Sniffing function in web browsers. If the Content-Type header is blank or missing, the browser ‘sniffs’ the content and attempts to display the source in the most appropriate way. To prevent the browser from sniffing the page’s content and deciding on which MIME type to use, use the X-Content-Type-Options header with the ‘nosniff’ directive:
Example:
X-Content-Type-Options: nosniff
- Expect-CT (Response Header): Allows sites to opt in to reporting and/or enforcement of Certificate Transparency requirements, to prevent the use of mis-issued certificates for that site from going unnoticed. When a site enables the Expect-CT header, they are requesting that the browser check that any certificate for that site appears in public CT logs.
Example:
Expect-CT: report-uri="<uri>",enforce, max-age=<age>
#Further Details:
- max-age: This is the duration (in seconds) of the data being stored in the browser cache.
- report-uri: This is the URL to which the breach report will be sent.
- enforce: This indicates whether the connection should be established, if a certificate that doesn’t comply with CT is present.
Note: The Expect-CT will likely become obsolete in June 2021. Since May 2018 new certificates are expected to support SCTs by default. Certificates before March 2018 were allowed to have a lifetime of 39 months, those will all be expired in June 2021.
- Access-Control-Allow-Origin (Response header): It indicates whether the response can be shared with requesting code from the given origin.
Example:
Access-Control-Allow-Origin: * | <origin> | null
#Further Details:
*: Allows request code from any origin to access the resource.
<origin>: Specifies an origin. Only a single origin can be specified.
References:
HTTP Headers : Web App Security Basics was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.
Hacker's Directory 