Adding support for navigation history to matchers

[Mzack9999]

Proposed changes

This PR adds support for navigation history (HTTP raw request/responses) to matchers

Checklist

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

How to reproduce

1. Use the following template:

id: test

info:
  name: test
  author: pdteam
  severity: info
  reference: test
  tags: headless

headless:
  - steps:
      - args:
          url: "{{BaseURL}}/test"
        action: navigate
      - action: waitload
    matchers:
      - type: word
        part: history
        words:
          - "test"

2. Run nuclei with a headless matcher on history:

$ echo http://localhost:8000 | go run . -duc -no-interactsh -t headless.yaml -headless

                     __     _
   ____  __  _______/ /__  (_)
  / __ \/ / / / ___/ / _ \/ /
 / / / / /_/ / /__/ /  __/ /
/_/ /_/\__,_/\___/_/\___/_/   2.5.8-dev

                projectdiscovery.io

[WRN] Use with caution. You are responsible for your actions.
[WRN] Developers assume no liability and are not responsible for any misuse or damage.
[INF] Using Nuclei Engine 2.5.8-dev (development)
[INF] Using Nuclei Templates 8.7.9 (latest)
[INF] Using Interactsh Server https://interact.sh
[INF] Templates added in last update: 19
[INF] Templates loaded for scan: 1
[2021-12-29 09:55:33] [test] [headless] [info] http://localhost:8000

[LuitelSamikshya]

Looks good.

[forgedhallpass]

@Mzack9999

I think in the "+\n", the + sign is a mistake.

Also his might be more readable:

rawResp.WriteString(fmt.Sprintf("HTTP/1.1 %d %s\n", respPayloads.ResponseCode, respPayloads.ResponsePhrase))

[Mzack9999]

@Mzack9999

I think in the "+\n", the + sign is a mistake.

Nice catch - fixed in #1465

Also his might be more readable:

rawResp.WriteString(fmt.Sprintf("HTTP/1.1 %d %s\n", respPayloads.ResponseCode, respPayloads.ResponsePhrase))

^ @Ice3man543 - This was implemented as requested in #1432 (comment)

[forgedhallpass]

I must disagree with that comment. In the original version (which actually coincides with my recommendation ;-) ), it's clearly visible that it describes one HTTP request line. Splitting it into multiple lines, not only makes the code longer (without any relevant performance benefit), but clutters the logic and makes it harder to follow.