feat: Added time based delay analyzer to fuzzing implementation

[Ice3man543]

Proposed changes

Added time delay verification by using alternating requests logic from ZAP to nuclei DAST mode and also added the concept of analyzers allowing more complicated verification checks. (HTTP - Fuzzing only)

Example template:

id: postgres-sqli-time-based

info:
  name: PostgreSQL Time based SQL Injection
  author: pdteam
  severity: critical


http:
  - payloads:
      prefixes:
        - " "
        - "' "
        - "\""
      suffixes:
        - "--"
        - "--"
        - "--"
    attack: pitchfork

    analyzer:
      name: time_delay
      #parameters:
      #  sleep_duration: 10
      #  requests_limit: 6
        
    fuzzing:
      - part: query
        type: postfix
        mode: single
        fuzz:
          # Ported from Ghauri
          # PostgreSQL > 8.1 OR time-based blind (comment)
          - "{{prefixes}}OR [RANDNUM]=(SELECT [RANDNUM] FROM PG_SLEEP([SLEEPTIME])){{suffixes}}"
          # PostgreSQL > 8.1 AND time-based blind (comment)
          - "{{prefixes}}AND [RANDNUM]=(SELECT [RANDNUM] FROM PG_SLEEP([SLEEPTIME])){{suffixes}}"
          
    stop-at-first-match: true
    matchers-condition: and
    matchers:
      - type: word
        # Also, DSL part analyzer_details contains detailed analysis
        # from the time delay analyzer.
        part: analyzer
        words:
          - "true"

Checklist

• Pull request is created against the dev branch
• All checks passed (lint, unit/integration/regression tests etc.) with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

[dwisiswant0]

By design, users won’t really know how the analyzer_matched variable is defined. It would be better to use the name already set on the analyzer object (ex. time_delay in this case).

Another key point to ensure is that the output type is boolean. So, instead of doing it like this:

    matchers:
      - type: word
        # Also, DSL part analyzer_details contains detailed analysis
        # from the time delay analyzer.
        part: analyzer_matched
        words:
          - "true"

We could go with a more straightforward approach by defining the matcher as:

    matchers:
      - type: dsl
        dsl:
          - time_delay # shorthand: time_delay == true

This is clearer and easier to follow.

[dwisiswant0]

Is time_delay a predefined type? I mean, if it's indeed set up as a specific kind of analyzer, it'd be a lot better to design it in a way that matches the style of matchers / extractors objects - so everything stays more aligned and easier to work with.

Here's what I'm thinking:

analyzer:
  - type: time_delay
    name: delayed # exported
    parameters: {...}
  - type: another_analyzer # what if there's no `name`? Defining `analyzer_N`?
    parameters: {...}

matchers:
  - type: dsl
    dsl:
      - delayed == true

[Ice3man543]

@dwisiswant0 Regarding the first point of part: analyzer_matched, it was done like this to keep it similar to the interactsh_protocol which also is done this way as a separate part and feels more uniform. The second one you mentioned can anyway be done with this as well using something like below

matchers:
      - type: dsl
        dsl:
          - analyzer_matched == true

Regarding the second point, only one analyzer is supposed to be used per check. For instance, the user won't combine time and boolean or xss context together. So it doesn't make sense to allow user to configure multiple of them. I don't see a scenario where we might need to combine multiple. Let me know what you think!

[dwisiswant0]

Wouldn't it be more reliable to use time.ParseDuration directly and skip having a custom handler for it? So we could remove the "time_unit" param entirely and make "sleep_duration" a string that gets parsed into time.Duration. What do you think, @Ice3man543?

[Ice3man543]

Agreed, will make it like so.