No Sql Injection picoCTF 2024 Solution

Description

1. Step 1Submit crafted JSON

   Observation

   app/utils/database.ts drops the parsed request body straight into a MongoDB query without checking field types. Swap an operator object in where the password string should be and the check falls apart.

   Use the email from seed.ts and place {"$ne":"null"} as the password value. MongoDB interprets it as "password not equal to the string null," which every stored hash satisfies, so the check passes instantly.

   bash

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

   Copied!

   What didn't work first

   Tried: Send the $ne payload with the JavaScript null literal instead of the string "null", like {"$ne": null}.

   MongoDB distinguishes the null literal from the string "null". For comparison purposes a missing field counts as null, so {"$ne": null} matches only documents whose password field exists and is not null, quietly excluding any account that never had one. The string form compares against the four characters n-u-l-l instead, so every stored password hash passes with no schema assumptions. Driver versions also coerce payloads differently, so if one variant fails, try the other.

   Tried: Try a classic SQL injection string like ' OR '1'='1 in the password field instead of a JSON operator object.

   MongoDB is not relational and does not parse SQL. A classic ' OR '1'='1 arrives as an ordinary string, gets compared literally against the stored hash, and fails. The injection here means replacing a scalar with a JSON object holding a query operator, not smuggling in text from another query language.

   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 whose password is anything other than the string 'null'" - which matches 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

   Observation

   The login endpoint answers with JSON after the injection lands. Open the Network tab and read the token out of the response body.

   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

   Observation

   The token is base64, recognizable from its alphabet and trailing padding. Decode it.

   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!

   Expected output

   picoCTF{jBhD2y7XoNzPv_1YxS9Ew5qL0uI6pasql_injection_f2f1...}

   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.