Repository navigation
Sqli canary exfiltration - #331
Merged
Merged
Conversation
kOaDT
marked this pull request as ready for review
September 18, 2026 22:14
kOaDT
force-pushed
the
sqli-canary-exfiltration
branch
from
September 19, 2026 20:36
395b816 to
a242fb6
Compare
The four SQL injection routes each carried their own copy of the guard and of
the row filter. The sanitizer now matches on the OSS{ prefix instead of the
word "flag", which stops it from hiding sqlite_master output from the player
while still keeping flag values out of every response.
A SQL keyword in the header used to be enough, so the challenge taught payload recognition rather than exploitation. The endpoint now hides a per-instance canary in internal_secrets and echoes back the rows the request wrote, so the flag only drops once the player reads that canary out of the database through the INSERT sink.
Any SQL keyword in the search term used to be enough. The flag now requires a UNION SELECT that actually reaches the per-instance canary in internal_secrets, and the SQLite error is returned as-is so the column count can be worked out from the endpoint itself rather than guessed.
Dumping the users table through the status filter used to be optional: any SQL keyword handed the flag over. The flag now requires reading the per-instance canary out of internal_secrets, which means a nine-column UNION that actually lands, while the credential dump stays exactly as exploitable as before.
Storing a SQL payload as a display name was rewarded on sight, and the audit panel handed the same flag to anyone typing that payload into the query string. The flag now needs the canary from internal_secrets to come back through a filter value the reviews table actually holds, which is what makes the injection second-order in the first place.
A bare PATCH from a terminal used to earn the flag, so the challenge rewarded doing nothing at all. The flag now requires the browser metadata a page attaches on a victim's behalf, with a Referer that is not the admin dashboard, which the shipped proof-of-concept page already sends. The endpoint still updates the order for any caller: the missing CSRF protection is the vulnerability, not the flag condition. The walkthrough also claimed a top-level navigation would carry the cookie cross-site, which sameSite=lax only allows for safe methods.
db:seed alone fails once the table is dropped, it reads reviews before writing them. Players also need to know their captured flags survive the recovery.
kOaDT
force-pushed
the
sqli-canary-exfiltration
branch
from
September 20, 2026 19:23
a597ba9 to
1cb5de3
Compare
kOaDT
force-pushed
the
sqli-canary-exfiltration
branch
from
September 22, 2026 22:11
001e0ce to
dd883b5
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.