What is SQL injection?¶
The practical answer¶
SQL injection is an attempt to manipulate a database query through input supplied to an application.
The key evidential caution¶
The dangerous assumption is that a suspicious parameter proves the database was compromised.
It does not.
An attacker may attempt to:
Key points¶
- bypass login
- read database records
- alter or delete data
- create accounts
- execute database functions
- interfere with the application
Evidence to preserve¶
Investigators should preserve:
Key points¶
- the exact request and parameter
- application and database logs
- response content
- error messages
- account or session details
- database queries where available
- data changes
- new accounts or exports
- follow-on activity
A request containing SQL-like syntax may be scanning, testing, malformed input or a genuine exploit attempt.
Success normally requires evidence that the application incorporated the input into a vulnerable query and that the database produced an unintended result.
Evidential limits¶
Do not rely only on a web response code.
A successful HTTP response may contain an application error.
Likewise, the absence of a visible database error does not exclude exploitation if the application suppresses errors.
Where data access is alleged, identify the records, query result or export rather than assuming the entire database was exposed.
Where authentication bypass is alleged, compare the request with normal application queries and session state. SQL injection may return one record, many records or only a true-or-false response. The scope of access should follow the actual database effect, not the theoretical capability of the payload.
That evidential boundary should remain explicit.
Operational takeaway¶
Separate injection attempt, vulnerable query execution and resulting database effect, and prove the scope of any data access or alteration.