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

Golang semgrep rule not matching every method invocation inside method body #9906

Closed
1 of 3 tasks
shivasurya opened this issue Mar 8, 2024 · 2 comments
Closed
1 of 3 tasks

Comments

@shivasurya
Copy link

Describe the bug
Semgrep rule isn't matching all function invocation calls inside function body. Example: Semgrep playground link. Is there any alternative way to match all possible auth.Verify method invocation within golang function

Expected behavior
Would it be possible to match every auth.Verify instance within the method body?

What is the priority of the bug to you?

  • P0: blocking your adoption of Semgrep or workflow
  • P1: important to fix or quite annoying
  • P2: regular bug that should get fixed

Environment
Semgrep playground / Ubuntu 22.04

Use case
What will fixing this bug enable for you?

Reduce some false positives while detecting auth functions in method body.

@ievans
Copy link
Member

ievans commented Mar 9, 2024

hi @shivasurya , this is actually expected behavior as $X.Verify() is a statement when written in the body of a function like that, and you are looking for it in an expression context. If you only wanted to match what you have I'd write two separate patterns, e.g.: https://semgrep.dev/playground/s/5rvrl

    patterns:
      - pattern: $X.Verify()
      - pattern-inside: |
          func $RESOLVER() { 
              ...
          }

Or if you just want inside the if blocks, you could use the deep expression operator: https://semgrep.dev/docs/writing-rules/pattern-syntax/#deep-expression-operator

func $RESOLVER() {
  ...
  if <... $X.Verify() ...> {
    ...
  }
  ...
}

I'll close this issue but would welcome ideas on how we can make this behavior more intuitive!

@ievans ievans closed this as completed Mar 9, 2024
@shivasurya
Copy link
Author

Thanks @ievans for the quick feedback. I'm not sure if this will cover all cases in the code within function block. However, I'll try to workaround with this.

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

No branches or pull requests

2 participants