Category: Work

Rants about my worklife.

RIP Yahoo Site Explorer –

I recently was reviewing a customer website and found this markup, while it looked vaguely familiar, I had do do a little searching to find it’s original use.

<meta name=“y_key” content=“xxxxxx” />

This was for Yahoo Site Explorer, it existed for a little over six years, from September 2005 until November 2011!

It provided a lot of similar functions as the Google Search Console.??https://en.wikipedia.org/wiki/Yahoo_Site_Explorer

TLDR; If you find this markup in any website, it’s relatively safe to assume that you can remove it with very little impact other than some saved bytes in your network traffic.

Trivy security vulnerability scanner

Security issues can creep in at all levels of software development, keeping a variety of tools available is always a good idea.

Trivy will help to identify configuration issues and potential secrets in a project.

The fastest method I’ve found to get started is to use Homebrew, if you have not already installed it, I’ve posted instructions in an earlier post.

brew install trivy

An initial scan can then be run with:

trivy fs --scanners vuln,secret,misconfig ./

REFERENCES:

Prevent spring from initializing webjar handler mapping at startup

I recently observed a case where an application does not use webjars in a service, yet the application is exposing the path. Generally this does not have any impact, but as spring and spring-boot are often deployed to run web services where there is no expectation of a user interface, this seems a bit heavy.

Seen in startup console as:

2024-08-14 09:01:001.033 DEBUG [] _.s.web.servlet.HandlerMapping.Mappings : 'resourceHandlerMapping' {/webjars/=ResourceHttpRequestHandler [classpath [META-INF/resources/webjars/]], /=ResourceHttpRequestHandler [classpath [META-INF/resources/], classpath [resources/], classpath [static/], classpath [public/], ServletContext [/]]}


For application.properties, use:

spring.web.resources.add-mappings=false

For application.yml, format as:

spring:
 web:
   resources:
     add-mappings: false

REFERENCES:

Use of lower-case HTML5 DOCTYPE as a network micro-optimization

TLDR; using lowercase in markup improves the compression as the dictionary for the algorithm will be smaller. Most HTML/JS/CSS is case insensitive and can be optimized as lowercase.

micro-optimizations can be fun… or an utter pain.

I’ve been on both sides of this debate at times, at one time had sub-second SLA’s for a web based customer service app that ran out of a UK data-center with users in South America.

This helped build a thorough understanding of how to best use the browser cache, progressive page loading, and optimization of image and network compression.

Webserver extensions like Google mod_pagespeed definitely help automate some of this stuff on the output, but nothing is ever robust as just building the application with performance in mind.

As a java shop (at that time), JSP exposes a lot of config to eliminate white-space in generated output, that often saved up to several K per page. I’m always amazed when I find large companies that still do not utilize those features, as “bandwidth is cheap” for the provider… but not always for the end user.

REFERENCES:

Replacing Google Fonts with Bunny Fonts for GDPR compliance

Google is “free” for users as it is actively collecting and selling their user activity. There are some small steps you can take to better protect your customers/users from this tracking. One small step you can take is to use a different source for fonts. While it’s technically feasible to self-host fonts, it’s often best to use an external party to leverage their CDN and the users browser cache for improved performance.

The Bunny Fonts API was designed to be fully compatible with the Google Fonts CSS v1 API, making the switch as easy as changing the hostname.

Simply swap “https://fonts.bunny.net/css” in place of “https://fonts.googleapis.com/css” on your website’s source code and let your users enjoy better privacy.

If you’ve implemented Content-Security-Policy (CSP) HTTP Headers in your application, you will also need a variation of the following:

font-src https://fonts.bunny.net/; style-src https://fonts.bunny.net/css;

REFERENCES:

Gradle dependency versions plugin

Developers often have a lot on their plates, maintaining current version of their library dependencies often takes a back seat to deliverables. Far too often, the only time a library is updated is when it becomes a problem, either as a vulnerability or as a headache that prevents other updates. Monitoring repositories and email lists can also be problematic.

To simplify some of the manual effort that often goes into this, use of build plugins can help. With them, each build, either on the developer desktop or as part of a CI (Continuous Integration) pipeline, can provide feedback to any developer that looks at the output.

Adding to a Gradle project only takes a few small changes:

In build.gradle:

plugins {
  id 'com.github.ben-manes.versions' version '0.51.0'
}

Then to invoke you can use:

./gradlew dependencyUpdates

To simplify for use with make, add to an existing step like ‘test’ in a Makefile like:

.PHONY: test
test: clean
  ./gradlew test dependencyUpdates

 

REFERENCES:

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:

SameParty cookie attribute

While Google has made strides to remove cookies, there was a recent addition to the Chromium product upon which Chrome, Safari, and Edge are based.

I saw this written up as the following:

The SameParty attribute takes no value, and requires that the cookie also specify the “Secure” attribute, and not specify “SameSite=Strict”. If either of these constraints is violated, the cookie will be considered invalid, and will not be set. “SameSite=Strict” is not supported because “SameSite=Strict” is intended as a security boundary, rather than a privacy boundary (which First-Party Sets aims to establish). Valid use-cases of “SameSite=Strict” in cross-site contexts should not be loosened even when the sites are same-party.

Better stated…

  • The SameParty attribute is specified without a value (as are Secure and HttpOnly) as ;SameParty;
  • The Secure attribute is required in order to use the SameParty attribute. Any cookie specifying SameParty without Secure will be rejected as invalid.
  • Additionally, any cookie specifying SameParty in the presence of SameSite=Strict will be rejected as invalid.

While I’ve seen this implemented in versions of Chrome 89+, it is not yet adopted in Firefox (and may never be).

References: