← Back to practice

Intigriti September Challenge · SQL injection · Resolved · Medium

Base64-wrapped SQL injection

The gallery accepted a Base64 value in its pic parameter. After decoding it, the application placed the result into a MySQL query without parameterization.

Finding the input path

A normal request used a value such as pic=Zm94, which decodes to fox.

Encoding changes the representation of input, not its meaning. I tested the decoded value as a database input and found that SQL operators still reached the query.

Confirming SQL injection

I Base64-encoded a simple true condition:

' OR '1'='1

The response rendered every critter description instead of a single record. That showed the decoded value was being interpreted as SQL rather than compared as ordinary data.

Following the database

I used one-column UNION SELECT queries to follow the data:

  1. version() identified MySQL 8.0.46.
  2. information_schema.tables revealed the application tables.
  3. information_schema.columns revealed the secret table’s columns.
  4. Selecting its note field returned the challenge flag.
' UNION SELECT note FROM secret_vault --

The same value sent in pic was Base64-encoded and then URL-encoded for the request.

Impact and result

The public gallery endpoint allowed read-only SQL execution, schema enumeration, and access to data outside the intended animal records. Intigriti closed the challenge report as resolved at medium severity.

What should change?

  • Use prepared statements with bound parameters for the gallery lookup.
  • Allow only known critter identifiers after decoding.
  • Give the gallery database account access only to the data it needs.
  • Do not expose database errors or unrestricted query results.