Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nuclei analyzer (Draft) Closes #1883 #2670

Open
wants to merge 5 commits into
base: develop
Choose a base branch
from

Conversation

pranjalg1331
Copy link

@pranjalg1331 pranjalg1331 commented Jan 13, 2025

(Please add to the PR name the issue/s that this PR would close if merged by using a Github keyword. Example: <feature name>. Closes #999. If your PR is made by a single commit, please add that clause in the commit too. This is all required to automate the closure of related issues.)

Description

This is a draft pr for Docker based analyzer for Nuclei. I have created a flask API around Nuclei (Cli tool) with the python subprocess module and have added Dockerfile and compose.yaml. Curently the image is being pulled from my dockerhub repository.
Please review my approach so a can proceed with resolving the issue.

Closes #1883

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue).
  • New feature (non-breaking change which adds functionality).
  • Breaking change (fix or feature that would cause existing functionality to not work as expected).

Checklist

  • I have read and understood the rules about how to Contribute to this project
  • The pull request is for the branch develop
  • A new plugin (analyzer, connector, visualizer, playbook, pivot or ingestor) was added or changed, in which case:
    • I strictly followed the documentation "How to create a Plugin"
    • Usage file was updated. A link to the PR to the docs repo has been added as a comment here.
    • Advanced-Usage was updated (in case the plugin provides additional optional configuration). A link to the PR to the docs repo has been added as a comment here.
    • I have dumped the configuration from Django Admin using the dumpplugin command and added it in the project as a data migration. ("How to share a plugin with the community")
    • If a File analyzer was added and it supports a mimetype which is not already supported, you added a sample of that type inside the archive test_files.zip and you added the default tests for that mimetype in test_classes.py.
    • If you created a new analyzer and it is free (does not require any API key), please add it in the FREE_TO_USE_ANALYZERS playbook by following this guide.
    • Check if it could make sense to add that analyzer/connector to other freely available playbooks.
    • I have provided the resulting raw JSON of a finished analysis and a screenshot of the results.
    • If the plugin interacts with an external service, I have created an attribute called precisely url that contains this information. This is required for Health Checks.
    • If the plugin requires mocked testing, _monkeypatch() was used in its class to apply the necessary decorators.
    • I have added that raw JSON sample to the MockUpResponse of the _monkeypatch() method. This serves us to provide a valid sample for testing.
  • If external libraries/packages with restrictive licenses were used, they were added in the Legal Notice section.
  • Linters (Black, Flake, Isort) gave 0 errors. If you have correctly installed pre-commit, it does these checks and adjustments on your behalf.
  • I have added tests for the feature/bug I solved (see tests folder). All the tests (new and old ones) gave 0 errors.
  • If the GUI has been modified:
    • I have a provided a screenshot of the result in the PR.
    • I have created new frontend tests for the new component or updated existing ones.
  • After you had submitted the PR, if DeepSource, Django Doctors or other third-party linters have triggered any alerts during the CI checks, I have solved those alerts.

Important Rules

  • If you miss to compile the Checklist properly, your PR won't be reviewed by the maintainers.
  • Everytime you make changes to the PR and you think the work is done, you should explicitly ask for a review. After being reviewed and received a "change request", you should explicitly ask for a review again once you have made the requested changes.

meshery-dev bot and others added 5 commits January 13, 2025 13:00
Signed-off-by: pranjalg1331 <[email protected]>
Signed-off-by: pranjalg1331 <[email protected]>
Signed-off-by: pranjalg1331 <[email protected]>
Signed-off-by: pranjalg1331 <[email protected]>
logger.debug(f"Running command: {' '.join(command)}")

result = subprocess.run(
command,

Check failure

Code scanning / CodeQL

Uncontrolled command line Critical

This command line depends on a
user-provided value
.
success, result = run_nuclei_command(url, template_dirs)

if success:
return jsonify(result), 200

Check warning

Code scanning / CodeQL

Information exposure through an exception Medium

Stack trace information
flows to this location and may be exposed to an external user.
if success:
return jsonify(result), 200
else:
return jsonify(result), 500

Check warning

Code scanning / CodeQL

Information exposure through an exception Medium

Stack trace information
flows to this location and may be exposed to an external user.
Comment on lines +161 to +165
{
"success": False,
"error": "An unexpected error occurred",
"details": str(e),
}

Check warning

Code scanning / CodeQL

Information exposure through an exception Medium

Stack trace information
flows to this location and may be exposed to an external user.
@pranjalg1331
Copy link
Author

@drosetti, Currently my Nuclei image process request synchronously. But I noticed in classes.py that we are polling the API for the results. So will I have to make my API asynchronous with task queues?

Copy link
Contributor

@drosetti drosetti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the analyzer perspective I think it's not required to make the request async. It should works simply avoiding the polling, it will have the data in the first request and in case it takes too much time there is a timeout over each task. I think we can keep in sync.

@@ -0,0 +1,54 @@
FROM python:3.9-slim
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

python 3.9 will reach the end of life in oct 2025 please use an higher version

@@ -99,7 +99,7 @@ check_parameters "$@" && shift 2
load_env "docker/.env"
current_version=${REACT_APP_INTELOWL_VERSION/"v"/""}

docker_analyzers=("pcap_analyzers" "tor_analyzers" "malware_tools_analyzers" "cyberchef" "phoneinfoga" "phishing_analyzers")
docker_analyzers=("pcap_analyzers" "tor_analyzers" "malware_tools_analyzers" "cyberchef" "phoneinfoga" "phishing_analyzers" "nuclei_analyzer")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I think you should add an "echo" in the print_help function (line 19) and add the path mapping (line 12)

@pranjalg1331
Copy link
Author

@drosetti, I think currently we are polling by default in all the docker-based integrations inside _docker_run function. Should I change this and pass a boolean for when polling is not needed and API is working in sync?

@drosetti
Copy link
Contributor

You're right, the polling is always made. I think the better solution is to change this analyzer: in this way all the docker-based analyzers have the same flow and this makes easier maintain them.

@pranjalg1331
Copy link
Author

pranjalg1331 commented Jan 15, 2025

@drosetti Another simpler approach would be to check if the task key is present in the result. If the key is not present, it means that the workflow is synchronous and we can directly pass the result. I believe it will also be more efficient than polling. Please suggest on which way should I move forward?

@pranjalg1331 pranjalg1331 requested a review from drosetti January 17, 2025 09:47
@drosetti
Copy link
Contributor

Do you want to put a flag and based on it do a sync or async request ? I don't like it a lot. Another approc could be create two methods: one for sync and on for async and both of them use a function to do the first request, in this way we avoid to duplicate code and the async version also have the polling requests. How does it sound to you ?

@pranjalg1331
Copy link
Author

@drosetti, for now, I have implemented the API in asynchronous structure. I am just working on optimizing it to reduce the time it takes to analyze. Once completed I will push the changes.
But I do agree that we should either implement a new method for calling synchronous APIs or we should mention in docs about our current architecture (polling).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants