GPT on Question 19, Sep 26

SQL injection (SQLi) occurs when untrusted input is interpreted as part of a SQL command rather than strictly as data.

Main classes

• 1.In-band SQL injection
  The attacker sends input and receives results through the same application channel.
• •UNION-based: Combines attacker-chosen queries with the application’s original query to expose other data.
• •Error-based: Intentionally triggers database errors that reveal schema, query, or data details.

• 2.Blind / inferential SQL injection
  The application does not directly display database results, so information is inferred indirectly.
• •Boolean-based: Application behavior changes depending on whether an injected condition is true or false.
• •Time-based: Database delays are used to infer whether conditions are true.

• 3.Out-of-band SQL injection
  Data is returned through a different channel, such as a database-triggered DNS or network request. This is less common and depends on database privileges and network access.

• 4.Stacked-query injection
  If the driver or database accepts multiple statements in one call, attacker input may append an additional command, potentially modifying or deleting data.

• 5.Second-order / stored SQL injection
  Malicious input is stored safely at first but later inserted unsafely into another SQL query. Validation only at initial entry does not prevent this.

Common injection contexts

SQLi is not limited to string values. It can occur in:

• •Login and search fields
• •Numeric IDs
• •ORDER BY, column names, or table names
• •LIMIT/pagination values
• •Dynamic filters and report builders
• •JSON or API parameters
• •Stored procedures containing dynamic SQL
• •ORM “raw query” or string-interpolation features

What developers should do

• •Use parameterized queries/prepared statements for every data value.
• •Never build SQL using concatenation, interpolation, or template strings.
• •For identifiers or sort directions that cannot be parameterized, use a strict allowlist mapping.
• •Avoid dynamic SQL inside stored procedures; parameterize it when unavoidable.
• •Apply least-privilege database accounts and separate read/write roles where practical.
• •Return generic client errors; log detailed database errors securely.
• •Treat stored data as untrusted when it is later used in queries.
• •Add automated SQLi tests and use code review/static analysis to find raw query construction.
• •Treat escaping as a last-resort, database-specific measure—not a substitute for parameters.

A safe pattern is conceptually:

SELECT * FROM users WHERE email = ?

with the email supplied separately through the database API, rather than inserted into the SQL text.