Breaking the
Critter Gallery

The target is /challenge.php — a small animal gallery with eight critters and no forms anywhere. Every tile links to itself with one parameter: ?pic=Zm94. Decode Zm94 and you get fox. So the server takes my value, base64-decodes it, and does something with it. That "something" is the whole challenge.

Worth remembering: base64 is encoding, not protection. It hides the value from a casual glance, nothing more. Try it:

Sending the real value fox renders a detail card — emoji, name, description. So some server-side code looked that name up.

First I checked the reflection: send <h1>test</h1> as the name and the page prints it back encoded — so no XSS there. But the value has to go somewhere. Next move: add a quote and see who complains.

The result was clean: fox' → the page comes back completely empty. fox'' → normal page. Odd quotes break it, even quotes survive. That's a SQL error with display_errors turned off — my input is landing inside a SQL string.

If the name really ends up in a SQL WHERE clause, I can change what the query returns. This payload closes the quote, adds OR '1'='1' (always true), and comments out the rest. I asked for a critter called x — the page showed me the fox, the first row in the table.

UNION SELECT appends my own row to the query's result, but the column count has to match the original query. So I swept it: UNION SELECT '1', then '1','2', and so on. The number of columns I can inject shows up right in the description box.

Here only one column works. Everything else crashes the query. One is all I need.

MySQL keeps a catalog of itself in information_schema, readable by default. With GROUP_CONCAT I can pull whole lists in a single request instead of one value at a time. Three questions: which database, which tables, which columns.

One injectable column, one target table. Pick what the query should answer below and send it — the last option is the one that ends the CTF.

The bug is one line: the decoded value was concatenated straight into the query. Base64 looked like a defense but wasn't one — decode is not sanitize. A prepared statement makes the whole thing impossible:

// challenge.php
$name = base64_decode($_GET['pic']);

$sql = "SELECT description FROM animals
        WHERE name = '" . $name . "'";
// decoded ≠ safe. 💥

$stmt = $pdo->prepare(
  "SELECT description FROM animals
   WHERE name = ?");
$stmt->execute([
  base64_decode($_GET['pic'])
]);
// + allow-list the 8 critter names
// + generic error page instead of blank 200