header fuzzing support in http templates

[0x123456789]

#4113 Proposed changes

Hi, I add new fuzzing part - headersPartType. It can be used to fuzz headers. Because user specify url as input I change argument type of rule.isExecutable() to access headers and body params in future. Can you please check that I move in right direction and if all is fine I will implement body parameters fuzzing

[ehsandeep]

@0x123456789 Thanks for creating this PR; I am curious how you intend to use this in its current form where only URL input is supported; we think before we introduce header/body fuzzing, we also need to add support for new input types, which will accept/include raw request information with possible insertion points to fuzz, but let me know I'm missing something and you have some example to share with current implementation.

[0x123456789]

@ehsandeep Hi, thank you for reply. You are right for now in most cases user pass URL as input, but templates also support RAW request, so if user pass URL and specify fuzzing template nuclei will use all another information from RAW request. Here simple example:

id: just-example

info:
  name: Just little PoC for Headers testing
  author: pdteam
  severity: medium
  tags: xss,rxss,dast

self-contained: false

variables:
  first: "{{rand_int(10000, 99999)}}"


http:
  - raw:
      - |
        GET /?x=aaa&y=bbb HTTP/1.1
        Host: {{Hostname}}
        Origin: https://exmple.com
        X-Fuzz-Header: 1337
        Connection: close
        Cookie: z=aaa; bb=aaa
        User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko)
        Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
        Accept-Language: en-US,en;q=0.9

    payloads:
      reflection:
        - "'\"><{{first}}"

    fuzzing:
      - part: headers
        type: replace
        mode: single
        fuzz:
          - "{{reflection}}"

    stop-at-first-match: true
    matchers-condition: and
    matchers:
      - type: word
        part: body
        words:
          - "{{reflection}}"

      - type: word
        part: header
        words:
          - "text/html"

Using this templates all headers for {{Hostname}} will be fuzzed.

You said:

we also need to add support for new input types, which will accept/include raw request information with possible insertion points to fuzz

If the fuzzing template contains a RAW request it is very close to what you said

UPD: I think you are right and in future it's better to implement another InputType, that can be converted to retryablehttp request

[0x123456789]

@ehsandeep Seems quite hard to introduce a new InputProvider (for file) as the Runner uses hmapInputProvider:

type Runner struct {
	...
	hmapInputProvider *hybrid.Input
	...
}

Later in code it used for interface InputProvider:

results := engine.ExecuteScanWithOpts(finalTemplates, r.hmapInputProvider, true)

Do you already have any ideas how do it better?

[ehsandeep]

@0x123456789 Thanks for sharing additional info and looking into input support; as of now, we are reviewing this and looking to merge this PR, so we can start to work on the follow-up work required to support the fuzzing feature.

[0x123456789]

@ehsandeep Thank you! If I can help in some way please share your thoughts

[tarunKoyalwar]

lgtm !

added example templates in integration_test
Note: this does not add support for fuzzing headers in headless templates

thanks for PR @0x123456789

[tarunKoyalwar]

@0x123456789 , about fuzzing and furthur enhancements

we currently are wrapping up nuclei v3 and its related issues => https://github.com/projectdiscovery/nuclei/milestone/32
but after that we will be working( most of it is already in WIP) on adding fuzzing support . which requires 2 things as you might have already noticed

• minor refactor around headless and fuzzing
• carrier support to store and access raw requests primarily through (input.MetaInput.RawRequest , input.MetaInput.RawResponse etc something like this) [WIP]
• later on other things like comparison support for base response and new response ( for IDOR etc) through dsl

we will create subsequent issues for these soon . meanwhile any type of contributions are greatly appreciated

[tarunKoyalwar]

$ TESTS="fuzz/fuzz-header-basic.yaml" ./run.sh   
::group::Build nuclei
::endgroup::
::group::Build nuclei integration-test
::endgroup::
::group::Installing nuclei templates

                     __     _
   ____  __  _______/ /__  (_)
  / __ \/ / / / ___/ / _ \/ /
 / / / / /_/ / /__/ /  __/ /
/_/ /_/\__,_/\___/_/\___/_/   v2.9.13

		projectdiscovery.io

[INF] No new updates found for nuclei templates
::endgroup::
skipping test case http/interactsh.yaml. disabled on darwin.
skipping test case http/interactsh-stop-at-first-match.yaml. disabled on darwin.
skipping test case http/default-matcher-condition.yaml. disabled on darwin.
[✓] Test "fuzz/fuzz-header-basic.yaml" passed!

[ehsandeep]

@0x123456789 @tarunKoyalwar here is the body fuzzing implementation - #4163 with examples test run, it just needs to be finalized to complete!

Fuzzing implementation currently supports proxify jsonl as input; we need to extend the input file support for other possible data sources listed in - #4131

[0x123456789]

@tarunKoyalwar Thank you!