Improve security & performance

Article in English Articol în Română

Increase Security with X-Security Headers

These techniques add extra security headers to all of your site's resources. Specifically, this tutorial explains how to add X-Security Headers to protect against cross-site scripting (XSS), page-framing, and content-sniffing. Adding these extra headers is simple and helps to boost the security of your site.

Protect against XSS attacks (X-XSS-Protection)

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.

First up, we want to add an X-Security Header to help protect against XSS. To do so, add the following directive to your site's root .htaccess file:

# X-XSS-Protection
<IfModule mod_headers.c>
	Header set X-XSS-Protection "1; mode=block"
</IfModule>

No modifications are required, simply copy/paste and done. This code works by adding the X-XSS-Protection header to your server responses. Most modern web browsers understand this header and will use it to help protect your site against cross-site scripting attacks.

Protect against page-framing and click-jacking (X-Frame-Options)

Clickjacking, also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page. Thus, the attacker is "hijacking" clicks meant for their page and routing them to another page, most likely owned by another application, domain, or both.Using a similar technique, keystrokes can also be hijacked.

With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker.

Next, we want to add an X-Security Header to help protect against page-framing and clickjacking. To do so, add the following directive to your site's root .htaccess file:

# X-Frame-Options
<IfModule mod_headers.c>
	Header always append X-Frame-Options SAMEORIGIN
</IfModule>

No modifications are required, simply copy/paste and done. This code works by adding the X-Frame-Options header to your server responses. Most modern web browsers understand this header and will use it to ensure that your page can be displayed in a frame only if the frame is on the same domain.

Protect against content-sniffing (X-Content-Type-Options)

Last but not least, we want to add an X-Security Header to help protect against content-sniffing. To do so, add the following directive to your site's root .htaccess file:

# X-Content-Type nosniff
<IfModule mod_headers.c>
	Header set X-Content-Type-Options nosniff
</IfModule>

No modifications are required, simply copy/paste and done. This code works by adding the X-Content-Type-Options header to your server responses. Most modern web browsers understand this header and will use it to ensure proper MIME types for all loaded resources (e.g., CSS, JavaScript, fonts, images, video, et al). No modifications are required, simply copy/paste and done. This code works by adding the X-Content-Type-Options header to your server responses. Most modern web browsers understand this header and will use it to ensure proper MIME types for all loaded resources (e.g., CSS, JavaScript, fonts, images, video, et al).

HTTP Strict-Transport-Security (HSTS)

HSTS (HTTP Strict Transport Security) protects users from cookie hijacking and protocol downgrade attacks by forcing browsers to request HTTPS pages from your domain. HSTS is similar to a 301 redirect from HTTP to HTTPS but at the browser level.

There may be a specific HSTS configuration appropriate for your website. The following are less secure options and preload-ineligible as first-time traffic to your site will be able to use insecure HTTP:

Strict-Transport-Security: max-age=10886400;
Strict-Transport-Security: max-age=10886400; includeSubDomains

A breakdown of the header:

Strict-Transport-Security Forces HSTS on the domain
max-age How long the header should be active in seconds
includeSubDomains Includes subdomains
preload Authorizes preload listing if eligible (covered below)

Below we'll cover adding the most secure HSTS configuration using the .htaccess file and submitting your domain to the Chrome preload list maintained by Google.

Add the following line to your .htaccess file:

<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=10886400; includeSubDomains; preload"
</IfModule>
  • To submit your domain for preloading, visit Hstspreload.org.
  • Type your domain and Check HSTS preload status and eligibility.
  • The background will turn green or red depending on the results.
  • Fix the errors and/or submit your domain for preloading.

After submitting your domain for HSTS preloading, it can take 2-6 months for your domain to be accepted and then listed in the latest browser versions.

Content Security Policy

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

When your browser loaded this page, it loaded a lot of other assets along with it. There are stylesheets and fonts to load along with quite a few javascript files. One for the Disqus comment system, one for Google Analytics, my social sharing buttons down at the bottom and a few more for good measure too. Your browser loads these assets because it is instructed to do so by the source code of the page. It has no way of knowing whether or not any of those files should or should not be loaded. An attacker could have placed a specially crafted comment in the comment section to load some malicious javascript from a 3rd party domain and this would also be loaded by your browser because it was included along with the page. Your browser has no reason to not trust the content from nastyhackers.com and no way of knowing the content is malicious. This is where CSP comes in.

Whitelisting Approved Sources

A CSP header allows you to define approved sources for content on your site that the browser can load. By specifying only those sources that you wish the browser to load content from, you can protect your visitors from a whole range of issues. Here is a basic CSP response header.

Content-Security-Policy: script-src 'self'

What can we protect?

CSP comes with a wide range of directives that can be used to enforce policy across a whole load of content and circumstances. Here is a list of all of the directives that are available, along with a brief description, courtesy of OWASP.

default-src: Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback),
script-src: Define which scripts the protected resource can execute,
object-src: Define from where the protected resource can load plugins,
style-src: Define which styles (CSS) the user applies to the protected resource,
img-src: Define from where the protected resource can load images,
media-src: Define from where the protected resource can load video and audio,
frame-src: Define from where the protected resource can embed frames,
font-src: Define from where the protected resource can load fonts,
connect-src: Define which URIs the protected resource can load using script interfaces,
form-action: Define which URIs can be used as the action of HTML form elements,
sandbox: Specifies an HTML sandbox policy that the user agent applies to the protected resource,
script-nonce: Define script execution by requiring the presence of the specified nonce on script elements,
plugin-types: Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded,
reflected-xss: Instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header,
report-uri: Specifies a URI to which the user agent sends reports about policy violation

Creating A Policy

You can be as specific or as broad as you like when creating a CSP and fine tune it so that it meets your requirements exactly. Here is an example policies that you can add into .htaccess:

Header set Content-Security-Policy "default-src 'self';"

More information on Content Security Policy you can find here and here.

Referrer-Policy

What's a referrer?

When a user clicks a link on one site, the origin, that takes them to another site, the destination, the destination site receives information about the origin the user came from. This is how we get metrics like those provided by Google Analytics on where our traffic came from. I know that 4,000 users came from Twitter this week because when they visit my site they set the referer[sic] header in their request.

The Referrer Policy header

The spec for Referrer Policy has been a W3C Candidate Recommendation since 26 January 2017 and can be found here but we are not going to cover everything in this post to save you the trouble. The Referrer Policy is issued via a HTTP response header with the same name, Referrer-Policy, and can contain one of the following values as defined in the spec:

enum ReferrerPolicy {
"",
"no-referrer",
"no-referrer-when-downgrade",
"same-origin",
"origin",
"strict-origin",
"origin-when-cross-origin",
"strict-origin-when-cross-origin",
"unsafe-url"
};

You can find here a detailed explanation for each spec. More info here.

Creating A Policy

Here is an example that you can add into .htaccess:

Header always set Referrer-Policy "same-origin"

Was this answer helpful? 0 Users Found This Useful (0 Votes)