1. Introduction
Blind SQL Injection (timing attack) is a web security vulnerability that allows an attacker to infer information about a database by observing the time it takes for the server to respond to different queries. This can allow attackers to steal data, modify data or even take control of the underlying server. Web applications using databases are commonly affected. Successful exploitation could lead to loss of confidentiality, integrity and availability of sensitive data.
2. Technical Explanation
Blind SQL Injection occurs when user-supplied input is used in a SQL query without proper sanitisation. This allows an attacker to inject malicious SQL code that may not directly return data but can be detected by observing the server’s response time. A timing attack exploits this by injecting queries designed to cause delays based on conditions being true or false, allowing attackers to deduce information about the database structure and content.
- Root cause: Lack of input validation and parameterized queries when constructing SQL statements.
- Exploit mechanism: An attacker sends crafted requests containing SQL injection payloads that induce time delays based on the truthiness of conditions within the query. By analysing these response times, they can infer data from the database. For example, an attacker might inject a payload like `’ AND 1=(SELECT 1 FROM users WHERE username=’admin’)–` which will cause a delay if a user named ‘admin’ exists.
- Scope: Web applications using databases such as MSSQL, MySQL, Oracle etc are affected.
3. Detection and Assessment
To confirm vulnerability, first check application code for use of parameterized queries. Thorough assessment can be done with automated scanners.
- Quick checks: Review web application source code to identify database interaction points and verify the use of parameterized queries or prepared statements.
- Scanning: Use a web application scanner like OWASP ZAP, Burp Suite, or Nessus with SQL injection detection enabled. These scanners will attempt to inject payloads and detect time-based responses.
- Logs and evidence: Examine web server logs for unusual query patterns or slow response times associated with specific user inputs. Look for error messages related to database queries.
# Example command placeholder:
# No direct command available, check application source code and web server logs.
4. Solution / Remediation Steps
The only proven method is to use parameterized queries. This ensures all user input is treated as data, not executable SQL code.
4.1 Preparation
- Consider a change window for deployment to minimise disruption. A roll back plan should include restoring from backup if necessary.
4.2 Implementation
- Step 1: Identify all locations in the application code where SQL queries are constructed using string concatenation or user-supplied input directly.
- Step 2: Replace these constructions with parameterized queries (prepared statements). Most database libraries provide built-in support for this feature.
- Step 3: Test each change thoroughly to ensure that the application functionality remains intact and no new vulnerabilities are introduced.
4.3 Config or Code Example
Before
query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'"After
query = "SELECT * FROM users WHERE username = ? AND password = ?"
cursor.execute(query, (username, password))4.4 Security Practices Relevant to This Vulnerability
- Least privilege: Grant database users only the minimum necessary permissions required for their tasks.
4.5 Automation (Optional)
No automation is available, as this requires code changes.
5. Verification / Validation
Confirm that parameterized queries are used and re-test with a scanner to verify the vulnerability is resolved.
- Post-fix check: Review application source code again to confirm all vulnerable constructions have been replaced with parameterized queries.
- Smoke test: Verify that users can still log in, access data, and perform other core functions of the application without issues.
- Monitoring: Monitor web server logs for error messages related to database queries. Set up alerts for unusual query patterns or slow response times.
# Example command placeholder:
# No direct command available, check application source code and scanner results.
6. Preventive Measures and Monitoring
- Baselines: Update the web application security baseline to include a requirement for using parameterized queries or prepared statements.
7. Risks, Side Effects, and Roll Back
Incorrect implementation of parameterized queries can introduce new bugs or performance issues. Restore from backup if necessary.
- Risk or side effect 1: Incorrectly implemented parameterized queries may not fully protect against SQL injection vulnerabilities.
- Roll back: Restore the web application and database from the pre-change backup.
8. References and Resources
- Vendor advisory or bulletin: N/A – This is a general coding practice issue, so no vendor specific advice exists.
- NVD or CVE entry: http://projects.webappsec.org/w/page/13246963/SQL%20Injection
- Product or platform documentation relevant to the fix: http://www.w3schools.com/sql/sql_injection.asp