This is a command injection prevention cheat sheet by Semgrep, Inc. It contains code patterns of potential ways to run an OS command in an application. Instead of scrutinizing code for exploitable vulnerabilities, the recommendations in this cheat sheet pave a safe road for developers that mitigate the possibility of command injection in your code. By following these recommendations, you can be reasonably sure your code is free of command injection. Learn more about Command Injection vulnerability concepts.Documentation Index
Fetch the complete documentation index at: https://docs.semgrep.dev/llms.txt
Use this file to discover all available pages before exploring further.
Check your project using Semgrep
1. Running an OS command
1.A. Running OS commands with exec.Command()
TheCommand and CommandContext execute commands provided as arguments. If unverified user data can reach its call site, this may end up in a command injection vulnerability. Both Command and CommandContext have built-in protections that do not let command arguments cause trouble. But ensure that the command itself is not controlled by the user, also do not use sh, because internal protection does not work in this case.
Example:
References
Mitigation
Do not let the user input inexec.Command and exec.CommandContext functions. Alternatively:
- Always try to use internal Go API (if it exists) instead of running an OS command. In other words, use internal language features instead of invoking commands that can be exploited.
- Do not include command arguments in a command string, use parameterization instead. For example:
Use:Instead of: - If it is not possible, then strip everything except alphanumeric characters from an input provided for the command string and arguments.
- Try to avoid non-literal values for the command string.
- If it is not possible, then do not let running arbitrary commands, use an allowlist for inputs.
Semgrep rule
go.lang.security.audit.dangerous-exec-command.dangerous-exec-command
1.B. Creating exec.Cmd struct
TheCmd represents an external command that is prepared or run. If unverified user data reaches its call site it can result in a command injection vulnerability. Make sure that the command path and first argument are not controlled by the user, also do not use sh, because internal protection does not work in such a case.
Example:
References
Mitigation
Do not let the user input inexec.Cmd struct. Alternatively:
- Always try to use internal Go API (if it exists) instead of running an OS command.
- Try to avoid non-literal values for the command string.
- If it is not possible, then do not let running arbitrary commands, use an allowlist for inputs.
- Do not include command arguments in a command string, use parameterization instead. For example:
Use:Instead of: - If it is not possible - strip everything except alphanumeric characters from an input provided for the command string and arguments.
Semgrep rule
go.lang.security.audit.dangerous-exec-cmd.dangerous-exec-cmd
1.C. Writing to a command’s StdinPipe
Command’sStdinPipe returns a pipe that is connected to the command’s standard input when it starts. A command injection vulnerability happens if unverified user data reaches StdinPipe. A malicious actor can inject a malicious script to execute arbitrary code.
Example:
References
Mitigation
Do not let the user input in command’sStdinPipe. Alternatively:
- Always try to use internal Go API (if it exists) instead of running an OS command.
- Do not use it to run the
bashcommand and to avoid non-literal values for the command string. - If it is not possible, then do not let running arbitrary commands, use a white list for inputs.
- Strip everything except alphanumeric characters from an input provided for the StdinPipe input.
Semgrep rule
go.lang.security.audit.dangerous-command-write.dangerous-command-write
1.D. Running OS commands with syscall.Exec()
Execor ForkExec invokes the execve(2) system call. If unverified user data can reach its call site, this is a command injection vulnerability. Make sure that the command is not controlled by the user, also do not run sh with any possibility of user input involved in command arguments.
Example:
References
Mitigation
Do not let the user input insyscall.Exec and syscall.ForkExec functions. Alternatively:
- Always try to use internal Go API (if it exists) instead of running an OS command.
- Try to avoid non-literal values for the command string.
- If it is not possible, then do not let running arbitrary commands, use an allowlist for inputs.
- Do not include command arguments in a command string, use parameterization instead. For example:
Use:Instead of: - If it is not possible - strip everything except alphanumeric characters from an input provided for the command string and arguments.
Semgrep rule
go.lang.security.audit.dangerous-syscall-exec.dangerous-syscall-exec