Lower timeout for interacting with DevTools
Problem
There are cases where the scanner may get hung waiting on a response from the browser to a request message (like Network.getResponseBody):
In this circumstance, the scanner will wait up to a configured timeout before ending the request with an error. This DevTools API timeout is set to 45 seconds by default, and we currently do not document the mechanism for changing it. Because 45 seconds is so much longer than other critical timeouts like DAST_PAGE_DOM_READY_TIMEOUT (6 seconds) and DAST_PAGE_READY_AFTER_NAVIGATION_TIMEOUT (15 seconds), the DevTools API timeout ends up being essentially irrelevant; by the time it would have triggered, whatever scanner action prompted the request in the first place has probably already timed out.
Most of the time responses from the browser are nearly instantaneous; indeed the correct functioning of the scanner relies on that fact. We currently know of no reason why the browser would take longer than a moment to respond, if it is going to respond at all.
Recommendation
There are two other timeouts which govern specific interactions with the browser: DAST_CRAWL_SEARCH_ELEMENT_TIMEOUT (3 seconds) and DAST_CRAWL_EXTRACT_ELEMENT_TIMEOUT (5 seconds). That is already an eternity by the standards of the DevTools protocol; if it actually took that long something would have to be seriously wrong. By lowering the DevTools API timeout to the higher of those values (5 seconds), we would lessen the impact of exceptional circumstances where the browser does not respond, while not interfering with normal operations.
Based on feedback from leadership, we should take a stepped approach to making this change. To ensure we minimize user disruption we should introduce timeout changes based on this incremental plan:
| Timeout value | Milestone |
|---|---|
| 45 | current |
| 30 | 18.0 |
| 20 | 18.1 |
| 10 | 18.2 |
| 5 | 18.3 |