Everytime I read one of these it always boils down to the same thing..Don't solve solved problems. And the best code in this case is code you didn't write as PHP's session handler is battle-tested but every line you write to roll your own is a line you have to secure, maintain, and eventually patch at 2am when someone finds the bug.
Session handling, auth, crypto, password hashing etc - all these are the exact areas where you should be the most allergic to rolling your own. Not because you're not smart enough, but because a simple bug like sanitizing in the wrong place and the failure is catastrophic like in this instance.
Use boring, proven, widely-audited solutions. Save your creativity for the actual problem you're solving.
Oh you're right to push back. I just love saying this nowadays :P Anyway, I haven't used these languages in a long time but the code looked like php to me, though I did notice the .pm file extension and wondered where I've seen it before.
I don't even know why you'd want to re-implement this stuff, too. It's not exciting or sexy work. It's like time parsing, time zone handling, leap years... Why would you want to inflict that on yourself? You will 100% not handle every edge case, and you will 100% get time and time zone handling bugs.
Oooooh that's really bad. Wordpress on Cpanel sites is like the Dark Matter of the internet, it's everywhere and you don't see it until something bad happens. Libations for the sysadmins patching & cleaning up this mess.
I like how the vulnerability is in the path that (a) attempts to write the password in reversibly encrypted form to disk [0] and (b) has a weird fallback path that writes it in clear text. Sigh.
[0] cPabel seems to be from 1996. We’ve known this is a mistake since before 1996.
I used to help nonprofits and small businesses build websites. Process always went like 1. buy domain, 2. buy a shared hosting provider that one-click-installs Wordpress, 3. use a theme to begin editing the website. Often, I would also use the email included with that hosting provider for the firm.
ALL of that goes through cpanel, for every shared hosting provider I can ever remember using. Even if the stuff happening on those servers didn't use perl, cpanel itself -- the admin of everything provided for that domain by the hosting provider -- it's a huge surface area.
Something that is starting to concern me with the flood of cyber chaos in the past couple of months is my homelab. Currently I do not have it set up to be accessible outside the local network and then add it and all my other devices to my tailnet to facilitate remote access (via an exit node on my local network). On top of that TrueNAS doesn't seem to have the best update cadence so I'm worried about having a system with known vulnerabilities only protected by not being accessible remotely in theory.
Session handling, auth, crypto, password hashing etc - all these are the exact areas where you should be the most allergic to rolling your own. Not because you're not smart enough, but because a simple bug like sanitizing in the wrong place and the failure is catastrophic like in this instance.
Use boring, proven, widely-audited solutions. Save your creativity for the actual problem you're solving.
cPanel is written in perl.
In fact PHP is only a few months older than it.
[0] cPabel seems to be from 1996. We’ve known this is a mistake since before 1996.
ALL of that goes through cpanel, for every shared hosting provider I can ever remember using. Even if the stuff happening on those servers didn't use perl, cpanel itself -- the admin of everything provided for that domain by the hosting provider -- it's a huge surface area.
https://copy.fail
yikes. https://www.shodan.io/search?query=basic+realm%3D%22cPanel%2...