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_matched
        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