Featured Articles

Continuous Documentation: Hosting Read the Docs on GitHub Pages (2/2)
Introducing BusKill: A Kill Cord for your Laptop
Crowdfunding on Crowd Supply (Review of my experience)
Hardening Guide for phpList
Trusted Boot (Anti-Evil-Maid, Heads, and PureBoot)
Nightmare on Lemmy Street (A Fediverse GDPR Horror Story)
Detecting (Malicious) Unicode in GitHub PRs
WordPress Multisite on the Darknet (Mercator .onion alias)
WordPress Profiling with XHProf (Debugging & Optimizing Speed)
previous arrow
next arrow

Hardening Guide for phpList

phpList Hardening Guide Featured Image

This post will outline recommended steps to harden phpList after install to make it reasonably secure.

phpList is the most popular open-source software for managing mailing lists. Like wordpress, they have a phplist.com for paid hosting services and phplist.org for free self-hosting.

Earlier this week, it was announced that phpList had a critical security vulnerability permitting an attacker to bypass authentication and login as an administrator using an incorrect & carefully-crafted password in some cases. This bug is a result of the fact that [a] PHP is a loosely typed language and [b] the phpList team was using the '==' operator to test for equality of the user's hashed password against the DB. This security pitfall has been known in PHP since at least 2010 (a decade ago!), but I'm sure the same mistake will be made again..

Indeed, security is porous. There's no such thing as 100% vulnerability-free code, and phpList is no exception. But if we're careful in adding layers of security to our infrastructure, then we might be able to protect ourselves from certain 0-days.

That said, here's my recommended steps to making your phpList install reasonably secure.

Michael Altfield

Hi, I’m Michael Altfield. I write articles
. . . → Read More: Hardening Guide for phpList

Browsing without being tracked via Fingerprinting

Your browser aggrigates a *lot* of data about your computer, and it won't hesitate to provide all of this data to a nosy web site. In fact, if a website requests a large dataset of your computer's configuration, concatinates it together, and passes it through a hash function, the resulting hash can be farily unique.

This procedure can be done (and is done) on seperate websites to track users and their activity across multiple websites. If the same procedure [get data, concatenate, hash()] produces the same hash value when done on 2 seperate websites, the website can be fairly certain that you're the same user. This technique for tracking users is known as Browser Fingerprinting.

Just to get an idea of how effective this is, here's an excerpt from the above-linked article:

[The EFF] found that, over their study of around 1 million visits to their study website, 83.6% of the browsers seen had a unique fingerprint; among those with Flash or Java enabled, 94.2%. This does not include cookies!

You can test the uniqueness of your browser's "fingerprint" using this handy EFF tool.

There is a really great document descirbing techniques that could be used to prevent
. . . → Read More: Browsing without being tracked via Fingerprinting