Adding support for code templates

[Mzack9999]

Proposed changes

This PR adds support for code templates. Uses stdin and stdout for in/out operation within the script context. The engine accepts two options:

• engine: any interpreter installed on the target machine (py, bash, powershell)
• source: code snippet or existing source file

Notes:

• Code templates requires a valid signature in order to be executed
• This PR also disables file, offlinehttp and code protocols when cloud is enabled
• The implementation is an experimental prototype (not optimized for performances and not supporting additional functionalities already available or in todo for gozero, such as sandbox or virtual environment)
• tests and docs will be extended and updated after pre-review

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) => Adding code template docs nuclei-docs#149

Example

# Print the template content
$ cat test.yaml

id: testcode

info:
  name: testcode
  author: testcode
  severity: info
  tags: code
  description: |
    testcode

code:
  - engine:
      - py
      - python3
    # Code Snippet
    source: |
      import sys
      print("hello " + sys.stdin.read() + ' ' + os.getenv('test'))
    # Code File
    # source: test.py

    matchers:
      - type: word
        name: testname
        words:
          - "hello"
    extractors:
      - type: dsl
        name: pyout # pyout will contain "hello test testvar
        dsl:
          - body

# Execute unsigned template => Rejected
$ echo "test" | ./nuclei -t test.yaml -v -debug -duc -no-interactsh -V test=testvar
...
[WRN] The template is not verified: 'C:\Users\marco\go\src\github.com\projectdiscovery\nuclei\v2\cmd\nuclei\testcode.yaml'
...
[FTL] Could not run nuclei: no valid templates were found
exit status 1

# Generate private key - go prefers prime256v1 (Ref: https://groups.google.com/g/Golang-nuts/c/Mbkug5t3ZYA)
$ openssl ecparam -name prime256v1 -genkey -noout -out priv-key.pem
# Extract public key
$ openssl ec -in priv-key.pem -pubout > pub-key.pem
read EC key
writing EC key

# Sign the template
$ cd v2/cmd/sign-templates
$ ./sign-templates -t ..\nuclei\test.yaml -prk ..\nuclei\priv-key.pem -puk ..\nuclei\pub-key.pem -a ecdsa

# Configure ENV variables - windows (NUCLEI_SIGNATURE_PUBLIC_KEY and NUCLEI_SIGNATURE_ALGORITHM)
# export NUCLEI_SIGNATURE_PUBLIC_KEY='C:\Users\marco\go\src\github.com\projectdiscovery\nuclei\v2\cmd\nuclei\pub-key.pem' # unix
$ $env:NUCLEI_SIGNATURE_PUBLIC_KEY='C:\Users\marco\go\src\github.com\projectdiscovery\nuclei\v2\cmd\nuclei\pub-key.pem' # windows           
# export NUCLEI_SIGNATURE_ALGORITHM='ecdsa' # unix
$ $env:NUCLEI_SIGNATURE_ALGORITHM='ecdsa' # windows                                

# Execute the signed template
$ echo "test" | ./nuclei -t test.yaml -v -debug -duc -no-interactsh -V test=testvar
...
[DBG] [testcode] Dumped Code Execution for test
hello test testvar
[testcode:testname] [code] [info] test [hello test testvar]

[tarunKoyalwar]

@Mzack9999

I was thinking it would be better if we only expose gozero.Gozero and gozero.Source. and dissolve gozero.command and let it be handled by gozero.Gozero (with sh as engine ) . Its early we would possibly need to change many things in gozero
ex:

1. context with timeout
2. support for bash script
3. temp file permissions

I think we will face more problems with sh or bash . if we do not expose gozero.command . there will be less changes in nuclei and even if we improve gozero and it will be a black box .

[tarunKoyalwar]

Also we already have logic about sh and ps that we implemented earlier in executils .

https://github.com/projectdiscovery/utils/blob/471a54f0a0712b263dea919b4c7388cbfcf88cf5/exec/executil.go#L176-L253

Note:
we might need to update them with regard to stdin and stdout

[JaneX8]

I just want to mention that including support for specific 3rd party tools is a great idea when they get specific implementations. But using code directly inside a YAML file in my opinion opens up so many risks that's just far from it's indented use, of both YAML-format and nuclei. If someone really wants to do something like this I would recommend just creating a bash script and supporting running bash scripts with some parameters instead.

[Mzack9999]

Notes:

• Interactsh urls placeholders suffers of a per template-protocol scope, alas, the logic is not centralized but scattered in different incompatible implementations across major protocols, and fully absent in others (such as whois, dns, etc). As a result implementing interactsh url in code templates has such urls accessible only within their own scope due to various abstraction layers. In short referring to the same variable in multiple protocol will create new interactsh url in their own layered implementation as there is no concept of template context execution. It would be necessary to refactor the core to transport these urls through metainput.
• Embedding -sign via env variables is not recommended, and generally it's use discouraged as it potentially enlarges attack surface

[ehsandeep]

• Adding default algorithm to sign (rsa)
• Adding docs to nuclei-docs for code protocol and template sign option

[ehsandeep]

@Mzack9999 Merge conflict ^