Featured Articles

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

Ephemeral Firefox as a Site-Specific Browser (3/3)

Site-Specific Ephemeral Firefox featured image showing a firewall between the facebook and firefox icons

This article is a part 3/3 of a series describing how to setup an Ephemeral Firefox session as a Site-Specific Browser. The ultimate goal is to be able to have a self-destructing browsing session that can only access a single company’s services, such as Google or Facebook.

Part 1/3: Ephemeral Firefox in Ubuntu Part 2/3: Ephemeral Firefox with Extensions Part 3/3: Ephemeral Firefox as a Site-Specific Browser

After setting up the Site-Specific Ephemeral Firefox Browser, you can then blacklist services designated to your Site-Specific browser(s) (such as Google or Facebook) from your main browser. This significantly improves your ability to browse the internet without your activity being tracked by these companies — leaving your sensitive data vulnerable to being stolen by hackers.

Michael Altfield

Hi, I’m Michael Altfield. I write articles about opsec, privacy, and devops ➡

About Michael


. . . → Read More: Ephemeral Firefox as a Site-Specific Browser (3/3)

Ephemeral Firefox with Extensions (2/3)

icon of ephemeral firefox with icons of popular extensions below it

I recently posted about how to create a sandboxed firefox profile to compartmentalize (and shred) your firefox browsing history in an Ephemeral Firefox session. But so far I’ve only covered how to create a simple vanilla firefox profile. What if you want your Ephemeral Firefox to include a few basic extensions?

This post will cover how to add extensions to your Ephemeral Firefox profile.

Part 1/3: Ephemeral Firefox in Ubuntu Part 2/3: Ephemeral Firefox with Extensions Part 3/3: Ephemeral Firefox as a Site-Specific Browser Michael Altfield

Hi, I’m Michael Altfield. I write articles about opsec, privacy, and devops ➡

About Michael


. . . → Read More: Ephemeral Firefox with Extensions (2/3)