Tag Archives: security

PHP Curl Security Hardening

Good post — with accompanying code — on PHP.Watch on how to tighten the almighty curl:

  1. Limit Curl Protocols
  2. Do not enable automatic redirects unless absolutely necessary
  3. If redirects are enabled enabled, limit allowed protocols (if different from #1 above)
  4. If redirects are enabled, set a strict limit
  5. Set a strict time-out
  6. Do not disable certification validation, or enforce it
  7. Disable insecure SSL and TLS versions

PHP Curl Security Hardening →

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