{"id":2675,"date":"2025-01-09T09:12:44","date_gmt":"2025-01-09T09:12:44","guid":{"rendered":"https:\/\/www.hackmosphere.fr\/how-to-obtain-a-time-based-blind-sql-injection-and-automate-by-modifying-sqlmap\/"},"modified":"2025-01-09T09:13:28","modified_gmt":"2025-01-09T09:13:28","slug":"how-to-obtain-a-time-based-blind-sql-injection-and-automate-by-modifying-sqlmap","status":"publish","type":"post","link":"https:\/\/www.hackmosphere.fr\/en\/how-to-obtain-a-time-based-blind-sql-injection-and-automate-by-modifying-sqlmap\/","title":{"rendered":"How to obtain a time-based blind SQL injection and automate by modifying SQLMAP?"},"content":{"rendered":"\n

The cybersecurity of web applications is a crucial issue in a world where digital data has become a major asset. Among the most subtle threats, “time-based blind SQL injection” vulnerabilities stand out for their ability to exfiltrate data without triggering obvious alerts. These attacks exploit database response times to reconstruct sensitive information, a technique that requires expertise and discretion. This article explores this type of attack in detail, based on a real case observed during an intrusion test. <\/p>\n\n

How is Time-Based Blind SQL Injection different from classic SQL injection?<\/h2>\n\n

A blind SQL injection<\/a> attack relies on the exploitation of SQL queries in vulnerable application parameters. Unlike a classic SQL injection, which directly displays results (such as errors or exfiltrated data), a “blind” attack relies on subtle cues, such as server response time. <\/p>\n\n

In a “time-based” variant, an attacker inserts SQL commands capable of “pausing” the database to check whether a condition is true or false. This technique makes it possible to extract data character by character by modifying response times, without any visible interaction with the user. <\/p>\n\n

Case study : A flaw in a PostgreSQL-based application<\/h2>\n\n

During a pentest on a web application, a vulnerability of this type was identified. Here’s how it was exploited. <\/p>\n\n

1. Vulnerability detection<\/h3>\n\n

A test request was sent to an application API. An HTTP 200 (OK) response indicated a successful request. However, the addition of an apostrophe (‘) generated an HTTP 500 error, indicating a potential SQL injection flaw. The error disappeared when two apostrophes were added (”), confirming a possible vulnerability in user input management. <\/p>\n\n

<\/p>\n\n

Classic search query in the ‘text’ parameter:<\/p>\n\n

\"Classic<\/figure>\n\n

<\/p>\n\n

We add an apostrophe to our text, which generates an HTTP 500 error code:<\/p>\n\n

\"An<\/figure>\n\n

<\/p>\n\n

We add a second apostrophe to see if the error disappears, and this is the case with an HTTP 200 OK response code:<\/p>\n\n

\"With<\/figure>\n\n

<\/p>\n\n

<\/p>\n\n

2. Setting up time-based injection<\/h3>\n\n

To test whether a SQL command could influence response times, a query using PostgreSQL’s pg_sleep() function was sent. Result: the server took several seconds to respond, confirming the possibility of influencing response times (see bottom right of screenshot). To be able to perform a sleep, there are a number of special features to note: <\/p>\n\n