Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
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

[BUG] Static string as DSL extractor #5888

Open
1 task done
JaneX8 opened this issue Dec 5, 2024 · 5 comments
Open
1 task done

[BUG] Static string as DSL extractor #5888

JaneX8 opened this issue Dec 5, 2024 · 5 comments
Labels
Type: Bug Inconsistencies or issues which will cause an issue or problem for users or implementors.

Comments

@JaneX8
Copy link
Contributor

JaneX8 commented Dec 5, 2024

Is there an existing issue for this?

  • I have searched the existing issues.

Current Behavior

I found that I can only "extract" a static string using DSL and it's either undocumented or unclear and not logical how to use it. When I use:

    matchers:
      - type: dsl
        dsl:
          - "md5(body) == 'somemd5sum'"
    extractors:
      - type: dsl
        dsl:
          - '"v1.0.0"' # < This only works when the string is '"here"' (between double quotes inside single quotes) and not when it is 'here' (between single quotes).

Expected Behavior

A clearer documentation for such use cases or perhaps a different type of extractor. I propose:

    extractors:
      - type: static
        name: detected_version
        value: "v1.0.0"

Steps To Reproduce

See above example.

Environment

- OS: Alpine
- Nuclei: 3.3.7
- Go: 1.22.9
@JaneX8 JaneX8 added the Type: Bug Inconsistencies or issues which will cause an issue or problem for users or implementors. label Dec 5, 2024
@dwisiswant0
Copy link
Member

dwisiswant0 commented Dec 5, 2024

i'm not quite sure i fully understand the use case for this yet. from my POV, when you're creating a template, you typically already have a clear purpose in mind for what it's meant to achieve.

also, since DSL values are expressions designed to be evaluated, it makes sense that extracting a string literal would require wrapping it in quotes to ensure proper handling.

    matchers:
      - type: dsl
        name: "v1_0_0"
        dsl:
          - "md5(body) == 'v1.0.0sum'"
        internal: true
      - type: dsl
        name: "v1_1_0"
        dsl:
          - "md5(body) == 'v1.1.0sum'"
        internal: true
      - type: dsl
        name: "v1_1_1"
        dsl:
          - "md5(body) == 'v1.1.1sum'"
        internal: true

    extractors:
      - type: dsl
        dsl:
          - 'v1_0_0 && "v1.0.0"' # ternary op
          - 'v1_1_0 && "v1.1.0"'
          - 'v1_1_1 && "v1.1.1"'

or i might be missing some important context about the actual scenario. could you kindly provide more details or explain the real-world use case a bit further? that would help us understand better. thanks!

@JaneX8
Copy link
Contributor Author

JaneX8 commented Dec 7, 2024

I forgot about naming matchers. In this case I can achieve it that way too, thanks.

However, I noticed before when writing templates that sometimes I only want to return a static string of something. Is the only way to do this naming matchers? Or can I somehow tell an extractor to always return something static (if the matcher worked)?

@ehsandeep
Copy link
Member

I forgot about naming matchers. In this case I can achieve it that way too, thanks.

However, I noticed before when writing templates that sometimes I only want to return a static string of something. Is the only way to do this naming matchers? Or can I somehow tell an extractor to always return something static (if the matcher worked)?

For the 2nd case, this should work as you mentioned initially:

    extractors:
      - type: dsl
        dsl:
          - '"THIS IS RANDOM TEXT"'

@JaneX8
Copy link
Contributor Author

JaneX8 commented Dec 7, 2024

Yes, it works but using dsl this way is not logical and natural. I propose a static type for this behaviour.

@dwisiswant0
Copy link
Member

[...] I propose a static type for this behaviour.

But could you share a real-world use case where this behavior would be needed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Bug Inconsistencies or issues which will cause an issue or problem for users or implementors.
Projects
None yet
Development

No branches or pull requests

3 participants