SQL Truncation

SQL truncation is an account takeover attack that exploits a mismatch between the length the application accepts and the length the database stores. It is not an SQL injection: no query is broken. The flaw is that the database silently truncates values exceeding the column length and, on top of that, strips trailing spaces.

The mechanics. Assume an email VARCHAR(20) column with a unique index, and a registration that validates "this email does not exist yet". The attacker wants to seize admin@book.htb:

1. They submit admin@book.htb + spaces + padding, e.g. admin@book.htb 123 (over 20 characters).
2. The application validation compares that string with the existing ones: it differs from admin@book.htb, so it passes the duplicate check.
3. The database truncates to 20 chars (admin@book.htb ) and trims trailing spaces, leaving admin@book.htb.
4. Since that email already exists, depending on configuration the row is overwritten (or a second indistinguishable "admin" is created), leaving the password under the attacker's control.

Detection hint. Any field that truncates input visibly (a name cut to N characters) suggests strict length limits in the schema. If the email or username behaves the same, truncation is a candidate. Confirm the limit by registering a value that, once truncated, collides with an existing account (the app returns a duplicate error).

Practical details. Panels usually reject spaces on the frontend; bypass it by sending the request with Burp and URL-encoded spaces (%20). Behaviour depends on the DBMS and its mode (MySQL in non-strict mode truncates without error; in strict mode it aborts).

Example payload

The target email, followed by spaces (which the database trims) and a filler character to exceed the column length (for example VARCHAR(20)):

curl -s -X POST http://<host>/register \
  --data-urlencode 'email=admin@book.htb                        a' \
  --data-urlencode 'password=hacked123'
# check the account takeover
curl -s -X POST http://<host>/login --data 'email=admin@book.htb&password=hacked123'

Defence. Validate length before reaching the database and reject (do not trim) anything exceeding it; enable the DBMS strict mode so truncation is an error, not a silence; normalise (trim) consistently in the application layer; use robust uniqueness constraints. Related to username enumeration (knowing which account to attack) and account takeover in general.