Blog

Security vulnerabilities are rarely usually not as simple as a view executing a query param against the database. More often, they're comprised of multiple steps, forming a chain from crafted input to intermediary to - gotcha!

It takes thorough understanding of the code base and adopting the mindset of an attacker. Putting various subsystems together in unintended ways to yield disastrous consequences.

Sometimes, it just takes a little curiosity - this can't possibly work, right?

Whose MFA is it anyway?

At one company, we built support into the application for MFA - multi factor authentication - via SMS. When a user attempts to log in, they are authenticated, but have a flag in their session that MFA has not been validated, preventing them from taking any actions.

All's well and good. Mostly. There's a itch behind my knee that I just can't manage to scratch. Session management is tricky to get right. Especially when developers write their own authentication logic, instead of using the platform or library defaults.. which was the case here.

Looking at the authentication code for the tenth time, I asked myself if it were possible to set a value in a session and keep it after login. If I could set "mfa validated" to true in my session, and then login, I'd bypass MFA. How could I do that though?

Ah, right. I could sign in with a separate account, for which I can validate the MFA. If I then try to sign in on top of that, I could keep the session and bypass MFA for the second account.

Can't possibly work, right? It does! The bug lied in the session regeneration code after login. Instead of generating a brand new session, the user inherited the existing session and was authenticated on top of it. Truly "multi" factor - use any additional factor 🤓

The Great Merge

At another company (what a long career 🫠), I went vulnerability hunting when I joined. I cannot believe that this works at every company. Seriously, if you want to shine before performance reviews, do a lookup for common escape hatch code (xss escaping disabled, csrf exempt view, etc.). Developers are lazy by nature and happily commit dangerouslySetInnerHTML={untrustedInput} before rushing to clock out. The more pickins' for me.

In my search I found several csrf exempt views. Most were fairly benign, uninteresting customer endpoints seemingly due to trouble with ajax requests. Again, rather than configure csrf protection correctly, developers chose to disable it. ¯\_(ツ)_/¯

One view that stood out to is the internal tool to merge customers. You know, customer signs up with email address A and then forgets and signs up with email address B, and gets all mixed up so the customer support team merges the accounts to settle the issue.

Now, missing csrf protection is not enough in 2025. By default, the major browsers will treat cookies as same site lax, which basically means "no cookie for you" for POST requests from other domains.

Now, developers could not possibly have disabled same site cookie protection, right? Say, explicitly set same site "none" so that "yes take this cookie please"? Oh yes, they did. In order to handle some arcane single sign on flow, which used POST to provide auth creds, developers had disabled same site protection. Chain complete!

Almost. Internal tools use uuids to refer to objects. So even with same site cookie and csrf protection disabled, I'd have to figure out the relevant uuids of customers to actually do anything. Did I really come this far to fail?

Of course not, or I wouldn't be writing about this (though the cookie story is a good one in its own right). The customer merge tool uniquely does not accept uuids but integer ids. Cha-ching. I can easily merge customers together by guessing ids. Or incrementing ids..

If I can count incremental ids, why don't I do that on repeat - merge customer 2 into 1, 3 into 1, 4 into 1, and so on: I could merge every single customer into a single super customer! 🚀

I never did try this in practice (a sudden database restore would not have pleased the higher ups), but it remains a fun thought experiment.

More to come

I'm finding this quite cathartic. I derive pride and pleasure from finding and fixing vulnerabilities. I may dig a little deeper in the memory and write some more.