No Sql Injection picoCTF 2024 Solution

Description

1. Step 1Submit crafted JSON
   Use the email from seed.ts and place {"$ne":"null"} as the password value. MongoDB interprets it as "password not equal to null," instantly passing the check.
   bash

   {"email":"joshiriya355@mumbama.com","password":{"$ne":"null"}}

   Copied!
   Learn more

   NoSQL injection exploits the fact that document databases like MongoDB accept query operators as part of the data payload itself. When an API endpoint deserializes user-supplied JSON directly into a database query object, an attacker can inject operators such as $ne (not equal), $gt (greater than), or $regex to manipulate query logic.

   The $ne operator in MongoDB means "not equal to." Sending {"password": {"$ne": "null"}} transforms the login query from "find user where password equals X" into "find user where password is not null" - which matches virtually every real account. This is the NoSQL equivalent of the classic SQL OR 1=1 bypass.

   • The vulnerability requires that the backend passes unsanitized JSON directly to the MongoDB driver.
   • The fix is to validate and whitelist input types - if a password field should be a string, reject objects.
   • ORMs and query builders with parameterized queries prevent this; raw db.collection.findOne({...userInput}) does not.
2. Step 2Grab the token
   Inspect the /api/login response. It returns a JSON array with a base64-encoded token field.
   Learn more

   After a successful login, APIs typically return a token- commonly a JWT (JSON Web Token) or a simple base64-encoded payload - that the client attaches to subsequent requests to prove it is authenticated. Inspecting the raw response body in DevTools' Network tab (or with Burp) shows the exact structure.

   Base64 is an encoding, not encryption. It converts binary data into ASCII-safe text using 64 printable characters. It is trivially reversible and provides zero confidentiality - anything base64-encoded is effectively plaintext to anyone who looks at it. Seeing base64 in an API response is always worth decoding.

   JWTs have three base64url-encoded sections separated by dots: header, payload, and signature. Even without the secret key you can read the header and payload, which often contain user IDs, roles, and expiration times that reveal application logic.

3. Step 3Decode the flag
   Replace the placeholder token below with the actual base64 string from your /api/login response, then decode it with base64 -d (or CyberChef's From Base64 recipe) to recover the picoCTF flag.
   bash

   echo '<TOKEN_FROM_API_RESPONSE>' | base64 -d

   Copied!
   Learn more

   base64 -d is the standard Linux command for decoding base64 strings. The echo pipe feeds the encoded string as stdin. Note that base64 strings may include = or == padding at the end - this is normal and needed for correct decoding.

   CyberChef's From Base64 recipe is especially handy when the output is not clean ASCII (e.g., binary data or nested encodings), as it renders the result visually and lets you chain further operations like From Hex or Gunzip in a pipeline.

   This challenge is a good reminder that sensitive data should never be embedded in tokens without encryption. Even if the flag were intended to be revealed after login, encoding it in base64 gives the illusion of protection while providing none.

Flag

Decoding the token from /api/login yields the flag.