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
Made also the rule to not report an issue when encountering function
scoped variable which terminate in a basic literal such as a string.
Signed-off-by: Cosmin Cojocar <cosmin.cojocar@gmx.ch>
The existing unit tests for G107 didn't have any comments why
a certain code is problematic.
Other than that we need more unit tests for rule G107 for the
different scenarios.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
Currently, rule G204 warns you about every single use of the
functions syscall.Exec, os.exec.CommandContext and os.Exec.Command.
This can create false positives and it's not accurate because you can
use those functions with perfectly secure arguments like hardcoded
strings for example.
With this change, G204 will warn you in 3 cases when passing arguments
to a function which starts a new process the arguments:
1) are variables initialized by calling another function
2) are functions
3) are command-line arguments or environmental variables
Closes: https://github.com/securego/gosec/issues/338
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
The big#Int.Exp used to be vulnerable in older versions of Go, but in the
meantime has been fixed (https://github.com/golang/go/issues/15184).
Signed-off-by: Cosmin Cojocar <cosmin.cojocar@gmx.ch>
I thought that an example where the user inputs a URL is more realistic.
Because if your operating system is already hacked then you are already screwed.
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
* Allow for SQL concatenation of nodes that resolve to literals
If node.Y resolves to a literal, it will not be considered as an issue.
* Fix typo in comment.
* Go through all files in package to resolve that identifier
* Refactor code and added comments.
* Changed checking to not var or func.
* Allow for supporting code for test cases.
* Resolve merge conflict changes.
* Support stripping vendor paths when matching calls
* Factor out matching of formatter string
* Quoted strings are safe to use with SQL str formatted strings
* Add test for allowing quoted strings with string formatters
* Install the pq package for tests to pass
* Add a rule which detects file path traversal when extracting zip archive
* Detect if any argument is derived from zip.File
* Drop support for Go version 1.8
