Conversation
Our SQL injection detection tokenizes queries to check them. If the tokenizer can't parse a query, we skip it and the query goes through. Some databases still execute partially valid queries though: ClickHouse ignores junk after ; and SQLite runs everything before an unclosed /*. Now when user input shows up in a query we can't tokenize, we treat it as an attack. On by default, opt out with AIKIDO_BLOCK_INVALID_SQL=false.
![aikido-pr-checks[bot]](https://avatars.githubusercontent.com/in/898896?s=60&v=4){kind=small}
| "payload": user_input, | ||
| } | ||
|
|
||
| if result == 3 and should_block_invalid_sql_queries(): |
There was a problem hiding this comment.
Two branches build and return nearly identical SQL injection result dicts (operation, kind, source, pathToPayload, metadata.sql, metadata.dialect, payload). Consolidate into a single helper to avoid duplicated response construction.
Details
✨ AI Reasoning
The new code adds two conditional branches that both construct and return a very similar dictionary describing a detected SQL injection. Both branches set the same keys: operation, kind, source, pathToPayload, metadata with sql and dialect, and payload. The second branch adds only one extra metadata field failedToTokenize. This repeats nearly identical business-logic for building the result object in two places, increasing maintenance burden: any future change to the shape of the result would need to be applied in both branches and could lead to inconsistent responses.
🔧 How do I fix it?
Delete extra code. Extract repeated code sequences into reusable functions or methods. Use loops or data structures to eliminate repetitive patterns.
Reply @AikidoSec feedback: [FEEDBACK] to get better review comments in the future.
Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info
Backslash escapes are MySQL-specific, so the unterminated string caused by a trailing backslash only fails tokenization in MySQL.
The test helpers now check specific return codes (1 for injection, 3 for failed tokenization, 0 for no injection) instead of boolean equality. Invalid SQL tests use a dedicated is_invalid_sql helper.
1 participant
Our SQL injection detection tokenizes queries to check them. If the tokenizer can't parse a query, we skip it and the query goes through. Some databases still execute partially valid queries though: ClickHouse ignores junk after ; and SQLite runs everything before an unclosed /*.
Now when user input shows up in a query we can't tokenize, we treat it as an attack. On by default, opt out with AIKIDO_BLOCK_INVALID_SQL=false.
Summary by Aikido
🚀 New Features
⚡ Enhancements
More info