It appears that `GetImportedName` returns _both_ aliased and non-aliased imports.
As a result, a file having both crypto/rand and math/rand (but aliased) would
trigger false positives on G404. Given the following file;
```go
package main
import (
"crypto/rand"
"math/big"
rnd "math/rand"
)
func main() {
_, _ = rand.Int(rand.Reader, big.NewInt(int64(2)))
_ = rnd.Intn(2)
}
```
And patching for debugging;
```patch
diff --git a/helpers.go b/helpers.go
index 437d032..80f4233 100644
--- a/helpers.go
+++ b/helpers.go
@@ -250,6 +250,8 @@ func GetBinaryExprOperands(be *ast.BinaryExpr) []ast.Node {
// GetImportedName returns the name used for the package within the
// code. It will ignore initialization only imports.
func GetImportedName(path string, ctx *Context) (string, bool) {
+ fmt.Printf("%+v", ctx.Imports.Imported)
+ os.Exit(1)
importName, imported := ctx.Imports.Imported[path]
if !imported {
return "", false
```
Would show that `math/rand` was included in the list, using it's non-aliased
name (`:rand`).
gosec -quiet .
map[crypto/rand:rand math/big:big math/rand:rand]
This patch works around this problem by reversing the order in which imports
are resolved in `MatchCallByPackage()`. Aliased packages are tried first, after
which non-aliased imports are tried.
Given the example application mentioned above:
Before this patch:
```bash
gosec -quiet .
Results:
[/Users/sebastiaan/Projects/test/gosec-issue/main.go:10] - G404 (CWE-338): Use of weak random number generator (math/rand instead of crypto/rand) (Confidence: MEDIUM, Severity: HIGH)
9: func main() {
> 10: _, _ = rand.Int(rand.Reader, big.NewInt(int64(2)))
11: _ = rnd.Intn(2)
```
With this patch applied:
```bash
gosec --quiet .
Results:
[/Users/sebastiaan/Projects/test/gosec-issue/main.go:11] - G404 (CWE-338): Use of weak random number generator (math/rand instead of crypto/rand) (Confidence: MEDIUM, Severity: HIGH)
10: _, _ = rand.Int(rand.Reader, big.NewInt(int64(2)))
> 11: _ = rnd.Intn(2)
12: }
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
* Add check for usage of Rat.SetString in math/big with an overflow error
Rat.SetString in math/big in Go before 1.16.14 and 1.17.x before 1.17.7
has an overflow that can lead to Uncontrolled Memory Consumption.
It is the CVE-2022-23772.
* Use ContainsPkgCallExpr instead of manual parsing
* Find G303 in string concatenations, with os.TempDir, and in path.Join args
* Find G303 with /usr/tmp, too
/usr/tmp is commonly found e.g. on Solaris.
In Go 1.16 or higher, the `io/ioutil` has been deprecated and the
`ioutil.ReadFile` function now calls `os.ReadFile`.
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
* Add G307 sample code.
The sample should reflect a defered close that leads to data loss.
Due to IDE auto-complete people tend at least log errors, but not
really care about handling.
* Add more G307 sample code. Propose a way to implement
* Remove unused code. Add example that should not return an error but does
* Remove test for synced closed file for now.
Will add this later
Co-authored-by: Cosmin Cojocar <cosmin.cojocar@gmx.ch>
* fix: add variable assignment checking as part of MinVersion
* fix: add more code to allow assignment with const
* fix: rework the code and add more test cases for MinVersion
* fix: format linting issue using gofumpt
