add project discovery Nuclei boefje

[RiieCco]

Changes

This commit adds the Project discovery Nuclei scan as a boefje
More info about the scanner

Issue ticket number and link

Please paste a link to the issue on the project board here. Alternatively, if there was no submitted issue prior to this PR, you may add this PR to the project board directly.

Proof

Extra instructions for others

This section may be skipped or omitted. Uncomment and answer the below questions if relevant.

Checklist for author(s):

• All the commits in this PR are properly PGP-signed and verified;
• This PR comes from a feature or hotfix branch, in line with our git branching strategy;
• This PR is "bite-sized" and only focuses on a single issue, problem, or feature;
• I am not reinventing the wheel: there is no high-quality library that already has this feature;
• I have changed the example .env files if I added, removed, or changed any config options, and I have informed others that they need to modify their .env files if required;
• I have performed a self-review of my own code;
• I have commented my code, particularly in hard-to-understand areas;
• I have made corresponding changes to the documentation, if necessary;
• I have written unit, integration, and end-to-end tests for the change that I made;

If a non-trivial PR:

• This PR is part of a milestone and has appropriate labels;
• This PR is properly linked to the project board (either directly or via an issue);
• I have added screenshots or some other proof that my code does what it is supposed to do;

## Checklist for functional reviewer(s):
- [ ] If a non-trivial PR: This PR is properly linked to an issue on the project board;
- [ ] I have checked out this branch, and successfully ran `make kat`;
- [ ] I have ran `make test-rf` and all end-to-end Robot Framework tests pass;
- [ ] I confirmed that the PR's advertised `feature` or `hotfix` works as intended;
- [ ] I confirmed that there are no unintended functional regressions in this branch;

### What works:
* _bullet point + screenshot (if useful) per tested functionality_

### What doesn't work:
* _bullet point + screenshot (if useful) per tested functionality_

### Bug or feature?:
* _bullet point + screenshot (if useful) if it is unclear whether something is a bug or an intended feature._

## Checklist for code reviewer(s):
- [ ] The code passes the CI tests and linters;
- [ ] The code does not bypass authentication or security mechanisms;
- [ ] The code does not introduce any dependency on a library that has not been properly vetted;
- [ ] The code does not violate Model-View-Template and our other architectural principles;
- [ ] The code contains docstrings, comments, and documentation where needed;
- [ ] The code prioritizes readability over performance where appropriate;
- [ ] The code conforms to our agreed coding standards.

[CLAassistant]

All committers have signed the CLA.

[underdarknl]

awesome, we'll have a look asap.

[ammar92]

Nice addition! I still have to test this out, but I do already have a few small remarks to improve it even more 👍

[ammar92]

Tested and seems to work for me!

[tobiasBDO]

I see this boefje currently ingests the Hostname, which gets used as a URL in this boefje. What about the HostnameHTTPURL? because this could be more customizable due to software running on different ports than default 80 and 443.

[RiieCco]

I see this boefje currently ingests the Hostname, which gets used as a URL in this boefje. What about the HostnameHTTPURL? because this could be more customizable due to software running on different ports than default 80 and 443.

That is achieved by making just a change in the "boefje.json" right?

[ammar92]

Indeed, and in the boefje itself since the input is different because Hostname and HostnameHTTPURL are different models

[RiieCco]

@ammar92, can you make a suggestion for me as to how that should look like? :-)
I am not sure what/where to look for exactly.

[ammar92]

@ammar92, can you make a suggestion for me as to how that should look like? :-)
I am not sure what/where to look for exactly.

So in general it would look like this:

• Update the boefje.json to consume both Hostname and HostnameHTTPURL
• In the boefje code (main.py) check wether you're dealing with a hostname or HostnameHTTPURL
  • If it's a HostnameHTTPURL, you can construct a URL from that using the netloc.name and port properties
  • If it's a Hostname, you can construct a URL from just the name property (meaning default http scheme and port 80)
  • To distinguish between the two input types, you could check for the object_type in boefje_meta.arguments["input"]["object_type"], this should either be Hostname or HostnameHTTPURL

[ammar92]

This could also return a None, which makes the formatted string look like <hostname>:None. It can be avoided by giving a default port, e.g. port = input.get("port", 80)

But since the port property is required and therefore guaranteed to exist, you can simply access that element directly: port = input["port"]

Suggested change

	port = input.get("port")
	port = input["port"]

[RiieCco]

@ammar92 Woeps i am not sure what i just did exactly haha, sorry about that!

[ammar92]

Looks good! One small suggestion left, but consider it approved 👍