GPT on Question 18, Sep 16

SQL injection (SQLi) occurs when untrusted input changes the structure of a SQL statement rather than remaining data. A useful developer briefing separates how injection happens from how an attacker observes results.

Main classes

• 1.In-band SQLi
  The application returns results through the same request/response channel.
• •Error-based: Database errors reveal schema, query, or data details.
• •Result-set/UNION-based: Manipulated queries cause attacker-selected data to appear in normal output.

• 2.Blind or inferential SQLi
  The application does not directly display database output, but behavior reveals whether a condition is true.
• •Boolean-based: Differences in page content, status, or response behavior indicate true/false.
• •Time-based: Deliberate database delays make conditions observable through response timing.

• 3.Out-of-band SQLi
  The database is induced to communicate through a different channel, such as a network lookup or outbound request. This depends on database features and network egress permissions.

• 4.Second-order SQLi
  Malicious-looking input is stored safely at first, then later retrieved and concatenated into a different dynamic query. Validation only at initial entry does not prevent this; every SQL execution point must use safe parameterization.

• 5.Stacked-query injection
  Where the driver and database allow multiple statements, injected input can append additional SQL operations. Support varies by platform and configuration.

• 6.SQL injection in non-value contexts
  Parameters usually protect values, but developers often dynamically construct:
• •table or column names
• •sort direction and ORDER BY fields
• •operators
• •pagination or query fragments

These must be selected from strict allowlists, not merely escaped.

Common root causes

• •String concatenation or interpolation in SQL
• •“Escaping” used instead of parameterized queries
• •Dynamic SQL inside stored procedures
• •Unsafe ORM escape hatches or raw-query APIs
• •Reusing stored data in later query construction
• •Excessive database permissions
• •Detailed database errors exposed to users

Core defenses

• •Use prepared statements/parameterized queries everywhere values enter SQL.
• •For identifiers or structural options, map user choices to a fixed allowlist.
• •Avoid dynamic SQL; if unavoidable, parameterize within it.
• •Apply least privilege to application database accounts.
• •Disable unnecessary multi-statement, filesystem, and outbound-network capabilities.
• •Return generic client errors while retaining detailed server-side logs.
• •Add code review rules and static analysis for raw SQL construction.
• •Test all inputs, including headers, cookies, JSON fields, stored values, and background-job data.

A key message for developers: input validation is helpful for business rules, but it is not the primary SQLi defense—separating SQL code from data through parameterization is.