HTB: Baby-Auth
The BabyAuth challenge on Hack The Box represents an entry-level web security exercise aimed at sharpening fundamental offensive skills in authentication bypass and web application logic flaws. Positioned as an introductory task, it invites participants to think critically about how modern authentication mechanisms are implemented — and how subtle misconfigurations can undermine them. While designed for beginners, the challenge subtly incorporates real-world patterns, making it both educational and relevant for aspiring penetration testers and security researchers.
The challenge presents a minimalistic web interface that appears to implement basic authentication functionality. At first glance, it offers a straightforward login form, but closer inspection reveals that it suffers from insecure implementation choices. Participants are tasked with identifying and exploiting weaknesses in how authentication is handled — potentially involving flaws such as weak session validation, improper logic in token verification, or manipulation of request headers. The goal is to bypass authentication controls and gain access to a restricted flag or dashboard, using careful observation and exploitation of web logic vulnerabilities.
First, I try logging in using some common default credentials like:
admin:admin or admin:password — but yeah, as expected, they don’t work.
Now the question is — what do we actually have to work with?
We notice there’s a “Create Account” option — so I go ahead and try to register a new account
I first try to register with the username admin, just to see what happens — but it tells me that the user already exists.
But this is useful — it confirms that admin is a real user in the system.
So next, I successfully register a regular account like:
Username: test
Password: user
Now at this point, you might think — should we brute-force the admin password?
Technically, yeah we could… but in the real world, this would take time, might not work, and could get our IP blocked by the server.
Instead, let’s see what’s going on behind the scenes.
Using Burp Suite, I intercept the request after logging in and take a look at the PHPSESSID cookie.
When we decode it from Base64, we find it’s actually a small JSON object that looks like this:
So… the session cookie is storing our username directly inside it. That’s a big security issue.
Now since we know admin is a valid user, we try something simple — change:
Nothing on this page caught my attention. I therefore made the decision to examine the background activity using Burp Suite. I discovered an interesting cookie while I was proxying the traffic.
We encode it back into Base64, replace the cookie in our browser, resend the request.
