[superasn]

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.

[bananamogul]

“And the best code in this case is code you didn't write as PHP's session handler is battle-tested”

cPanel is written in perl.

[superasn]

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.

[hparadiz]

PHP has built in session handling and the ability to store them to local, in memory, RDBMS database, or you can implement SessionHandlerInterface, SessionIdInterface with your own custom class.

It's probably the most battle hardened session system ever.

[shawnz]

cPanel is 30 years old, are you saying it's not battle tested, boring, proven, and widely audited?

In fact PHP is only a few months older than it.

[ChrisMarshallNY]

30 years isn't really a good thing, here.

I've been coding for more than 40 years, and I probably only took security seriously, in the last 25 or so.

In fact, in Ye Days of Yore, we often deliberately coded in unsecured stuff, for convenience.

Look at some of the old Apple Systems (pre-OS X), to see some stuff that would make secops people defecate masonry.

[ryandrake]

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.

[xyzzy_plugh]

I tend to agree and I often strongly recommend to my clients to choose battle tested off-the-shelf solutions for these problems rather than roll their own, but...

Sometimes it makes sense to roll your own and the cost of a dependency isn't worth it. This can be especially true when you need to accommodate many bespoke environments and you end up needing to make little accomodations here and there. Can create a very unpleasant situation when you don't own the code.

I'm not a cryptographer but I've spent a significant portion of my career focusing on the security-side of things and I've rolled my own auth quite a few times on very public projects you can access today and I've never had any significant findings through repeated pentests.

But that's just the thing: I did it the right way, and there is a right way to roll your own stuff, to forge it in a way it comes out suitable. Is it bug free? Probably not, but I feel significantly better about it having thoroughly tested it by myself, my colleagues and paid professional penetration testers.

I couldn't easily find an answer but I'd like to know if this implementation has been validated by a professional or not.

[TZubiri]

But it's not the same thing every time, for example if you had written 'your own' http request you wouldn't habe been hit by the axios vuln.

If you rolled your own crypto and didn't install AF_ALG, you would have avoided copy fail.

Even in this case if you had implemented your own control panel, you wouldn't be hit.

Actually roll your own, don't add dependencies

[christophilus]

Well, I tend to fall on your side of this, but doing this probably means you’re equally or more insecure and just won’t know it until you’re hacked. That said, I have written my own auth and session layers numerous times. My needs are generally simple, so getting it correct isn’t too hard.

When you pull in a generic auth or session library, you pull in a “can do everything” module rather than a “can do this one specific thing” module. So, your attack surface grows as do your odds of misconfiguration.

[londons_explore]

I doubt the mantra of "don't roll your own Auth/crypto" - especially if it lives on a server where the code can't be inspected.

Sure, there will be more bugs in my code, but the attackers will be putting far more scrutiny into a widely used library.

Some deliberately hilariously weak auth I built decades ago is only just now starting to get broken into by AI bots, whereas any vulnerable wordpress was broken into within days.

[Ekaros]

Thinking of use cases where services I build have reasonably low internal userbase. Maybe rolling out own is not worst choice always. After all it leads to manual or at least targeted work by attackers. Instead of very common spraying stuff randomly. So risks might in the end be lower.

[cestith]

There are well over a million cPanel/WHM installations in the world.