I Closed an Unauthenticated Bypass, Then Locked Out My Own Staff

The alert I was chasing had nothing to do with what I found. I was in the codebase for an unrelated ticket, tracing how staff sessions get verified on an internal admin tool, when I hit a line that made the whole page redirect logic stop mattering: if("login" == p) return;. That’s the login exemption, checked before the session check, and p is a raw query-string parameter. Append ?p=login to any tool URL and the gate returns without ever looking at whether you’re staff.

I didn’t take that on faith. I hit it live: an anonymous GET to a diagnostic tool with no cookies came back 302 to the login page, as expected. The same request with ?p=login appended came back 200, with 6,375 bytes of live database rows in the body, cart items with real IDs and statuses. Same bypass worked against a second, unrelated tool. Then I checked how many pages shared this gate: 103 files under tools/, another 122 staff pages outside it, 46 more under ajax/, all routed through the same SessionStaffVerifyRedirect() function. One missing check, one shared include, the entire internal admin surface open to anyone who knew the parameter name.

The exemption existed for a real reason: without it, the login page itself would redirect-loop, since rendering it also runs the session check that says you’re not logged in. But it was keyed on a value the client sends, not on anything the server actually controls. The fix was to stop trusting p and check the resolved path instead, session.pathInfo, which IIS sets from the actual file being served and which a query string can’t touch. Only default.asp, the login page itself, would get the exemption.

I patched a clone, then differential-tested it against the unpatched one side by side: patched tool with ?p=login now 302s to login; unpatched still leaks 200 and data. Login page itself still rendered fine. Shipped it as a hotfix, verified the bypass was closed on production the same hour, confirmed staff who were already logged in saw no change. Ticket closed, felt clean.

The guard didn’t know it was also blocking the door it guarded

Thirteen hours later, staff couldn’t log in. Not “session expired,” not a typo, actual login attempts, correct credentials, bouncing straight back to the login page with error=SessionExpired in the URL. I went to reproduce it and found I couldn’t log into the staff portal on any clone either, which is not something I’d normally suspect from a same-day hotfix, so I burned a few minutes wondering if it was a credential or cache issue before I looked at the actual response.

It wasn’t the credentials. A POST to the login handler with deliberately wrong credentials still came back 302 to error=SessionExpired instead of reaching the actual authentication function. The guard was firing before AuthenticateStaff ever ran, meaning the password was never even checked. My path-based fix from earlier that day only exempted default.asp, the page that renders the login form. But the form doesn’t POST to default.asp. It posts to /ajax/login.asp, a different file, which runs through the exact same SessionStaffVerifyRedirect() on the way in. I’d fixed the render and broken the submit, because I’d reasoned about “the login page” as one thing when it was two files sharing one gate, and I only checked one of them.

Nobody had been locked out yet when I found it because anyone with an existing session was unaffected, staff who’d logged in before the hotfix just kept working. It was quiet by luck, not because it was working.

The fix was the same shape as the first one, just wider: exempt both default.asp and ajax/login.asp by path, still keyed off session.pathInfo, still not spoofable by a query param. I verified it the same way as before: a bad-credentials POST now correctly reached AuthenticateStaff and came back error=invalidLogin instead of SessionExpired, a real staff login succeeded end to end, and the original ?p=login bypass on an unrelated tool still redirected, no regression. Verified live on prod before calling it closed, the same way I’d verified the hole in the first place, because “I’m pretty sure” was exactly the assumption that put me here.

The mistake wasn’t skipping a test. It was treating “authenticate before serving” as one rule when the real rule is per-entry-point: every path that reaches the auth gate needs its own accounting of what it’s supposed to do when there’s no session yet, including the one thing whose whole job is to create one.

dxdev LESSON · paste into your AI coding agent
LESSON: Account For What Every Entry Point Does Without A Session, Including The One That Creates Sessions
SOURCE: dxdev.com/blog/2026-09-07_the-security-fix-that-broke-the-front-door
WHAT HAPPENED: While working an unrelated ticket, the author found that a login exemption keyed on a raw query-string parameter let anyone append ?p=login and skip the staff session check, returning live database rows with a 200. The same gate was shared by 103 tool files, 122 other staff pages, and 46 ajax files. The author patched the gate to key on the server-resolved path, differential-tested it, shipped it, and verified it on production. Thirteen hours later logins failed with error=SessionExpired, because the form posts to /ajax/login.asp, a second file behind the same gate that the patch had not exempted. Staff with existing sessions were unaffected, so the breakage stayed quiet by luck. The follow-up exempted both files by path and was verified live with a bad-credentials POST, a real login, and a recheck of the original bypass.
THE RULE: Treat authentication as a per-entry-point rule, not one global rule. Every path that reaches the auth gate needs its own accounting of what it should do when no session exists yet, especially the paths that create sessions.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. List every file or route that passes through the shared auth gate, and confirm each one has a documented and tested behavior for an unauthenticated request.
      2. Confirm any auth exemption is keyed on a server-resolved value such as the actual served path, never on a client-supplied parameter.
      3. After an auth change, test the full login flow end to end with both bad and good credentials on a fresh session, not only the page that renders the login form.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.