Clear-Site-Data HTTP Header

In an effort to improve security on the client-side modern browsers have introduced a means to allow for web applications request a client to remove persisted data. Of course, not supported in any version of MSIE or Safari, but all modern browsers Chrome 61+, Edge 79+, Firefox 63+ support.

This approach can be useful at logoff or session invalidation to remove data from the client-side, particularly in cases of persistent or reflected XSS.

Clear-Site-Data: “cookies”
Clear-Site-Data: “cache”, “cookies”, “storage”, “executionContexts”

REFERENCES:

Google Federated Learning of Cohorts (FLoC) – optout

Google Chrome 89 and other browsers based upon it such as Chromium Edge have introduced a new capability known as FLoC. This approach removes the need for third-party cookies by passing a group identifier in the HTTP Headers in a manner similar to how Cookies are exchanged. While FLoC should allow for users to remain more anonymous as advertisers only receive a group identifier for the user, it would not be difficult to use their IP address or other features available via device fingerprinting to track the individual.

As a web user, you would need to use several approaches to avoid this:
1. Use a browser without FLoC support. Hopefully, this will be added to the configuration menus to allow users to prevent it, similar to DNT.
2. Use a browser plugin (or other software/proxy) to remove the FLoC headers.

As a web-developer, you can add configuration to opt-out of all FLoC cohort calculation by sending the following HTTP response header:


Permissions-Policy: interest-cohort=()

If you really want to see the data, the following javascript will expose it:

const { id, version } = await document.interestCohort();
console.log('FLoC ID:', id);
console.log('FLoC version:', version);

REFERENCES:

Neofetch for displaying system information

Originally designed for use in demonstrations on Linux bash in an easy to understand way that could be used in screenshots and demos. In my experience I’ve found that it also makes it easier to review details of remotely administered and virtual machines or images when performing maintenance.

Neofetch shows Operating System, uptime, CPU, GPU, and memory information. While built for linux bash, it can also be installed on macOS and Windows machines.

Installation for Linux is as simple as:
sudo apt install neofetch

REFERENCES:

HSTS preload

If you have already started using HSTS to force users to your HTTPS website, the use of ‘preload’ is another simple addition as it only requires the addition of the keyword to the header.

Once done, you can either wait for your site to be identified (which can take a long time, or forever for less popular websites) or ideally, submit your hostname to be added to the lists preloaded in many modern browsers. The advantage here is that your users will never make a single request to your HTTP website and will automatically be directed to HTTPS.

An HTTP Header example:

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

Apache2 configuration example:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

REFERENCES:

“Referrer-Policy” HTTP Header

A relatively new HTTP Header that is supported by most modern browsers (except MSIE) is the “Referrer-Policy” header. There have been previous attempts to implement similar protections through use of the ‘rel’ (or ‘rev’) attributes on links to external websites. The latest approach takes a different approach and prevents leaking of internal URLs, and in some cases parameters, to external websites. This is important from a security perspective as you might maintain some sensitive information in your page urls, that would otherwise be inadvertently shared with an external website.

Clearly, you’ll need to determine your own level of security based upon your needs. Example: ‘no-referrer’ would be the most strict and would prevent the browser from sending the ‘Referer'(sic) header even to your own websites pages.

Example header values:

Referrer-Policy: no-referrer
Referrer-Policy: no-referrer-when-downgrade
Referrer-Policy: origin
Referrer-Policy: origin-when-cross-origin
Referrer-Policy: same-origin
Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: unsafe-url

Implementation can be accomplished in many ways, the most simple being and addition to your HTTP server configuration similar to the one shown below for Apache 2.x:

Header always set Referrer-Policy strict-origin

REFERENCES:

Content-Security-Policy: block-all-mixed-content

If you are running a secure website, it’s a good idea to prevent non-secure assets from being included on your page. This can often happen through the use of content management system, or even through website vulnerabilities. A simple change in HTTP headers will help browsers to defend against them.


Content-Security-Policy: block-all-mixed-content

Most modern browsers, except MSIE, currently support this approach.
– Firefox 48+

REFERENCES

Content-Security-Policy: upgrade-insecure-requests;

As the web has been shifting to HTTPS for security and performance reasons, there are many methods to migrate users. One simple method is via the use of the Content-Security Header.


Content-Security-Policy: upgrade-insecure-requests;

Most modern browsers, except MSIE, currently support this approach.
– Chrome 43+

REFERENCES

SameSite cookies

Recently, while reading through the updated 2017 OWASP Top Ten RC1 documentation, last updated in 2013, I noticed a recommendation to use Cookies with the “SameSite=strict” value set to reduce CSRF exposure in section A8.

Consider using the “SameSite=strict” flag on all cookies, which is increasingly supported in browsers.

Similar to the way that HttpOnly and Secure attributes have been added, SameSite allows for additional control.

Per the documentation, as of April 2017 the SameSite attribute is implemented in Chrome 51 and Opera 39. Firefox has an open defect, but I would expect it to be added soon to follow Chrome.


Set-Cookie: CookieName=CookieValue; SameSite=Lax;
Set-Cookie: CookieName=CookieValue; SameSite=Strict;

According to the specification you can issue the SameSite flag without a value and Strict will be assumed:


Set-Cookie: CookieName=CookieValue; SameSite

As many programming languages and server runtime environments do not yet support this for session cookies, you can use the Apache Tier1 configuration to append them.


Header edit Set-Cookie ^(JSESSIONID.*)$ $1;SameSite=Strict
Header edit Set-Cookie ^(PHPSESSID.*)$ $1;SameSite=Strict

It looks like PHP.INI might support the following attribute in a future release, but it’s not there yet!

session.cookie_samesite

REFERENCES:

Modify Ubuntu Swappiness for performance

Sometimes, it is possible to improve the performance of Ubuntu on older hardware by modifying the disk swapping behavior.

Check your current setting:

cat /proc/sys/vm/swappiness

To modify the behavior, just change the value and reboot. Most documentation recommends trying a value of 10.

sudo vi /etc/sysctl.conf

Add (or change):

# Decrease swappiness value (default:60)
vm.swappiness=10

REFERENCES:

Sonatype Nexus2 Repository Manager OSS

To allow for repeatable, faster builds in a continuous build environment, it’s often a good idea to use a central repository to cache common assets and prevent the need to download assets from the internet for each build. Using Nexus allows for those transfers to occur over your local network for previously downloaded assets.

You can download the WAR from:
http://www.sonatype.org/downloads/nexus-latest.war

And install on your Java application server, such as Apache Tomcat, via normal means.

If you are using Maven, you’ll need to make appropriate changes in (/.m2/settings.xml) to direct your builds to use Nexus.

Jenkins and other build automation tools will require similar changes.

REFERENCES: