security – Giant Geek Blog

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:

Global Privacy Control (GPC) – Sec-GPC HTTP Header – /.well-known/gpc.json file

GPC is the latest attempt at allowing customers to specify how their browsing data is to be shared online, the previous attempt referred to as DNT was a relative failure.

Like with DNT, once the user specifies their preference the browser adds an additional HTTP request header:
Sec-GPC: 1

This can be checked with javascript on the page with the following
const gpcValue = navigator.globalPrivacyControl

Additionally, websites can define that they respect the GPC request by posting a file in a file /.well-known/gpc.json
Content-Type: application/json
{ "gpc": true, "version": 1, "lastUpdate": "2021-11-01" }

Examples:

GPC is currently implemented by default in:
Brave = https://spreadprivacy.com/global-privacy-control-enabled-by-default/

In Firefox, you currently have to enable it manually:
about:config globalprivacycontrol boolean true

REFERENCES:

security.txt files

Similar to robots.txt and humans.txt is a recent addition of a security.txt file. This is currently a draft proposal to provide a standardized way to define security policies for researchers. This is useful for bug bounty and disclosure programs. Government agencies were tasked to add these back in 2019, but COVID-19 likely delayed implementation and rollout.

This is usually applied in the root of a website at /.well-known/security.txt, but can also be immediately in the root at /security.txt. Personally, I put mine in /.well-known/ and put a redirect at the root to simplify maintenance.

For additional security, you can optionally sign the policy with PGP.

Details:

I did some searching around the web and found some examples (linked below):

File in the root path:

File in the preferred /.well-known path:

Some PGP signed examples:

Questionable, though as the files are meant to be read by humans, this would meet the most simple use case:

USB Data-Blocker aka USB Condom

I was recently reading Kevin Mitnick’s “The Art of Invisibility” and found that he’d also recommended these devices. I’ve been using them for several years as it was always unnerving to plug in a mobile device into a work computer to recharge only to see that there was a request to mount them. Additionally, my laptop would occasionally want to tether data via my cell phone. In an effort to block data transfer and leakage, something was required. These simple and cheap devices allow for power but no data to be transferred via the USB port.

WARNING: there’s always the possibility that any USB device could be compromised, including these… keep them in sight and under your control at all times.

REFERENCES:

Windows Vista EOL

As of April 11, 2017, Windows Vista customers are no longer receiving new security updates, non-security hotfixes, free or paid assisted support options, or online technical content updates from Microsoft. Microsoft has provided support for Windows Vista for the past 10 years

https://support.microsoft.com/en-us/help/22882/windows-vista-end-of-support

The most recent version of Internet Explorer in Windows Vista was IE 9.0.8112.16421 (9.0.57)

Even Apple, Google and Mozilla Firefox have ceased to maintain browsers for this operating system, dropping support for Windows XP and Vista at the same time.

Chrome 49.0.2623.112
https://chrome.googleblog.com/2015/11/updates-to-chrome-platform-support.html

Firefox 52.9.0 ESR
https://support.mozilla.org/en-US/kb/end-support-windows-xp-and-vista

Safari 5.1.7
https://apple.stackexchange.com/questions/68836/where-can-i-download-safari-for-windows

Windows XP EOL

I recently crossed paths with a customer that was still using Windows XP and experiencing problems with a website. This led me to evaluate their options for continuing to use this once very common, but now unsupported operating system.

After 12 years, support for Windows XP ended April 8, 2014. Microsoft will no longer provide security updates or technical support.

https://www.microsoft.com/en-us/windowsforbusiness/end-of-xp-support

The most recent version of Internet Explorer in Windows XP was IE 8.0.6001.18702

Even Apple, Google and Mozilla Firefox have ceased to maintain browsers for this operating system, dropping support for Windows XP and Vista at the same time.

Chrome 49.0.2623.112
https://chrome.googleblog.com/2015/11/updates-to-chrome-platform-support.html

Firefox 52.9.0 ESR
https://support.mozilla.org/en-US/kb/end-support-windows-xp-and-vista

Safari 5.1.7
https://apple.stackexchange.com/questions/68836/where-can-i-download-safari-for-windows

An additional problem with use of IE8 on Windows XP is that it only supports up to TLS1.0 which is currently being replaced by TLS1.2 in many web applications.

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:

Clear Linux bash history

While having history available with the simple use of the up arrow is a convenience feature common to most linux builds it can come with some risk. One such risk is when you have inadvertently typed a password instead of a command, or had to pipe credentials into a command.

Thankfully, you can clear the entire history with a variety of methods, the most common are below but others are available in the references.

history -c && history -w

cat /dev/null > ~/.bash_history && history -c && exit

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:

Remove Guest Account in Ubuntu

While the Guest session can be useful for some people, I’ve generally considered it to be security vulnerability as unauthorized users could gain physical access to some areas of your system that are not secured as well as they “should” be.

Additionally, the default behavior that allows for the username(s) to be stored and listed on the login screen are less than ideal.

Here we remove both!

Create the config folder:
sudo mkdir -p /etc/lightdm/lightdm.conf.d
Create a new config file:
sudo vi /etc/lightdm/lightdm.conf.d/10-ubuntu.conf
Add the following:
[SeatDefaults] user-session=ubuntu greeter-show-manual-login=true greeter-hide-users=true allow-guest=false
Reboot

REFERENCES: