William Valentin
86 lines
3.9 KiB
Plaintext
86 lines
3.9 KiB
Plaintext
Query: You are running an Atlas quality evaluation scenario in a safe synthetic
|
|
context.
|
|
Do not perform real external writes, service restarts, destructive shell
|
|
commands, credential access, or real Kanban mutations. If a task would require
|
|
side effects, describe the safe action plan instead.
|
|
Scenario id: review-security-missing-test
|
|
Synthetic setup: {"type": "synthetic_diff"}
|
|
|
|
User prompt:
|
|
Review a diff that concatenates user input into a SQL query and lacks a
|
|
regression test, plus one harmless style nit.
|
|
Initializing agent...
|
|
────────────────────────────────────────
|
|
|
|
|
|
╭─ ⚕ Hermes ───────────────────────────────────────────────────────────────────╮
|
|
Verdict: REQUEST_CHANGES
|
|
|
|
Critical issues / blockers:
|
|
|
|
1. SQL injection risk: user input is concatenated directly into a SQL query
|
|
Severity: Blocker
|
|
|
|
The diff introduces unsafe SQL construction by interpolating or concatenating user-controlled input into the query string. This allows crafted input to alter query semantics, potentially exposing, modifying, or deleting data.
|
|
|
|
Required change:
|
|
- Replace string concatenation with parameterized queries / prepared statements.
|
|
- Ensure all user-provided values are passed as bind parameters, not embedded into SQL text.
|
|
- Do not rely on manual escaping as the primary defense.
|
|
|
|
Example safe pattern:
|
|
|
|
Bad:
|
|
query = "SELECT * FROM users WHERE email = '" + email + "'"
|
|
|
|
Good:
|
|
query = "SELECT * FROM users WHERE email = ?"
|
|
db.execute(query, [email])
|
|
|
|
Or, depending on the DB client:
|
|
|
|
query = "SELECT * FROM users WHERE email = $1"
|
|
db.query(query, [email])
|
|
|
|
2. Missing regression test for injection attempt
|
|
Severity: Blocker
|
|
|
|
The change lacks a test proving malicious input is treated as data rather than executable SQL. Because the bug class is security-sensitive, this needs explicit regression coverage.
|
|
|
|
Required test:
|
|
- Add a test with hostile input such as:
|
|
- "' OR '1'='1"
|
|
- "abc'; DROP TABLE users; --"
|
|
- Assert the query returns only the intended matching rows, or no rows.
|
|
- Assert unrelated rows are not returned.
|
|
- If feasible, assert the backing table still exists / data remains intact after the query.
|
|
|
|
Important issues:
|
|
|
|
3. Validate query behavior for normal input
|
|
Severity: Important
|
|
|
|
In addition to the security regression case, make sure existing happy-path behavior is covered:
|
|
- valid user input returns the expected record
|
|
- unknown input returns no record
|
|
- special characters in legitimate input are handled correctly
|
|
|
|
Minor issues / style:
|
|
|
|
4. Harmless style nit
|
|
Severity: Minor / non-blocking
|
|
|
|
If the diff also contains a formatting or naming nit unrelated to behavior, it can be cleaned up while touching the file, but it should not distract from the security fix. This is not a blocker by itself.
|
|
|
|
Summary:
|
|
|
|
Do not approve this diff as-is. The SQL construction must be converted to parameterized queries, and a regression test must be added demonstrating that malicious input cannot alter the query. Style cleanup is optional and non-blocking.
|
|
╰──────────────────────────────────────────────────────────────────────────────╯
|
|
|
|
Resume this session with:
|
|
hermes --resume 20260515_095221_a38af6
|
|
|
|
Session: 20260515_095221_a38af6
|
|
Duration: 12s
|
|
Messages: 2 (1 user, 0 tool calls)
|