-
Notifications
You must be signed in to change notification settings - Fork 111
False positives for SSRF #7
Comments
Hey @stevenjohnstone, thanks for the issue submission. We're glad that you're finding gokart useful! I am able to reproduce this issue using the test file that you've included. We'll take a deeper look here to resolve. |
I have reproduced this issue scanning the provided test file using package bug
import "net/http"
func DoSomething() (*http.Response, error) {
req, err := http.NewRequest("GET", "http://example.com", nil)
if err != nil {
return nil, err
}
return http.DefaultClient.Do(req)
} The scan does not consider the function vulnerable to SSRF as presented below. $ gokart scan bugs/ssrf03/bug.go
Using config found at /home/saullo/.gokart/analyzers.yml
Revving engines VRMMM VRMMM
3...2...1...Go!
Race Complete! Analysis took 398.462088ms and 82 Go files were scanned (including imported packages)
GoKart found 0 potentially vulnerable functions As this got me curious, I took a deeper look into what While recursively taint analyzing the provided test code, the Lines 119 to 142 in 3d38a9a
The functions that have a Lines 90 to 93 in 3d38a9a
I wonder if it wouldn't be possible to use a more detailed condition to taint vulnerable functions and avoid false positives. |
Finding gokart really useful so far: nice work!
Using 0.1.0, I see quite a lot of false positives for SSRF. For example,
It looks like any function which takes an
*http.Request
as an argument and passes it toDo
will be flagged as potentially vulnerable? In the above example, the request url comes from a string literal so isn't tainted.The text was updated successfully, but these errors were encountered: