`wasLastResponseDelayed` does not use `conf.timeSec` by default

[zjxszzzcb]

sqlmap/lib/core/common.py

Line 2813 in 1de66fd

retVal = (threadData.lastQueryDuration >= max(MIN_VALID_DELAYED_RESPONSE, lowerStdLimit))

When I was using sqlmap to test whether a service was vulnerable to SQL injection, I encountered an issue:
sqlmap identified an injection point but misjudged it as a false positive.
When sqlmap used time-based blind injection to verify whether it was a false positive, it employed the following payloads:
SLEEP(5-(IF(69=69,0,5))) Response time 10 seconds, continuing.
SLEEP(5-(IF(69=88,0,5))) Response time about 1 second, continuing.
SLEEP(5-(IF(88=88,0,5))) Response time 11 seconds, continuing.
SLEEP(5-(IF(99 88,0,5))) Response time 8 seconds. Since this expression is an invalid SQL statement, a warning "false positive or unexploitable injection point detected" was triggered, and sqlmap's verification was interrupted.

Due to certain reasons, the service I tested does indeed introduce some delay when the expression is invalid. I wanted to simply increase --time-sec to 15 to verify this vulnerability, but it failed(I resolved the issue by adding --disable-stats. This parameter doesn't seem to appear in the help information? I checked with python sqlmap.py -hh but couldn't find this option.). I don't understand why under default conditions it only checks whether the response time is greater than the mean + 7 times the standard deviation, rather than continuing to check if response time > conf.timeSec?

[stamparm]

You're absolutely right that --time-sec is used to define the expected delay for time-based blind SQLi, but the actual detection logic in sqlmap is more nuanced. Rather than relying solely on a fixed threshold, the tool uses a heuristic approach based on statistical analysis of response times (e.g., comparing against the mean + 7 * std deviation). This is intentional, as basing delay detection solely on --time-sec would be too simplistic and could easily lead to false positives or negatives, especially on unstable networks. Less mature tools (e.g. Burp) often use fixed thresholds, but sqlmap aims for more reliable detection.

As for the --disable-stats option — you're correct that it's not shown in the help output. It's an internal/hidden flag that can be helpful in specific scenarios like yours. Given your use case, I'll go ahead and expose this option so users can take advantage of it when necessary.

[stamparm]

p.s. I started to write the gibberish, usual bastardly response, but asked ChatGPT to make it more polite :)

[zjxszzzcb]

You're absolutely right that --time-sec is used to define the expected delay for time-based blind SQLi, but the actual detection logic in sqlmap is more nuanced. Rather than relying solely on a fixed threshold, the tool uses a heuristic approach based on statistical analysis of response times (e.g., comparing against the mean + 7 * std deviation). This is intentional, as basing delay detection solely on --time-sec would be too simplistic and could easily lead to false positives or negatives, especially on unstable networks. Less mature tools (e.g. Burp) often use fixed thresholds, but sqlmap aims for more reliable detection.你说的完全正确，--time-sec 用于定义基于时间的盲 SQLi 的预期延迟，但 sqlmap 中的实际检测逻辑更加微妙。该工具不仅依赖于固定阈值，还使用基于响应时间统计分析的启发式方法（例如，与平均值 + 7 * 标准偏差进行比较）。这是有意为之，因为仅根据 --time-sec 进行延迟检测过于简单，并且很容易导致误报或漏报，尤其是在不稳定的网络上。不太成熟的工具（例如 Burp）通常使用固定阈值，但 sqlmap 旨在提供更可靠的检测。

As for the --disable-stats option — you're correct that it's not shown in the help output. It's an internal/hidden flag that can be helpful in specific scenarios like yours. Given your use case, I'll go ahead and expose this option so users can take advantage of it when necessary.至于 --disable-stats 选项 — 您是对的，它没有显示在帮助输出中。它是一个内部/隐藏标志，在像您这样的特定场景中可能会有所帮助。根据您的用例，我将继续公开此选项，以便用户可以在必要时利用它。

My point is whether the comparison with conf.timeSec is missing. For example, why isn't the judgment logic threadData.lastQueryDuration >= max(MIN_VALID_DELAYED_RESPONSE, lowerStdLimit, conf.timeSec)?

[stamparm]

i hope you can imagine that there is a good reason for that???

conf.timeSec is not always used in a straight "delay for X seconds" way. some payloads don't have exact "delay X seconds" way to define (e.g. BENCHMARK in case of MySQL)

[zjxszzzcb]

Oh, you're right. I'm really sorry for misunderstanding some things and asking a silly question.

Finally, I'd like to ask—are there any plans to improve this part in the future? For example, adjusting the judgment logic based on different kinds of payloads? After all, in the scenario I encountered, it's really puzzling that sqlmap aborts testing just because SQL statements with syntax errors have longer response times, while correctly formatted SQL statements seem to work perfectly fine. For sleep-based payloads, it would be great if sqlmap could automatically check whether the response time exceeds the specified sleep duration by default.