-
Notifications
You must be signed in to change notification settings - Fork 1.9k
[Golang][C#] Sinks from external libraries/projects #20431
-
Hello,
Suppose I'm scanning a go-project 'MyRestApiProject' locally, where there is a sql-injection. The sink is defined in another project which is stored under /Users/me/go/pkg/mod/github.dev-course.com/smpl-projects/ directory. This sink is supported by codeql. 'MyRestApiProject' makes a call to the sink but codeql doesn't recognise it as it comes from the external project.
Is there any way I could make codeql look inside this call into the external project?
For C# there is Modeling the calls your codebase makes to external APIs, but if it becomes cumbersome to add sinks manually in the future, how can I facilitate this process?
Besides, it's unavailable for golang. What possibilities do I have?
Thank you for taking time with my request)
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 3 comments 1 reply
-
I'm interested in an automatic method of making codeql recognise external sinks. Making it follow the call and analyse the tiny part of the external project which concerns the sql mechanism
Beta Was this translation helpful? Give feedback.
All reactions
-
I'm double-checking on model-packs. Meanwhile one thing you could consider would be creating a single CodeQL database containing both your library and your application, thereby allowing CodeQL to see 'inside' the library calls and complete the path from source to sink. This could be achieved using a CodeQL traced build (either use the -c option one or more times in the CLI, or replace the autobuild step with go build invocations in an Actions setting). Whatever go build invocations result from a traced command will be analysed as 'user' rather than 'library' (opaque) code, allowing CodeQL data-flow paths to go back and forth between the two.
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1
-
Thank you for the reply!
The idea with traced build sounds brilliant. I wonder if, with traced build enabled, Codeql will build all the dependencies of the project? There may be dozens of them, and it may considerably slow done the db build process.
Ideally, the tool could create ASTs of some separate files of the dependency, of those files which contain the sink logic.
Say, the project MyProject imports two methods form the project DbQueries. In fact, during SAST analysis of MyProject, I'm only interested in the AST/DataFlowGraph of MyProject and of the two DbQueries methods. I don't need the rest of DbQueries. Is there any way to do without the in-depth build of the dependency?
Beta Was this translation helpful? Give feedback.
All reactions
-
Side note: the model editor is not available for Go, but it is still possible to write models by hand and put them in a model pack. It is more cumbersome though.
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1