Articles

Getting Started with User Scripts

A User Script is a locally installed script in your web browser that applies JavaScript and CSS customizations to a specific website while you are visiting the website. Here are a few example use cases:

  1. Add Functionality, such as a “Download List to CSV” button that loops through a list on the web page and generates a CSV file.
  2. Remove Functionality, such as hiding links or buttons you never intend to use to help de-clutter a web interface.
  3. Fix Design Issues, such as the position or color of an element on the page that might be bothering you.

User Scripts can be run in any web browser by installing a User Script browser extension. Here are a few example User Script extensions for some of the more popular web browsers:

  1. Safari – Userscripts
  2. Firefox – Violentmonkey
  3. Brave – Violentmonkey
  4. Chrome – Violentmonkey
  5. Edge – Violentmonkey

PRO TIP: If you have access to a WebDAV file sharing folder that supports BASIC authentication, Violentmonkey can sync your User Scripts settings across multiple browsers. Unfortunately, Violentmonkey does not currently support WebDAV DIGEST authentication.

Getting Started with Userscripts Extension on Safari

I’ve provided a few example scripts you can use to suppress extra menus and buttons on several financial websites. Here are step-by-step instructions to install these scripts.

  1. Install the Userscripts browser extension for Safari
  2. Enable the extension
    1. Go to the Safari drop-down menu and select Preferences
    2. When the Preferences window appears, go to the Extensions tab
    3. Make sure the “Userscripts” extension is enabled. The check box next to the extension name should be checked.
  3. Click the “Userscripts” icon on your Safari browser bar. The icon will look similar to this: “</>
  4. You should see a window with a “Search and Filter” text box, Gear icon, and Plus icon in the upper-left corner
  5. Click the Plus icon and choose “New Javascript”. You should see a new JS User Script in the left-hand list and a new User Script template in the right-hand content area.
  6. Download a Sample Script, open the text file, and copy/paste the code into the right-hand content area, replacing the sample template code. Repeat for each User Script you’d like to try. You can install multiple User Scripts.
    1. Minimal QBO – Minimal interface for Intuit QuickBooks Online
    2. Minimal Mint – Minimal interface for Intuit Mint
  7. Use the toggle in the left-hand list to enable/disable individual User Scripts
  8. Browse to the website and enjoy the User Script customizations!

Viscosity VPN set a static hostname on macOS 11.1 (Big Sur)

Each time I use the Viscosity VPN client on macOS 11.1 (Big Sur) to establish an OpenVPN connection, the hostname displayed in new macOS terminal session would change from my computer name (e.g. “user@trogdor“) to the reverse lookup hostname of my VPN IP address (e.g. “user@ip-10-2-3-4”).

Suppose I always wanted my hostname to be “trogdor“. I ran the following command in a Terminal session to set a permanent hostname that does NOT seem to change when I connect to the VPN.

scutil --set HostName trogdor

Huge thank you to Chris Searle for posting this same solution for OSX Lion and Mountain Lion! I assume that means this solution would also work for all macOS versions between 10.7 and 11.1:

  • OSX 10.7: “Lion”
  • OSX 10.8: “Mountain Lion”
  • OSX 10.9: “Mavericks”
  • OSX 10.10: “Yosemite”
  • OSX 10.11: “El Capitan”
  • macOS 10.12: “Sierra”
  • macOS 10.13: “High Sierra”
  • macOS 10.14: “Mojave”
  • macOS 10.15: “Catalina”
  • macOS 11.0: “Big Sur”
  • macOS 11.1: “Big Sur”

Did this help you out? Do you have more info to share? Please reply below! I’d love to hear from you.

State of U2F in December 2020

NOTE: This is an updated version of my original article: “State of U2F in May 2019” (18 months ago)

I am attempting to register physical USB keys with various online accounts in an attempt to improve my online security.

I purchased multiple YubiKey keys (YubiKey 5C and YubiKey 5C Nano) with the intent to register at least two keys with each of my supported online accounts so that I have a backup in case my primary key is lost or stolen. I have access to additional YubiKey keys for testing, so I will attempt to register at least 3 keys with each service.

Before you begin, consider using YubiKey manager to disable all interfaces except “FIDO U2F” and “FIDO2” on each key. I manually labeled each of my keys as “U2F NNNN”, though it is unclear which sites are using older FIDO1 (FIDO U2F) and which sites are using newer FIDO2. The “OTP” interface is similar to Google Authenticator [1] and could leak your identity [2]. Disabling OTP will prevent YubiKey from typing a string every time you tap the YubiKey button. Only enable the interfaces you intend to use.

Here is a summary of my experience with each online provider. Each browser test was performed on macOS 11.1 (Big Sur) on Apple Silicon M1 with latest version of Brave (1.2.40 88.0.4315.5), Firefox (84.0), and Safari (14.0.2) 64-bit browsers. I am able to register keys to my accounts and authenticate to my accounts using Brave, Firefox, and Safari. All 3 browsers appear to have built-in support for “WebAuthn” and/or “U2F”.

Google (Apps, Cloud)

Key Limit: Multiple (6+) — Successfully registered 6 different U2F keys
Supported Browsers:
• Brave (1.2.40 88.0.4315.5) on macOS 11.1 (Big Sur) – M1 Intel/Rosetta 2
• Firefox (84.0) on macOS 11.1 (Big Sur) – M1 Universal App
• Safari (14.0.2) on macOS 11.1 (Big Sur) – M1 Universal App

GitHub

Key Limit: Multiple (6+) — Successfully registered 6 different U2F keys
Supported Browsers:
• Brave (1.2.40 88.0.4315.5) on macOS 11.1 (Big Sur) – M1 Intel/Rosetta 2
• Firefox (84.0) on macOS 11.1 (Big Sur) – M1 Universal App
• Safari (14.0.2) on macOS 11.1 (Big Sur) – M1 Universal App

Facebook

Key Limit: Multiple (6+) — Successfully registered 6 different U2F keys
Supported Browsers:
• Brave (1.2.40 88.0.4315.5) on macOS 11.1 (Big Sur) – M1 Intel/Rosetta 2
• Firefox (84.0) on macOS 11.1 (Big Sur) – M1 Universal App
Unsupported Browser:
• Safari (14.0.2) on macOS 11.1 (Big Sur) – M1 Universal App (fallback to OTP authenticator code)

WordPress (via Plugin)

Key Limit: Multiple (6+) — Successfully registered 6 different U2F keys
Supported Browsers:
• Brave (1.2.40 88.0.4315.5) on macOS 11.1 (Big Sur) – M1 Intel/Rosetta 2
• Firefox (84.0) on macOS 11.1 (Big Sur) – M1 Universal App
• Safari (14.0.2) on macOS 11.1 (Big Sur) – M1 Universal App

NameCheap

Key Limit: Multiple (6+) — Successfully registered 6 different U2F keys
Supported Browsers:
• Brave (1.2.40 88.0.4315.5) on macOS 11.1 (Big Sur) – M1 Intel/Rosetta 2
• Firefox (84.0) on macOS 11.1 (Big Sur) – M1 Universal App
• Safari (14.0.2) on macOS 11.1 (Big Sur) – M1 Universal App

Amazon Web Services (AWS)

Key Limit: ONE (1) — Simple On/Off toggle for 2FA. Must choose either OTP or U2F. Cannot enable both simultaneously. Unable to Register Multiple U2F Keys [3]
Supported Browsers:
• Brave (1.2.40 88.0.4315.5) on macOS 11.1 (Big Sur) – M1 Intel/Rosetta 2
• Firefox (84.0) on macOS 11.1 (Big Sur) – M1 Universal App
Unsupported Browsers:
• Safari (14.0.2) on macOS 11.1 (Big Sur) – M1 Universal App

Twitter

Key Limit: ONE (1) — Simple On/Off toggle for U2F. Unable to Register Multiple U2F Keys. Can enable OTP and U2F simultaneously.
Supported Browsers:
• Brave (1.2.40 88.0.4315.5) on macOS 11.1 (Big Sur) – M1 Intel/Rosetta 2
• Firefox (84.0) on macOS 11.1 (Big Sur) – M1 Universal App
• Safari (14.0.2) on macOS 11.1 (Big Sur) – M1 Universal App

No Support for U2F or FIDO2

LinkedIn – The only supported verification methods are SMS and OTP (Authenticator App) as of 12/2020
MailChimp – The only supported verification methods are SMS and OTP (Authenticator App) as of 12/2020
Slack – The only supported verification methods are SMS and OTP (Authenticator App) as of 12/2020. More Info

References

[1] Medium: The Unofficial FIDO U2F FAQ
[2] Hacker Noon: Avoid Leaking Your Identity with YubiKey
[3] AWS: Use YubiKey security key to sign into AWS Management Console with YubiKey for multi-factor authentication (comments confirm only one U2F device is supported per login)

AWS CodeBuild Failed due to Docker pull rate limit. Solution: Update buildspec.yml file.

At Logic Forte, our CI/CD pipelines typically use AWS CodeBuild to pull Git repositories and build/test/deploy Docker images. Our typical build will pull a public image from Docker Hub, build a custom image, and then save our custom image to a private repo on ECR for testing/deployment.

Docker has been notifying users that they would begin rate limiting public image requests in November 2020. The new limits of 100 pulls per hour may seem like it would not affect your occasional builds, especially if you deploy from a private repo like ECR.

Nearly all of our image pulls use our private repo when we deploy and when we scale up/down. We might build 5-10 times per day, which is far below the new 100 pulls per hour limit. However, if you use a cloud service (such as CodeBuild) to build your Docker images, this new rate limiting will likely affect you since the cloud build service will likely exceed Docker’s new rate limit thresholds. The service is building images for thousands of other customers, so Docker seems thousands of pull requests coming from the build service and they no idea who the requests belong to.

Problem

Our CodePipeline failed immediately after Docker began enforcing the new rate limits. Specifically, our CodeBuild job failed with the following errors:

Building the Docker image...

[Container] 2020/11/04 18:19:25 Running command docker build -t $REPOSITORY_URI:$IMAGE_TAG .
Sending build context to Docker daemon  6.797MB
Step 1/17 : FROM php:7.3-apache
toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit

[Container] 2020/11/04 18:19:26 Command did not exit successfully docker build -t $REPOSITORY_URI:$IMAGE_TAG . exit status 1
[Container] 2020/11/04 18:19:26 Phase complete: BUILD State: FAILED

Solution

Fortunately, the solution to the “toomanyrequests: You have reached your pull rate limit” error was simple and straightforward.

  1. Create account at Docker.com. We created a new FREE individual account at Docker.com just for authenticating pull requests.
  2. Create a new Access Token in your Docker account under Account Settings then Security. We named our access token “AWS CodePipeline”.
  3. Update your project buildspec.yml file used by CodeBuild so that it authenticates to Docker prior to building images. We added the following 3 lines to our build spec, immediately before our “docker build” command. Substitute “mybucket”, “mypath”, and “myusername” with valid values for your environment.
aws s3 cp s3://mybucket/mypath/.docker.key .docker.key
docker login -u myusername --password-stdin < .docker.key
rm .docker.key

To be clear, we placed our Docker Access Token in a file named “.docker.key” and uploaded the “.docker.key” file to a restricted S3 bucket. Our build process is already reading other files from the S3 bucket, so adding this file to the mix was easy. If your CodeBuild job is not already interacting with S3, you will need to setup IAM permissions to allow CodeBuild to read from a bucket. An alternate solution would be to store your Access Token in AWS Secrets Manager and retrieve the secret token during the build process.

Need a quick fix? You could temporarily use the following single line solution in your Build Spec file (instead of the 3 lines we are using above) to test and ensure that authenticating to Docker resolves your build errors.

docker login -u myusername -p myaccesstoken

Be aware that storing your Access Token in your Build Spec file is not considered best practice, since your access token would end up being committed to a shared code repository. If you test with this one-liner, be sure to remove the access token from your Docker account after you are done testing!

Please reply below if you found this helpful. It is always nice to hear that these posts are helping others. 🙂

AWS Lambda Function that Automatically Updates Security Groups using AWS ip-ranges.json file

We heavily restrict outbound traffic for all of our EC2 instances. This is straightforward most of the time, but can be frustrating when you want to allow access to AWS services.

AWS offers VPC endpoints for some services, such as S3, that allow us to make the AWS service available in our VPC without having to allow outbound HTTPS access to the entire internet.

However, what do you do when you want to use a service that does NOT offer a VPC endpoint? For example, we need to allow HTTPS to SQS and we need to allow SUBMISSION (587/tcp) to SES. AWS would tell you that you have to allow outgoing HTTPS or SUBMISSION traffic to the entire internet.

I created a script a few years ago (based on an AWS script for CloudFront) to solve this problem. The script downloads the list of known AWS IP ranges every time the list is updated, merges the ranges for your specified AWS Region, and then updates Security Groups that contain special tags. While not perfect, this script allows us to restrict outgoing HTTPS or SUBMISSION traffic to known AWS IPs instead of the entire internet. It has been working quite well for the past few years.

I published the code with documentation today. Would gladly accept PRs if you try this and want to help improve the documentation. Enjoy!
https://github.com/jason-klein/aws-lambda-update-security-groups-aws-ip-ranges