Exploit SQL Injection
Goal
Determine whether user-controlled input can alter SQL query logic in a way that changes access, data, or behavior.
Assumptions
- one or more endpoints send untrusted input to a database layer
- query construction may not be safely parameterized everywhere
- secondary features are often weaker than primary flows
Prerequisites
- endpoints with user-controlled input
- ability to replay and compare requests
- safe test environment and authorization to probe
Recon steps
- Map all user-controlled inputs: query params, forms, JSON, cookies, headers.
- Look for filtering, sorting, search, exports, and admin-only features.
- Note error behavior, timing, and content changes.
Exploit / test steps
- Send simple syntax probes to detect parser influence.
- Test boolean and timing differences where appropriate.
- Compare success/failure behavior across endpoints.
- Probe less obvious inputs like headers, hidden params, or mobile/API routes.
- Confirm whether the issue is read-only, auth bypass, or broader query control.
Validation clues
- SQL errors or stack traces
- content differences under boolean conditions
- measurable timing differences
- auth or data access behavior changes unexpectedly
Mitigation
- parameterize queries consistently
- avoid raw string concatenation
- constrain DB privileges
- review query-building helpers and ORMs for unsafe escape hatches
- monitor suspicious query patterns safely
Logging / detection
- repetitive syntax-like probes
- abnormal query timing patterns
- errors around query parsing or type coercion
Related notes
References
- Testing / Lab: PortSwigger SQL injection topic — https://portswigger.net/web-security/sql-injection
- Foundational: OWASP Top 10 Injection — https://owasp.org/Top10/2021/A03_2021-Injection/
- Foundational: OWASP WSTG — https://owasp.org/www-project-web-security-testing-guide/latest/